C3 · 适度微服务——反过度拆分的务实回归

C3 · 适度微服务——反过度拆分的务实回归

系列第 13 篇 / C 线第 3 篇（C 线 3/4）
视角：架构师选型 · 深度长文
承接：C1 服务网格选型 · C2 OpenTelemetry 统一可观测 · B4 多智能体 Control Plane · B6 AI 护栏与可观测

「我们花了两年把单体拆成微服务，现在又在考虑合并回去。」——2026 年这类声音在技术社区里越来越响。微服务从「银弹」回归到「一种有代价的工具」，是今年架构圈最务实的一次集体清醒。

一、立论：微服务是手段，不是目的

C 线前两篇讲清楚了「服务间底座」怎么搭：C1 选网格（安全/流量/身份），C2 装可观测（Trace/Metric/Log 一把梭）。但这两条能力有个隐含前提——你已经有很多服务了。

问题恰恰出在这里。过去十年，「微服务化」被当成架构成熟度的标尺，甚至简历驱动开发的 KPI：一个 10 人团队、业务逻辑并不复杂、日活刚过万的系统，也硬拆成 12 个服务，配齐 K8s + Istio + 全套可观测，结果 80% 的精力花在运维自己造的分布式系统上，业务迭代反而慢了。

2026 年的行业共识已经很冷静，可以总结成一句话：

微服务不是目的，是「团队协调成本」与「独立扩展需求」超过「分布式系统复杂度成本」时才值得用的手段。绝大多数系统，应该从模块化单体起步，按需演进。

这个结论不新（Martin Fowler 的 MonolithFirst 早就是经典），但 2026 年它被数据重新夯实了。Gartner 2026 技术趋势报告给出一组刺眼数字：约 45% 的企业在微服务迁移后，遭遇了超过预期的运维成本增长。这不是「拆错了」，是「过早拆、过度拆」的系统性代价。

本文帮你建立一套选型口径：什么时候该用单体、什么时候该拆、怎么拆才不踩坑、以及——为什么网格和可观测这些「微服务税」该由平台团队统一买单，而不是每个业务组自己交。

二、过度微服务的代价：被低估的「微服务税」

把单体拆成 N 个服务，你买到了独立部署和独立扩展，但也同步引入了一整套分布式系统税。每一项单独看都「能解」，加起来就是一支平台团队的工作量：

最常被忽视的，是运维负担随服务数近似线性增长。一篇 5 服务的「微服务」相比 5 模块的单体，运维负担大约是 5×——而多数团队的业务收益根本不成正比。

更隐蔽的是网络延迟叠加：一个用户请求若链式调用 5 个服务，每个 p99 是 20ms，最坏路径就是 100ms，且任何一跳抖动都会放大到端到端。单体里这些是同进程方法调用，开销可以忽略。

架构师判断口径：当你说「我们要上微服务」时，先回答「哪一项目前被分布式复杂度拖垮的收益，能盖过这 5× 的税？」答不上来，就还不到时候。

三、模块化单体回归：不是「带文件夹的单体」

2026 年「模块化单体（Modular Monolith）」重新被奉为务实起点。但很多人把它误解成「就是个分层清晰的单体」——错，关键在边界是否被强制。

3.1 什么是真正的模块化单体

不是「按文件夹分模块」的约定（约定会在 6 个 sprint 后腐化），而是在代码层面强制模块边界：

/src
  /billing
    /internal        # 其他模块禁止 import
    api.ts           # 唯一公开面
  /catalog
    /internal
    api.ts
  /shipping
    /internal
    api.ts

规则：每个模块只暴露一个 api.ts 作为公开面；任何其他模块不得 import /billing/internal。用 lint 规则（ESLint boundaries 插件）或构建期检查在 CI 里让违反边界的提交直接失败。这是「模块化单体」和「两年后需要重写的大泥球」之间的唯一区别。

3.2 Java 生态的趁手工具：Spring Modulith

对本文读者（Java 后端）最相关的是 Spring Modulith——它把「模块边界强制 + 模块间事件驱动」做成了一等公民：

• 用 @ApplicationModule 声明模块，启动时校验依赖方向是否破界；
• 模块间通信优先走 应用事件（而非直接方法调用），天然为将来「抽成独立服务」留好异步 seam；
• 集成测试可针对单个模块跑，不拉起全应用。

