微服务熔断器一般放在哪

发布网友发布时间：2022-04-21 14:13

共1个回答

热心网友时间：2023-07-22 23:52

随着企业微服务化战略的实施，业务功能细分，越来越多的服务从原有的单体应用中分解成一系列独立开发、部署、运维的微小服务，服务之间则依赖于各种RPC框架互相通信。纵然，微服务化有着很多优势，但与之伴随而来的是各种复杂性，对开发人员来说，除了业务领域本身外，还需要考虑由于服务拆分之后诸如分布式事务、服务部署及运维、rpc调用等系列问题，本文将重点分析微服务化过程中熔断机制及应用注意事项。

微服务调用与“雪崩效应”：

　　微服务化之后服务之间调用关系复杂，调用层级深，服务之间依靠rpc框架进行通信，如下图1，实线是同步rpc调用，虚

图1 服务调用关系

　　线则是异步rpc调用，整个调用链路从webapi开始到dinnerservice结束，红色节点则表示该服务不可用或高延迟，异步调用msgservice异常对链路返回结果并无影响，而同步调用（memberservice服务）的性能对链路则有很大影响，其会造成链路上planeservice、orderservice及webapi服务堵住，堵着的请求会耗费线程及io资源，随着此类请求越来越多，特别是在流量高峰时，如果不能及时解决memberservice的问题，最终将把整条链路堵死，造成webapi不能对外提供服务，提供崩溃，这就是所谓的雪崩效应。

雪崩效应解决方案：

　　针对雪崩效应的情况，通常我们可以有如下几中方案来解决。

　　一、同步调用异步化方案。如图所示，异步调用对于调用方来说，不会造成堵塞，从而将调用方保护起来。因此，可从业务层面设计入手，将不需要及时返回结果的业务调用设计成异步来调用。典型场景，注册验证码发送，消息通知等。

　　二、限流方案。通过*入口流量，将并发*在一定范围内，能在一定程度上避免雪崩效应，如果不可用服务是部分不可用或超时时。

　　以上方案都不能彻底解决问题症结，那真正比较可行的则是第三种，应用熔断隔离机制的方案。熔断，就像电路短路，当电压过高，负载加重时，保险丝就会自动断开，避免事故发生。在微服务中，当链路上某个服务不可用或延迟严重，达到熔断器设定指标阈值时，则触发熔断机制，对于后续请求直接返回默认结果或抛出异常，避免整个链路因为部分服务不可用而雪崩。隔离则是服务调用方将耗时的方法或rpc调用与业务代码隔离开来，避免耗时方法或rpc调用造成服务堵塞。

熔断机制及考虑因素：

　　熔断机制具体实现体现为一个熔断器，如何实现熔断器，主要考虑以下几个方面。

　　第一，熔断请求判断算法即熔断在什么条件处于开启状态，什么条件处于关闭或半关闭状态。使用滑动时间窗口来记录每个时间片内相关熔断计数指标及熔断器状态，这个时间片段称作为一个bucket，默认维护10个bucket，每1秒一个bucket，随着时间的滚动，最早的bucket抛弃，创建新的bucket到滑动窗口右边。每个blucket记录请求总数、成功数、超时数、拒绝数及熔断器状态，默认错误超过50％且10秒内超过20个请求进行中断拦截。