微服务的重试与弹性设计

banq 18-03-26
              

本文是开源工作流引擎Camunda联合创始人Rücker对微服务调用进行弹性设计的改进建议,类似谷歌的gRPC和阿里的Dubbo都可以看成是RPC微服务,Spring提供了REST服务,这些服务虽然形式不同,本质都是同步调用。这种同步调用在生产环境可能遭遇各种意外情况发生堵塞延迟,怎么办?下面他提出了几种设计方案。


以简单的网络购物为案例:

客户端 ---->支付微服务 ---->信用卡微服务

这种简单的调用链非常普遍,以它为案例阐述有状态的弹性模式。

假设信用卡服务变得疯狂,也就是说它虽然还能响应,但非常缓慢。那么支付服务调用信用卡服务会被阻塞在这里,因为支付服务一直等待信用卡响应,而信用卡服务延迟响应了。由于延迟过程需要很长时间,所有从支付服务出发的线程都会被堵塞在这里,支付服务最终会超时出错。在你的系统中出现这样一个很微小的故障可能会瘫痪整个系统,这是一种没有弹性的设计。

下面是改进设计演进版本:

快速失败fail fast
这里可以应用一个快速失败模式,比如使用断路器。在这个例子中,使用了Netflix Hystrix断路器。如果信用卡服务响应减慢,断路器就会立即中断支付服务的调用并且让支付服务马上发生故障。这样,即使功能无法实现了(我无法向信用卡充值),但仍然可以确保整个系统可响应。

快速失败是不够的
但快速失败是不够的。在信用卡服务被修复后,经常会进行重试。此重试需要具有状态性,不仅可以立即重试,而且可以在几分钟,几小时甚至几天内重试。对信用卡服务进行有状态的重试,也就是重试带着信用卡服务的输入参数。

保持同步响应
在这种情况下,通常不需要异步处理,只要信用卡服务可用,就可以很好地返回同步响应,但只有在不能同步时才切换到异步。

区分能否同步响应,使用HTTP返回码来支持(200 OK意味着所有OK,202 ACCEPTED意味着同步失败)。

没有消息的异步工作分配
相比同步调用服务的另一种方法是异步通信。默认是使用消息。

但是异步不一定使用消息,可以使用工作流引擎作为工作分配,表现得像一个队列。工作流引擎会提供一个支付是否完成的查询,如果没有,会让客户更换另外一张信用卡,然后再次调用支付服务,这个过程只要指定流程后,流程会负责重试。


使用补偿的业务交易
在分布式系统中,ACID事务不适用(或者至少不能很好地扩展)。使用补偿是另一种选择 - 这意味着如果以后发生失败时可以撤​​销已执行的工作。

在这个案例中,基于上面的流程重试,重试几次后就不再无限次重试了,而是作为支付失败处理,然后将支付之前的流程进行回退,调用回退环节的各个回退方法执行补偿,最终将状态恢复到这次支付活动没有发生以前的状态。

flowing-retail/payment-rest at master · flowing/fl

[该贴被admin于2018-03-27 10:39修改过]

              

1