微服务拆到多少个，运维开始"管不过来"？聊聊规模焦虑的临界点

背景

我做了 5 年运维，从最早一个 monolith 跑在两台 ECS 上，到现在管着 60+ 个微服务的 K8s 集群，切身体会到一个感受：服务数量每翻一倍，运维的复杂度不是翻倍，是翻好几倍。

具体来说，我数了一下我们现在的日常负担：

• 60 个服务 × 平均 3 个副本 = 180 个 Pod，光"谁在跑、谁没跑、谁在抖动"就要盯；
• 每个服务有自己的日志 pattern、告警规则、健康检查、配置项——监控面板从 3 个 tab 膨胀到了 12 个 tab；
• 一次发布，以前是"改一个 jar 包重启"，现在是"选服务 → 灰度 → 观察 → 全量 → 回滚预案"，一次变更涉及 4-5 个环节；
• 最要命的是排障：以前一个进程挂了看 dmesg + tail log 就完事，现在一个请求要跨 6-7 个服务，链路追踪是刚需，但 trace 采样率一开全量，日志存储成本直接 ×3。

几种常见做法（也是分歧所在）

1. "拆得越细越好，运维靠平台化兜底"——典型大厂思路：服务拆到 100+ 个，但配套有完整的 Service Mesh、统一日志平台、自动化巡检、AIOps 告警收敛。运维的核心工作变成"维护平台"而不是"维护服务"。

   • 问题：小团队没有这个平台预算和人力，拆了就是灾难。

2. "别拆了，模块化单体（Modular Monolith）就够了"——很多中小团队的选择：一个进程里按模块分 package，部署还是单实例。运维压力小，但牺牲了独立扩缩容和团队并行开发。

   • 问题：一旦某个模块内存泄漏，整个进程挂；不同模块的技术栈也被锁死了。

3. "折中方案：按业务域拆，但控制总数"——比如 10-20 个服务，每个服务对应一个业务域（用户、订单、支付、库存……），每个域内用模块隔离。运维管得过来，也有一定独立性。

   • 问题：怎么定义"业务域"本身就有争议，拆错了比不拆还难受。

我的倾向

我个人偏向第 3 种，而且有一个比较具体的判断标准：如果你们团队的值班同学，能在 5 分钟内定位到"哪个服务出了问题"，那服务数量就没超限；如果需要翻 trace、查 3 个以上的面板才能定位，说明该收一收了。

但我也承认，这个标准高度依赖团队规模。一个 5 人的运维团队管 20 个服务和管 5 个服务，体验完全不同。

想听大家聊聊

1. 你们团队目前管着多少个微服务？从什么时候开始觉得"开始吃力"了？
2. 你们有没有设过"服务数量上限"？怎么定的？
3. 有没有"拆了又合回去"的经历？什么情况下做的这个决定？
4. 小团队（运维 3 人以内）用 Service Mesh 是加分项还是负担？

这个话题没有标准答案，但我觉得每个做运维的人都会遇到。欢迎带具体数字和场景来聊，越具体越好。