《微服务架构 — 服务治理 、 服务限流、服务降级、服务熔断》由会员分享，可在线阅读，更多相关《微服务架构 — 服务治理 、 服务限流、服务降级、服务熔断（3页珍藏版）》请在金锄头文库上搜索。
1、微服务架构 服务治理 服务限流、服务降级、服务熔断1 文章目录 目录 服务限流 服务降级 服务熔断服务限流C S的异常问题：C的请求太多，超出S的服务能力，导致S不可用。例如： DoS 攻击，企图耗尽被攻击对象的资源，让目标系统无法响应直至崩 溃。因此， S 需要能够进行自我保护，例如： S 对 C 限流，保护 S 的服务 资源。限流通常在网关或网络层面实施。对各类请求设置最高的 QPS 阈值，当请求 高于阈值时直接阻断。常用的限流算法有滑动计数，漏斗限流和令牌桶限流三 种。 滑动计数限流：按时间片（比如 1 秒）定义滑动窗口，计数器记录当前 窗口的请求次数，达到阈值就限流，窗口滑动后计数器归
2、零。可采用循 环队列数据结构实现。 漏斗限流：维护一个队列，所有请求进队列，按 FIFO 服务，队满溢出 则丢弃请求。 令牌桶限流：按固定速率往桶中存入令牌，服务前先从桶中取令牌，取 到令牌才服务。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请 求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例 如：商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了 大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正 常响应。服务降级C老S的异常问题：S自身出现异常，或者由于资源有限需要对部分C请求 故意表现为异常（类似限流），为了不影响其
3、他服务功能，主动关闭服务的一 些功能。当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以 保证核心业务不中断。比如：网上超市下单界面有一个推荐商品凑单的功能， 当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。 简而言之，降级类似于把部分代码注释掉，牺牲部分功能。这要求 S 在实现 时，需要具备感知异常的能力，并对关键逻辑实现开关控制。实际场景中，对 异常的感知通常由熔断器实现。服务熔断C老S的异常问题：当C发现S出现异常（比如：大量超时），由C主动 出击，暂停对 S 的请求。当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时 或者收到错误
4、返回。如果调用链路比较长，可能会导致请求堆积，整条链路占 用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断， 标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连 接。C对S熔断后，那么原本需要调用S实现的逻辑怎么办呢？ C可以使用Mock 数据、缓存数据、缺省数据等替代，或者干脆就是抛异常返回错误信息。 此时，如果 C 也是一个服务，它相当于做了服务降级。所以我们经常看到服 务熔断和服务降级一起出现（Hystrix的断路器在实现时就是把熔断和降级方案 打包实现的）。但本质上它们不是一回事，降级发生在S，熔断发生在C。之 所以配合实现，是因为许多微服务模块同时
5、承担 C 和 S 两种角色。下谚聚统匸请求开始央败卜瞬系统2.断路器打开请求快速去败3.灰送健康检查卩淅系统4.断路器重苣姣丁匚勺：可鬲当达到健離的 闽値时豆赴连按请求卄始凰时 或返回誥浜码当达到一定阖值时 停止监透通帖偶尔发送健展检僅。 仟看下游系统是亦已恢筮I F游柔统I总9调用代码代码服無的限弊卜一卜文代码服务的限界上；文调用调用代码4代码眾务的限畀卜.卜一文调用调用P9代码N代码4服务的限界上卜文服务熔断的设计有两个关键点：1. 判断何时熔断：通常使用无锁循环队列计数来实现。C对每次请求S 的正常、异常（失败、拒绝、超时）返回计数，当异常返回次数超过设 定阈值时进行熔断。2. 何时从熔断状态恢复：处于熔断状态时，C每隔一段时间（比如5秒），允许部分请求通过，若这部分请求正常返回，就恢复熔断。
