微服务拆到 8 个以后，运维成本开始反噬：你们会考虑回退成模块化单体吗？

先交代背景，免得大家只看到观点。我们是一条 6 人团队维护的 B 端业务线，K8s 1.28 自建 3 节点集群，上面跑着 8 个 Go/Spring 混合微服务。最初拆分理由很正：团队并行开发、独立发布、故障隔离。但一年下来，我逐步体会到几个越来越贵的「隐性成本」：

1. 发布与联调成本：一次涉及 3 个服务的接口变更，要协调 3 条 CI、3 个灰度批次，联调环境里 8 个服务互相依赖，任何一个起不来整条链路都瘫。
2. 可观测性碎片化：日志分散在 8 个 Pod、trace 跨 8 个进程，新人排障的平均时间从「看一个日志文件」变成「拼一张分布式调用图」。
3. 资源利用率：8 个服务各自最小 2 副本 × 512MB，光保底内存就吃掉集群 40%+，而真实 QPS 分布极不均衡——两个核心服务占 70% 流量，其余 6 个长期空转。

于是我开始认真考虑「模块化单体」（modular monolith）：一个进程、清晰的模块边界（包级隔离 + 接口契约）、模块间走 in-process 调用，对外仍然暴露 API。收益是部署/日志/事务/连接池全部回归单实例管理，资源可超卖；代价是失去独立扩缩容与故障隔离，且团队需要纪律来守住模块边界。

我的倾向：当服务数 < 10、团队 < 10 人、流量没有 10 倍级差异时，模块化单体的综合成本大概率更低；但如果是多团队各占服务、或存在明确的资源异构（CPU 重 vs IO 重），拆分仍然划算。

想听大家的真实场景：

• 你们拆到几个服务后开始「后悔」？触发点是什么（成本？排障？发布）？
• 有没有做过「合并回单体」的实践？迁移路径怎么走的（先合并发布还是先合并代码）？
• 模块化单体的边界靠什么守——CI 检查包依赖？code review？还是干脆靠「约定 + 信任」？
• 你们是怎么量化「运维成本」的？有没有可复用的指标（发布耗时、排障 MTTR、资源利用率）？