熔断降级落在网格这一层，业务就不用各自写一套
服务调用链一长，某个下游一抖，上游跟着全慢。熔断降级就是在这根链上装个开关，下游撑不住时先切走、先砍掉不重要的，保住主干还能喘气，喘过了再慢慢恢复。一、阈值别拍脑袋
熔断的触发阈值不能凭感觉定，拍出来的数往往和实际扛不住的点差很远。要拿压测和真实峰值说话，说出来的数才有依据，依据稳了，触发时才没人质疑该不该断。降级粒度要细，粗了会把不该砍的能力一起砍掉，体验更差。流量规则改完先在小范围试，试过了再推到全量，推之前心里才有底。
阈值要能调，调的依据是观察。观察一段时间内的失败率和耗时，发现老误断就放宽，老不断就收紧。死写一个值不回头看，环境变了它还按老标准，标准早过期了。熔断阈值别拍脑袋，拍出来的数往往和实际扛不住的点差很远。日志级别别全开，全开会盖过真正该看的那几条。
二、降级方案先备好
降级用的那个开关平时不按，但得先备在手里。备着的方案要写清触发条件和砍掉哪些能力，写清了紧急时刻才敢按，按下去知道牺牲的是什么，牺牲得心里有数。演练时故意触发熔断，触发过才信这套机制真兜得住。治理边界画在网格层，业务侧不用关心怎么拦怎么转，只管写逻辑。
降级影响要提前知会下游，下游不知情会以为自己这边出了毛病，毛病查半天查到是你砍了调用，两边白白折腾。提前打声招呼，对方好把自己的预期也调一调。降级方案先备好，备着的那个开关平时不用，急了才敢按。告警要能收敛，一条根因引发一堆告警，收敛了才好定位。
三、熔断后能自愈
熔断不是一断了之，得能自己探活、自己恢复。自愈的逻辑写清楚，写清了才不用半夜爬起来手动合，手动合慢半拍，半拍里业务还在别处受着影响。恢复后慢慢放量，一下子全放回去刚稳下来的系统又会被冲。规则冲突要有人拍板，两个团队各写一套会互相打架，打架就乱了。
延后那阵子看着平，实际下游还在被压，压到上限一次性释放，释放出来的场面比早处理难看得多。熔断后要能自愈，自愈的逻辑写清楚，写清了才不用半夜爬起来。可观测数据留多久要想好，留短了出事查不到，留长了费存储。
四、状态要可见
熔断状态要能实时看到，看得见状态的人不会往那个坑里继续发请求。看不见，请求照发，发了全超时，超时堆起来把更多环节拖慢，慢到整个页面都转不动。指标先定哪些要看，定太多了反而没人看，没人看等于没采。
熔断次数和时长要留趋势，趋势往上走就是告警。看见趋势的人早介入，介入时还能从容扩容或者限流，从容比救火强，救火时手忙脚乱容易再点错一处。降级影响要知会下游，下游不知情会以为自己这边出了毛病。埋点改了要同步文档，文档不更新的团队迟早不知道数从哪来。
五、降级粒度要细
降级别一刀切，粗了会把不该砍的能力一起砍掉，用户体验掉一大截。细到某个非核心功能单独关，核心链路照常跑，跑着的人根本感觉不到哪一角被收了。调用链打通后，慢请求能追到具体哪一跳拖了后腿。
没演练过的开关，真到那天没人敢按，不敢按就只能干挺着，挺到下游完全没响应，响应没了才被迫动手。频繁熔断说明上游真撑不住，光熔断不扩容只是延后爆点。异常指标要有基线，有基线才知道现在是平常还是反常。
六、恢复慢慢放量
熔断恢复后别一下子全放回去，刚稳下来的系统再被全量冲一下，容易又塌。慢慢放量，放一点看一阵，阵里没问题再放一点，这样每次放的都有兜底。监控面板按角色分，值班的和开发的关注点不一样，混着反而乱。
放量过程盯紧指标，指标一反复就缩回上一档。缩回去不丢人，硬撑着放量把刚恢复的又冲垮，垮了才真难看，难看之外还得重新走一遍恢复流程。熔断状态要可见，看不见状态的人还在往那个坑里发请求。看板别做得太花，花哨的图不如一张能直接看出毛病的实在。
熔断降级是链上的保险，保险装对了，单点故障伤不到全局。阈值、方案、自愈、可见、粒度、放量，六件事做到位，网格层这层保险才真保险，而不是摆样子的开关。 每一段都很有分量，认真读完全篇感觉整个人都提升了不少。 对这个话题有了更全面的认识，不再只停留在表面理解。 不管是内容还是排版都很用心，看得出来楼主花了不少时间，必须支持。
页:
[1]