微服务 vs 单体：2026 年该怎么选？

一句话结论：90% 的团队应该从单体开始，"模块化单体"是新的甜点位。微服务只在规模化后才需要。

背景

2026 年 6 月，Martin Fowler 发文《Monolith First in 2026》，重新引发微服务 vs 单体的讨论。

核心观点：

"微服务的成功案例几乎都从单体开始。模块化单体比微服务有 90% 的好处，且只有 10% 的复杂度。"

本文用真实数据深入探讨。

5 个常见误解

误解 1：微服务 = 可扩展

# 反例：拆分后反而更难扩展
单体：
  - 一个服务，一个数据库
  - 启动时间 5s
  - 一次部署搞定

错误拆分：
  - 6 个微服务
  - 6 个数据库
  - 跨服务事务复杂度爆炸
  - 每次"小改动"需要 3 个服务联动部署

误解 2：微服务 = 高可用

# 反例：分布式系统的故障模式反而更多
单体故障：1 类（进程崩溃）
微服务故障：
  - 网络分区
  - 雪崩（Cascading Failure）
  - 数据不一致
  - 服务发现失败
  - 配置漂移
  - 限流降级
  ...

误解 3：微服务 = 团队独立

# 现实：跨服务协作成本极高
服务 A 改了接口 → 服务 B、C、D 都得改
每个 PR 都涉及 3-5 个团队 review
协调会议比写代码时间还多

误解 4：微服务 = 技术异构

# 异构的真实成本
不同语言 = 不同工具链
不同数据库 = 不同运维
不同部署 = 不同 CI/CD

每加一种技术栈，团队认知负担 +30%

误解 5：微服务 = 适合大公司

# 反例：很多大公司回归单体
Amazon Prime Video：从微服务回退到单体（2023）
Istio / Dapr：尝试解决微服务复杂度，反而更复杂
Shopify：至今坚持模块化单体
Basecamp：强烈反对微服务

真实数据对比

开发效率

5 人团队，从 0 开始做电商 SaaS：

方案 A：单体（Next.js + Postgres）
  - 2 周 MVP
  - 3 个月完整产品
  - 1 人能维护

方案 B：微服务（4 服务 + K8s）
  - 4 周 MVP（被基础设施拖累）
  - 6 个月完整产品（多 2 个月）
  - 至少 3 人维护

运维成本

单体：
  - 服务器：1 台 $50/月
  - 监控：1 个工具
  - 部署：1 条命令
  - 总成本：$200/月（含备份）

微服务（4 服务）：
  - 服务器：4 台 $200/月 + K8s $500/月
  - 监控：3 个工具（Prometheus / Loki / Tempo）
  - 部署：Helm + ArgoCD
  - 总成本：$3000/月（15x）

故障恢复时间（MTTR）

单体故障 → 重启进程 = 5 秒
微服务故障 → 排查链路 + 修复 + 部署 = 30 分钟

什么时候用微服务

✅ 适合微服务的场景

信号	解释
团队 > 50 人	单体仓库冲突频繁
单体启动 > 30s	开发体验极差
明确的扩展需求	不同模块需要不同资源
服务边界清晰	已有多个独立业务线

❌ 不适合微服务的场景

场景	原因
团队 < 10 人	复杂度 > 收益
MVP / 早期产品	需求变化快，边界未定
性能敏感	跨服务调用增加延迟
强事务一致性	分布式事务难以实现

"模块化单体"是新甜点

核心思想

物理上：单体（一个进程、一个数据库）
逻辑上：清晰的模块边界（按业务切分）

模块边界设计

// src/modules/orders/index.ts
// 明确的 exports，控制依赖方向

export { createOrder } from './actions';
export { OrderService } from './service';
export type { Order, OrderItem } from './types';

// 不导出数据库访问层
// 不允许其他模块直接 import

// src/modules/payments/index.ts
// 严禁跨模块 import 内部实现

import { createOrder } from '@/modules/orders'; // ✅ 通过 public API

// import { db } from '@/modules/orders/db'; // ❌ 禁止

强制约束

