在公众号回复课程,免费获取JAVA全栈课程
开发时的Plan B
作者 | 颜 群
公众号 | 大数据和人工智能技术
开发者无法预料所有可能发生的意外,因此有了异常处理机制;开发者无法罗列出所有的选择分支,因此有了else(或switch中的default);同样的,开发者也无法掌控网络等客观设备的稳定性,因此就需要一种Plan B计划,保证系统运行期间的合理性。本次介绍的Plan B就是指“熔断保护”机制,它主要解决的问题是“服务雪崩”。
日常开发中,我们经常会维护一个公共服务。如,“短信通知”就是一个公共服务,它可以供系统中的订单服务、用户服务、金融服务等共同使用,并且可能存在级联的调用关系,如图所示。
然而这种“级联调用公共服务”的设计,却容易带来服务雪崩问题。以图中的“秒杀服务”为例。试想,如果“短信服务”出现了网络延迟等异常,那么就无法给“订单服务”的调用作出响应,从而导致“订单服务”处于等待状态。同理,“订单服务”自身的等待,又会导致“秒杀服务”的请求无法得到应答,进而也随之一起处于等待状态。类似这种场景,由于某个服务的延迟,而导致调用链上的多个服务一起处于等待的状态,就称为服务雪崩。
可见,服务雪崩会造成请求链上的多个服务同时处于等待状态。并且请求链越长,对性能的损耗就越严重。在高并发环境下,线程的使用率十分珍贵,而服务雪崩却会造成大量线程处于阻塞状态,因此服务雪崩会严重的影响系统的性能以及用户的体验。
解决服务雪崩的一个有效策略就是使用“熔断保护”机制。
熔断保护的核心思想是:失败 总比“长期等待”好得多。例如我们在使用电脑时,如果双击了一个软件却长时间无法运行它,那么系统就会给我们一个提示,大致意思就是:XXX应用未响应,你可以点击“关闭程序”结束它,如图。
如果我们点击了“关闭程序”,实际就会触发一次 熔断保护机制。即,我这次宁愿不用你了,也不想长时间在这耗着等你。
在软件开发时,经常会通过一些算法或心跳检测机制实现 熔断保护机制。例如,使用心跳检测机制 检测某个服务是否正常运行,如果异常 就关闭它;如果后续某个时间,该异常的服务又正常运行时了,就又可以停止熔断保护,转向正常的服务流程。
说明:“心跳检测机制”是检测可用性的一种常用手段。试想,在 BS 架构中,服务端如何感知客户端已经离线?正常情况下,当客户端点击了“退出”按钮后,服务端就能断定此客户端已下线。但在弱网环境下,服务端如果因为网络问题暂时丢失了与客户端的通信,无法及时的接收客户端发来的“退出”请求,那么就无法根据客户端的“退出”请求来断开连接。此时就可以使用“心跳检测机制",即在客户端和服务端之间维持一个双向的“心跳数据”(即,每隔一段时间,就会向彼此发送一条数据),如果某一方长时间接收不到对方发来的心跳,就可以断定对方已经掉线,从而断开连接。
实践中,经常用keepalived组件实现心跳检测机制。
- 完 -
领取专属 10元无门槛券
私享最新 技术干货