拆微服务之前，先把可观测性和降级路径补齐
· 阅读需 3 分钟
2020 年前后，微服务这个词在很多团队里都很热。系统一旦变大，大家很自然就会想：是不是该拆服务了？这个方向当然有它的价值，但我后来越来越警惕一种冲动，就是把“拆”本身看成答案，却没有先补上对应的观测和降级能力。
没有这些基础设施，服务拆得越细，很多问题只会变得越难定位。
为什么“能拆”不等于“该拆”
单体服务的很多问题，其实在一个进程里还能被肉眼看清楚。
一旦拆成多个服务，请求链路拉长，失败点增加，接口重试、超时、依赖抖动都会变得更复杂。
如果团队还没有稳定的日志关联、指标监控和告警阈值，拆分后的系统只是把问题分散了，并没有让问题变少。
我最看重的第一层准备：可观测性
在我看来，至少要先有这些基础：
- 能区分请求是卡在哪个服务
- 能看到错误率、耗时和超时分布
- 能把同一条链路串起来看
- 出问题时能快速定位是调用方、被调方还是中间网络
这些能力如果没有，服务拆完之后你听到的第一句话通常会变成：“好像某一段有点慢，但不知道是哪。”
第二层准备：降级路径
微服务一旦依赖变多，故障就不再只是“这个接口报错”。
更常见的情况是：
- 下游变慢，主流程一起被拖慢
- 某个非核心服务挂了，主页面也跟着不可用
- 重试链路失控，把问题从一个点放大成一片
所以我后来判断系统能不能拆，都会问：如果某个服务不可用，主流程有没有降级路径？
没有降级，就等于你把系统稳定性押在了所有依赖都一直正常这件事上。
真正值得拆的时候，通常长什么样
我不是反对微服务，而是更相信它应该建立在这些前提上：
- 团队已经能稳定看懂链路
- 服务边界确实清晰
- 依赖失败后有明确回退策略
- 运维和发布流程能承接更多服务实例
具备这些条件时，拆服务才更像放大优势；没有这些条件时，拆分只是在放大管理成本。
小结
微服务最大的门槛，从来不只是代码拆不拆得开，而是系统在拆开之后你还能不能看得清、守得住。
2020 年我对这件事的感受越来越强：在拆分之前把可观测性和降级路径补齐，比先拆再补要稳得多。