// 使用 ESLint 规则
// .eslintrc.json
{
  "rules": {
    "no-restricted-imports": ["error", {
      "patterns": [
        {
          "group": ["@/modules/*/db", "@/modules/*/internal/*"],
          "message": "不要直接访问其他模块的内部实现"
        }
      ]
    }]
  }
}

模块通信

// 模块间通过事件通信
// src/modules/orders/events.ts
export const orderCreated = createEvent('order.created', {
  orderId: z.string(),
  userId: z.string(),
  total: z.number(),
});

// src/modules/payments/handlers.ts
orderCreated.on(async (event) => {
  // 自动处理支付流程
  await processPayment(event.orderId, event.total);
});

优点

- 单体部署（简单）
- 模块清晰（可独立演进）
- 数据库共享（事务简单）
- 后期可拆分（如果需要）

真实案例

案例 1：Shopify（10 年坚定模块化单体）

• 月活 5 亿商家
• 单一 Rails 应用
• 模块化设计，新功能按模块加
• 2000+ 工程师，1 个仓库

案例 2：GitHub（早期模块化单体）

• 2008-2017：单一 Rails 应用
• 2018 后：开始拆分（团队 1000+）
• 拆分前用了 10 年单体

案例 3：Stack Overflow（极致单体）

• 1 个 SQL Server + 1 个 Web Server
• 服务全球开发者，月 PV 10 亿+
• 团队只有 50 人

案例 4：Segment（拆分失败回退）

2017：从单体拆为微服务
2020：发现维护成本太高
2020：合并回单体（保留部分微服务）
教训：过早微服务化是常见的架构错误

微服务拆分的 5 个前提条件

如果你的团队真的需要微服务，先确认这 5 点：

1. 有清晰的业务边界

不应该这样拆：
- user-service（用户）
- order-service（订单）
- product-service（产品）
- inventory-service（库存）
→ 4 个服务紧密耦合，每个改动都涉及多个

应该这样拆：
- billing-service（计费：独立业务线）
- recommendation-service（推荐：独立业务线）
- identity-service（认证：通用能力）
→ 服务间松耦合，独立演进

2. 有专业的 SRE 团队

微服务需要的能力：
- K8s / Service Mesh 运维
- 分布式追踪
- 日志聚合
- 监控告警
- 故障演练
→ 小团队没有这些能力 = 微服务 = 灾难

3. 团队规模足够大

Amazon 经验法则（"两个披萨原则"）：
- 每个团队 6-8 人
- 每个团队独立负责多个服务

反推：
- 10 人团队 → 1-2 个服务（单体或微服务都行）
- 50 人团队 → 5-8 个服务（模块化单体 + 微服务混合）
- 200 人团队 → 20+ 个服务（成熟微服务）

4. 有完善的 CI/CD

微服务 = 每天多次部署
单服务出 bug = 影响全局

CI/CD 要求：
- 每个服务独立 pipeline
- 自动化测试覆盖率 > 80%
- 灰度发布 / 回滚能力
- 监控指标完善

5. 有明确的可扩展需求

不是"未来可能扩展"
而是"现在就需要不同资源"

例：
- 推荐系统：需要 GPU
- 订单处理：需要高 CPU
- 静态资源：需要大存储

→ 这种场景才适合微服务

我的看法

2026 年的架构选择：

90% 团队（< 50 人）：
  → 模块化单体
  → 后期如需要，渐进式拆分

9% 团队（50-500 人）：
  → 模块化单体 + 少量微服务
  → 关键能力独立（如认证、计费）

1% 团队（> 500 人，或特殊场景）：
  → 完整微服务架构
  → 配合 Service Mesh

最重要的原则：

"永远从最简单的架构开始。只在遇到具体痛点时才升级。"

不要被"架构师"、"最佳实践"忽悠。大部分架构问题，其实是组织问题。

参考

• Martin Fowler - Monolith First
• Shopify Engineering Blog
• Segment 回退单体案例
• AWS 披萨原则

---

本文观点结合 Martin Fowler 2026 年新文 + 多个真实团队案例，2026 年 6 月整理。