微服务故障模式与构建弹性系统

1.5 亿，这个数字，是 Capillary 的 Engage+ 产品在新年高峰时段两小时内发送的通信量。即便是这样的小故障，也会影响到我们客户的资本和我们产品的信誉。

故障就像一场大爆炸，它们可以是手榴弹的爆炸，也可以是核弹级别的爆炸，而爆炸造成的破坏取决于爆炸半径。 再好的系统，也会有出故障的一天。若不及早发现并加以处置，也会加剧造成更大的破坏。

请注意，这篇文章将着重于微服务设计中的健壮性和故障恢复，尤其着重于微服务间的通信与故障恢复。

1 动机

在微服务架构环境中，一项服务一旦出现故障，就会对其他服务产生影响，进而造成产品的多次更新，使用户失去对产品的信心。在 Engage+ 中，我们采用了一种编排的微服务架构。因为时间的关系，我将不会详细描述这个模型的细节。简而言之，我的意思是说：

在一个编排的微服务架构中，系统的每个组成部分都不依靠单一的中心控制点，而是涉及有关业务事务工作流程的决策。

从图中我们可以看到，在决策过程中涉及了许多的服务，所以在这个架构下，处理任何故障就如同在干草垛中寻找一根针那样艰难。所以，我们怎样才能在它把整个干草垛都烧掉之前，检测出这些故障，然后再控制它们的爆炸半径？

2 故障与恢复

其基本可以分成两大大类：

服务之间的故障：这些是在 Capillary 内运行的其他微型服务

基础设施级别的通信故障：这些故障可能包含基础设施组件，如数据库（MySQL）、队列（RabbitMQ）等。

让我们看看更多的细节：

服务之间的故障

下游服务可能会因为各种各样的原因而失去响应，从而造成故障。

这些故障的原因有很多，比如 CPU 使用率过高会引起很多无响应的调用、应用程序线程的耗尽、服务内存的问题等等。

按照行业标准，一项服务必须具有 99.999% 的可用