这意味着你今天写的单体，明天抽服务时边界已经是现成的，拆分是重构而非重写。

3.3 单体也能规模化（打破迷思）

• Shopify 在极高交易量下跑模块化单体，靠严格内部边界 + 只把少数高负载模块抽成独立服务；
• Stack Overflow 用少数服务器 + 单体扛住数十亿请求；
• Uber 后来把数千微服务做「合并回更粗粒度域服务」的反向治理，正是过度拆分后回调的典型。

结论：单体扩得比你以为的远得多。拆分的理由应该是「团队/扩展/合规压力」，而不是「业务会长大」。

四、分布式单体陷阱：比单体更糟

有一种「伪微服务」，集合了微服务的全部成本和单体零收益——分布式单体（Distributed Monolith）：

1. 共享数据库：多个服务读写同一库表。你得到微服务的网络成本，丢掉独立部署与数据隔离收益。规则是 database-per-service——两个服务若真需要共享库，说明其中一个还没真正成为独立服务。
2. 同步链式调用：A→B→C→D 串成一条请求才能完成，任何一环挂全部挂，且延迟叠加。正确做法是事件驱动异步解耦（Kafka / NATS / SQS），下游出问题时上游能优雅降级，代价是业务要显式处理最终一致。

一句话识别：如果你的「微服务」必须协调一次发布才能部署，那你建的不是一个微服务，是一个带多余网络跳数的单体。

拆之前先用 DDD 限界上下文（Bounded Context）划清边界，物理拆分是结果不是起点。

五、拆分决策框架：信号清单 + 五问

5.1 什么时候才该拆（至少同时满足两条）

1. 资源不对称：某模块需要 10× 于其余部分的计算/扩展曲线（如媒体处理管道、搜索索引、GPU 推理）。
2. 团队阻塞：两个及以上团队在同一代码库上互相等发布。
3. 合规隔离：某模块有 PCI / HIPAA 等强隔离要求，需限定暴露面。
4. 工程规模：代码库上的工程师数越过 ~50，跨域合并冲突成为常态。

四条都不满足？拆了只会增加网络延迟和运维面，没有可量化收益。

5.2 五问框架（Run your project through these）

5.3 康威定律：边界跟着团队走

拆，就按团队边界拆，不是按技术整洁度拆。亚马逊「两披萨团队」（6–10 人，含 PM/设计/on-call）是实用经验值：低于它你养不起一个服务，高于它你就有协调问题。一个服务没人认领 = 没人维护；一个服务两团队共养 = 协调开销抵消拆分收益。

5.4 不该拆的理由（简历驱动开发清单）

• 「我们在成长」——单体比你以为的更能扛；
• 「我看了个微服务的演讲」——演讲有幸存者偏差；
• 「简历上想写微服务」——这是最贵的镀金。

六、怎么拆得好：增量路径

真正要拆时，别「大爆炸重写」，走增量抽取：

1. 定边界：选一个早已干净分离的模块（Spring Modulith 已帮你标好）。
2. 立契约：先写 API spec + 针对它的测试。
3. 双跑阶段：同一份代码，既在单体里跑、又作为服务部署。
4. 切流量：把该模块的调用慢慢导到服务，监控（C2 的 trace 会立刻告诉你链路对不对）。
5. 移除：确认稳定后，从单体里删掉该模块。

模块化单体让这一步只是「重构」而非「重写」——这就是前面强调 enforced boundaries 的回报。

数据 ownership 优先于服务边界：最干净的服务边界围绕「数据所有权」——订单服务独占 orders 表，别人只能通过它的 API 读写。共享库是最糟耦合。

异步优先：同步调用会制造分布式单体；用事件总线 + Saga/Outbox 处理跨服务的业务正确性（金融交易、库存预留等强一致场景必须显式建模）。

七、平台工程：网格与可观测的「运营心脏」

回到 C1/C2。网格（安全/流量）和可观测（Trace/Metric/Log）是微服务的硬成本。如果一个组织没有平台团队来统一买单，这些能力就会散落到每个业务组，重复造轮子、标准不一、没人维护。

2026 的务实做法是平台工程（Platform Engineering）+ 内部开发者平台（IDP，如 Backstage 类）：

