服务容错、限流、资源隔离、熔断、监控…3天，撸干净了！

占小狼的博客 · 公众号 · · 2021-06-04 09:15

正文

有一次，饿了么业务部门发现指标突然降了50%，技术团队排查问题发现DAL（数据库中间件）做了限流。业务强行让把限流打开，结果打开后 数据库 QPS 瞬间飙到2万，业务瞬间慌了，赶紧让再给限制住。

不仅饿了么，美团同样在服务治理方面也面临着巨大挑战，如对多语言支持不够好；中间件和业务绑定在一起，制约彼此迭代；异构治理体系技术融合成本很高；治理决策比较分散。

01

饿了么CTO说，

“不能被烂用的框架不是好框架”！

两家头部大厂在服务治理方面都投入了大量的人力、物力、财力，如果服务治理搞不好，分布式系统就像一潭死水，享受不了高内聚、低耦合、扩展方便、部署灵活、开发效率提高的红利。所以说，服务治理是微服务化的第一关。

饿了么CTO总把“不能被烂用的框架不是好框架”放在嘴边，啥意思呢？

比如监控的 SDK 曾经被业务错误的使用，每发一次报警就启一个新线程，最后整个进程因为开了太多的线程挂掉了。所以说你无法预测每个开发者会怎么使用你的框架，即使框架被滥用了，最坏的情况，也要保证能活的下去。

02

回到业务场景，

服务治理究竟要治理什么？

服务治理有很多痛点需要开发团队使尽浑身解数，如服务注册发现、请求链路追踪、服务熔断、服务限流、服务管控配置、服务预警等等。

放到实际业务场景：

故障定位非常困难，出了问题，各查各的，非常低效，怎么实现高效定位；
秒杀的时候，所有的监控系统、链路跟踪系统都要是可以降级的，不能因为这些东西导致整个系统崩溃；
超时配多少是合适的？100ms？300ms？极端情况有些业务配到 3 秒的，很多程序员并不清楚超时设成多少合适；
你无法无限制的接受请求，不可能一百个并发就接收一百个，并发到底怎么配，怎么限流？

服务治理是一个非常大的话题，我最重要的经验是做好保护与自我保护。而对大部分程序员来说难点往往在于无法将积累的单点知识串联起来，形成系统知识结构，这就导致停留在机械的应用层面，无法根据业务场景与底层逻辑进行匹配，最终无法形成解决问题和举一反三的能力。

理论 - 实现 - 应用 - 问题 - 解决 - 精进是我们提升自我能力的路径，前段时间和玄姐（前58集团技术委员会主席、阿里云MVP、腾讯云TVP）聊，收获颇多。他谈到，以架构师的思路和视野学习服务治理，你将更容易掌握同行难以复制的核心竞争力。

为了帮助更多开发工程师、架构师掌握服务治理核心，玄姐联合快狗打车CTO沈剑老师，结合10多年一线大厂实践经验，打磨了一套《千亿级并发10大维度服务治理解决方案实战》专栏课。3天精讲，10大维度，带你深入学习服务治理，掌握核心框架模型，并在千亿级企业真实海量数据案例中，培养服务治理实战能力。