第6章 抗排异治疗：弹性与容错

第6章 抗排异治疗：弹性与容错

拆完、上线、开灯，你以为终于消停了——可现实是：线上流量一来，分布式系统比单体更容易一个接一个地崩。本章给系统上"抗排异与免疫"：熔断切断坏一路、限流挡住恶流量、降级保主流程、重试兜偶发抖动、舱壁限制一场雪崩的传染半径。目标只有一个：坏一块不影响全局。

单体里你让一个模块坏了，通常整台一起炸；微服务的巨大卖点本来是"坏一块别连累别人"，但如果你什么都不做，它根本不会自动坏一块不连累——恰恰相反，同步调用和共享资源会把一个小故障指数级放大成一场雪崩。所以弹性与容错不是选修，是把"故障隔离"这个微服务承诺真正兑现的那一步。

一条主线

还是商城，假设支付服务突然变慢或挂了。没有容错时，一次支付慢会拖住所有依赖它的下单请求，线程池被占满，订单也挂、用户也挂，最后整站打摆子。我们跟着这一个故障，看熔断怎么把"坏的支付"拦在墙外、限流怎么保住"还能用的"，降级怎么让主流程绕开，舱壁怎么防止"一个爆掉的全带崩"。

沿途站点

6.1 熔断器：过载保护闸——讲 Hystrix 那类熔断的心智模型：三态（闭合/开路/半开）、失败率驱动的自动开关，以及怎么让"对坏路直接短路"，别把请求继续往火里送。

6.2 限流与降级：门诊分流——限流按阈值挡恶流量（令牌桶/漏桶），降级在压力下提供"次一级但可接受"的响应。两者配合让保住的系统继续喘气。

6.3 重试与舱壁：超时自救与水密隔舱——重试兜"偶发而可恢复"的失败（但要小心放大风暴、要退避要幂等）；舱壁用独立的资源池把一个服务的故障关在小隔间里，防止它"殃及池鱼"。

拐点与结论

本章的认知转折：故障隔离不是"微服务天然自带"的，而是你显式设计出来的。你得主动告诉系统"哪段坏就不去碰它、哪个池满了就别往里挤、什么情况下给次一点的答案"，它才会在你最需要的时刻站得住。把这套思想又称一句"面向失败设计"——接受失败必然发生，把注意力放在"失败时怎么优雅"，而不是"如何保证永不失败"。读完全章，你会用一句话回答"为什么晴天没人管事故"。

这一章最容易踩的三个坑

弹性与容错的坑，往往在"以为做了"和"做到位"之间：

1. 以为"拆了服务"就自动获得故障隔离。这是最危险的错觉。什么都做，同步调用依然会把一个小故障指数放大成雪崩。隔离是显式设计出来的，不是天然自带的。
2. 重试不配退避和幂等。遇到失败就"再试一次、换个姿势再试"，结果把故障方压得更死，风暴越滚越大。重试一定要带指数退避、带抖动，还要下游幂等，否则重试本身成了新的故障源。
3. 熔断只装一半，短路后没人接。熔断了但上层没有降级、没有缓存、没有明确提示，前端收到一坨 undefined，体验照样崩。熔断必须和降级/本地缺省值配成一套，才算完整地"面向失败设计"。

带着这三点进站点，你会在每一节里看到它们被反复收拢。

读完你应该

• 手绘熔断器的闭合/开路/半开三态，并说明各自的动作
• 说出限流"令牌桶/漏桶"的心智模型，和降级的"次一级方案"
• 设计一次"带退避、带幂等"的安全重试，避开放大风暴
• 用舱壁把"支付挂了"关进小隔间，避免全站陪葬
• 判断一次故障时该熔断、该限流、该降级还是该重试

下一章的接力

系统能扛住故障了，但还有另一路威胁：恶意或疏漏的用户、不怀好意的调用、没护住的服务间通信。第 7 章给它上"无菌与门禁"——认证授权、API 与通信安全，再走进测试与混沌工程把防线提前演练。先会抗故障，再会防入侵。