• 网格、可观测、流水线、密钥管理由平台组一次性建好，业务组通过 Golden Path 自取；
• 没有平台团队，就别上微服务——这是前面所有「税」的最终归宿。

这也解释了为什么 C1 强调「小团队先别上网格」：你还没到需要为 N 个服务统一治理的规模，提前上网格只是提前交税。

八、与全系列的衔接（这是「适度」的全局意义）

C3 不是孤立的一课，它把前面 A/B/C 的线索收束成一个统一口径：

• 回扣 A 线（Java 后端演进）：A1 虚拟线程 让单体在高并发下也能跑出异步性能；A3 GraalVM 原生镜像 让单体/模块启动 <50ms、内存 30–80MB——单体也能很「云原生」，不因「想弹性扩缩」就非得拆。
• 回扣 B 线（AI 工程化）：这是最妙的一层——
  • B4 多智能体 Control Plane 里我断言「多智能体 = 新型微服务」。那套服务粒度问题在这里完全复用：Agent 拆太细 → 协调税（bag-of-agents 错误放大 17×）、telephone-game 失真；拆太粗 → 一个 Agent 干所有事、不可独立扩展。Agent 的「限界上下文」同样该按业务域划。
  • B6 AI 护栏与可观测 的护栏网关、MCP Server 本质上就是「围绕 AI 能力的微服务边界」——database-per-service 对应「每个工具/数据源独占上下文」，共享上下文正是 MCPTox 投毒的温床（见 B3）。
  • B5 模型路由 的 Model Gateway 是「按能力而非按团队」的服务拆分范例。
• 回扣 C1/C2：网格和可观测是「服务数 × 复杂度」的函数。服务越少，税越低；但你一旦有服务，这些能力就该由平台统一提供。

一句话：架构师的核心功力，不是「会不会拆」，而是「知道什么时候不拆、什么时候该拆、拆出来怎么治理」。

九、决策表与落地清单

9.1 选型决策表

9.2 落地清单（从今天起）

• 把单体按 DDD 限界上下文分模块，用 Spring Modulith / lint 强制边界（CI 失败拦截）；
• 模块间优先走应用事件，预留异步 seam；
• 严禁跨模块直连数据库、严禁跨模块 import internal；
• 监控四个拆分信号（资源不对称 / 团队阻塞 / 合规 / 规模 ~50），用数据触发拆分，不用感觉；
• 若拆服务：先立契约 + 双跑 + 切流量 + 移除，配 C2 的 trace 验证；
• 服务间走事件驱动 + Saga/Outbox 处理强一致；
• 网格（C1）与可观测（C2）由平台团队统一建，业务组走 Golden Path 自取。

9.3 常见误区（凯哥踩坑/见过坑的总结）

1. 「拆分 = 架构先进」——错，拆分是负债，收益需 measurable；
2. 「共享一个库方便」——这是分布式单体，迟早还债；
3. 「先拆再想边界」——顺序反了，先 DDD 后物理拆；
4. 「同步调用链更直观」——直观但脆弱，迟早被一次下游抖动教做人；
5. 「上了 K8s 就该上网格」——见 C1，小团队先别。

小结

2026 年架构师对待微服务的态度，从「信仰」回归「算账」：微服务税是真实的、近似线性的；只有当团队协调或独立扩展压力盖过它时，拆分才划算。 模块化单体是默认起点，enforced boundaries 是它区别于大泥球的关键，Spring Modulith 是 Java 生态的趁手工具。拆要增量、按康威定律、由平台团队统一买单基础设施。

而这篇文章最值得记住的一点是：B 线的多智能体、护栏网关、MCP Server，本质都是「AI 能力的服务粒度问题」——你在 C3 建立的选型口径，直接平移到 B4 的 Agent 编排治理上。架构的底层逻辑，从来都是通的。

下一篇（C4 · Serverless 与 Java 冷启动）：把 C 线收尾。当业务真的出现「流量稀疏、峰谷剧烈」的模块，Serverless 是比常驻微服务更省的归宿；但 Java 的冷启动曾是死穴——A3 的原生镜像正是解法。C4 把这条线彻底打通，C 线收官后切入 D 线（融合蓝图）。