Plan B之服务雪崩与熔断保护

在公众号回复课程,免费获取JAVA全栈课程

开发时的Plan B

作者 | 颜 群

公众号 | 大数据和人工智能技术

  开发者无法预料所有可能发生的意外，因此有了异常处理机制；开发者无法罗列出所有的选择分支，因此有了else（或switch中的default）；同样的，开发者也无法掌控网络等客观设备的稳定性，因此就需要一种Plan B计划，保证系统运行期间的合理性。本次介绍的Plan B就是指“熔断保护”机制，它主要解决的问题是“服务雪崩”。

 日常开发中，我们经常会维护一个公共服务。如，“短信通知”就是一个公共服务，它可以供系统中的订单服务、用户服务、金融服务等共同使用，并且可能存在级联的调用关系，如图所示。

 然而这种“级联调用公共服务”的设计，却容易带来服务雪崩问题。以图中的“秒杀服务”为例。试想，如果“短信服务”出现了网络延迟等异常，那么就无法给“订单服务”的调用作出响应，从而导致“订单服务”处于等待状态。同理，“订单服务”自身的等待，又会导致“秒杀服务”的请求无法得到应答，进而也随之一起处于等待状态。类似这种场景，由于某个服务的延迟，而导致调用链上的多个服务一起处于等待的状态，就称为服务雪崩。

 可见，服务雪崩会造成请求链上的多个服务同时处于等待状态。并且请求链越长，对性能的损耗就越严重。在高并发环境下，线程的使用率十分珍贵，而服务雪崩却会造成大量线程处于阻塞状态，因此服务雪崩会严重的影响系统的性能以及用户的体验。

解决服务雪崩的一个有效策略就是使用“熔断保护”机制。

熔断保护的核心思想是：失败 总比“长期等待”好得多。例如我们在使用电脑时，如果双击了一个软件却长时间无法运行它，那么系统就会给我们一个提示，大致意思就是：XXX应用未响应，你可以点击“关闭程序”结束它，如图。

如果我们点击了“关闭程序”，实际就会触发一次 熔断保护机制。即，我这次宁愿不用你了，也不想长时间在这耗着等你。

在软件开发时，经常会通过一些算法或心跳检测机制实现 熔断保护机制。例如，使用心跳检测机制 检测某个服务是否正常运行，如果异常 就关闭它；如果后续某个时间，该异常的服务又正常运行时了，就又可以停止熔断保护，转向正常的服务流程。

说明：“心跳检测机制”是检测可用性的一种常用手段。试想，在 BS 架构中，服务端如何感知客户端已经离线？正常情况下，当客户端点击了“退出”按钮后，服务端就能断定此客户端已下线。但在弱网环境下，服务端如果因为网络问题暂时丢失了与客户端的通信，无法及时的接收客户端发来的“退出”请求，那么就无法根据客户端的“退出”请求来断开连接。此时就可以使用“心跳检测机制"，即在客户端和服务端之间维持一个双向的“心跳数据”（即，每隔一段时间，就会向彼此发送一条数据），如果某一方长时间接收不到对方发来的心跳，就可以断定对方已经掉线，从而断开连接。

实践中，经常用keepalived组件实现心跳检测机制。

- 完 -