微服务架构设计

为什么需要拆分单体服务

一个典型的 Go 单体后端:所有业务逻辑在一个 binary 里,共享一个数据库,一次 CI/CD 部署整个应用.
早期团队小,迭代快,运维简单.但问题出在规模上升之后:

微服务定义

先给一个工作定义:

关键特征:

单体不止一种形态

在讨论"拆分"之前,先识别你手上的单体类型--不同形态的药方不同:

经典单体(Single Deployment Unit)

所有代码编译成一个 binary / 一个 WAR 包部署.内部可能有模块划分(package / module),但运行时是一个进程.

分布式单体(Distributed Monolith)

服务虽然物理拆开了,但因为共享数据库,同步链式调用,联合发布,实际上没有获得独立部署的能力.这是最糟糕的状态--拥有分布式的全部代价,却没有微服务的任何收益.

模块化单体(Modular Monolith)

单一部署单元,但内部有清晰的模块边界(独立 DB schema,接口契约,显式依赖声明).这是许多团队的最优中间态--享受单体的简单运维,同时为未来可能的拆分保留边界.

┌────────────────────────────────────────────────────────────┐
│                     模块化单体                              │
│                                                            │
│  ┌──────────┐   接口调用   ┌──────────┐   接口调用   ┌──────────┐  │
│  │  订单模块  │ ─────────→ │  支付模块  │ ─────────→ │  库存模块  │  │
│  │ (私有表)   │            │ (私有表)   │            │ (私有表)   │  │
│  └──────────┘            └──────────┘            └──────────┘  │
│                                                            │
│                      共享部署单元                            │
└────────────────────────────────────────────────────────────┘
         ↓ 未来可独立拆出
┌──────────┐     gRPC     ┌──────────┐    事件    ┌──────────┐
│  订单服务  │ ──────────→ │  支付服务  │ ────────→ │  库存服务  │
└──────────┘             └──────────┘           └──────────┘

用 DDD 划定服务边界

微服务拆分最大的难题不是技术,而是在哪里画线.领域驱动设计(Domain-Driven Design,DDD)给出了最实用的思维框架.

限界上下文(Bounded Context)

核心概念:每个限界上下文是一个自洽的业务领域,内部的术语和规则在上下文内有明确含义,出了边界可能语义不同.

实操步骤:

1. 事件风暴(Event Storming):召集业务方和开发,在白板上列出所有业务事件("订单已创建","支付已完成","库存已扣减"...)
2. 聚合命令和事件:将相关事件归入同一个聚合(Aggregate),聚合是事务一致性的边界
3. 识别上下文边界:当两组事件之间的交互变成"通知"而非"直接调用"时,它们大概率属于不同上下文
4. 上下文 = 服务候选:每个限界上下文对应一个或一组微服务

上下文映射(Context Mapping)

服务之间不是孤岛--它们必须协作.DDD 定义了几种典型的上下文间关系:

拆分策略与粒度

常见拆分维度

康威定律(Conway's Law)

康威定律不是建议,是物理定律级的观察.实践中的含义:

• 如果你的组织是按"前端组 / 后端组 / DBA 组"划分的,你很难做出围绕业务能力的微服务--因为每个功能都要跨三个组协调
• 反向操作(逆康威定律):先设计你想要的系统架构,再按这个架构调整团队结构
• 一个服务的最佳 owner 数量 = 一个团队(5-9 人).超过这个数字通常意味着服务太大了

粒度判断:太粗 vs 太细

常见反模式

反模式一:共享数据库

多个服务直接读写同一个数据库的同一张表.

为什么有害:

• 数据库 schema 变更影响所有服务--耦合回来了
• 无法独立扩缩容数据层
• 数据所有权不清,谁都能改,没人敢动

正确做法: 每个服务拥有自己的 schema(甚至独立数据库实例).需要对方数据时,通过 API 或事件获取,不直接查表.

反模式二:同步链式调用

A → B → C → D → E,链路上任何一环超时,整个请求失败.

为什么有害:

• 可用性 = 各环节可用性的乘积(99.9%5 = 99.5%)
• 延迟 = 各环节延迟之和
• 任何一个下游的部署或故障都影响上游

正确做法: 异步解耦(事件驱动),并行调用,缓存,设置合理超时 + 降级.

反模式三:分布式单体

前面已经提到--物理拆分但逻辑耦合.核心症状:不能独立部署.

检测方法: 问自己"我能不能只发布 A 服务而不通知其他团队?"如果答案是"不能"--你有一个分布式单体.

反模式四:按技术层拆分

把"数据访问层","业务逻辑层","API 层"各自拆成独立服务.

为什么有害: 一个业务需求改动要同时修改 3 个服务--拆分没有减少协调成本,反而增加了网络调用和部署风险.

正确做法: 按业务能力纵向拆分,每个服务内部自己包含 API → 业务逻辑 → 数据访问的完整栈.

┌───────────────────────┐
│ 按技术层拆分(错误)            │
├───────────────────────┤
│  • direction TB        │
│  • API 层服务             │
│  • 业务逻辑服务              │
│  • 数据访问服务              │
│  • API --> BIZ --> DAL │
└───────────────────────┘
┌─────────────────────┐
│ 按业务能力拆分(正确)         │
├─────────────────────┤
│  • direction TB      │
│  • 订单服务
API+逻辑+数据 │
│  • 支付服务
API+逻辑+数据 │
│  • 库存服务
API+逻辑+数据 │
└─────────────────────┘

何时不该拆微服务

这可能是整篇笔记最重要的一节.微服务有真实的代价:

以下场景建议保持单体(或模块化单体):

• 团队 ≤ 5 人
• 产品处于 MVP / 探索期,业务边界还不清晰
• 没有 K8s / 容器化基础设施,运维能力不足
• 不存在独立部署的需求(所有功能总是一起发布)
• 核心路径对延迟极度敏感(每多一跳网络增加 1-5ms)

从单体到微服务的演进路径

如果决定要拆,不要一次性重写,而是渐进式拆分(Strangler Fig Pattern):

┌────────────┐
│ 第一步:识别边界   │
├────────────┤
│  • 单体应用     │
└────────────┘
┌─────────────────────────────┐
│ 第二步:模块化                     │
├─────────────────────────────┤
│  • 模块化单体
清晰接口 + 独立 schema │
└─────────────────────────────┘
┌────────────┐
│ 第三步:逐步抽取   │
├────────────┤
│  • 服务 A     │
│  • 缩小的单体    │
└────────────┘
┌────────────────────────┐
│ 第四步:持续演进               │
├────────────────────────┤
│  • 服务 B                 │
│  • 服务 C                 │
│  • MOD2 --> |"继续拆"| MS3 │
└────────────────────────┘

绞杀者模式(Strangler Fig Pattern)

名字来自热带的绞杀榕--种子落在宿主树上,缓慢包裹宿主,最终取而代之.

应用到迁移中:

1. 在单体前面加一个路由层(API Gateway / Nginx / Envoy)
2. 新功能直接写成新服务,流量通过路由层导入
3. 逐步迁移旧功能:从低风险模块开始,迁移完后把流量切到新服务
4. 旧单体逐渐缩小,直到只剩空壳(或彻底下线)

数据所有权与数据库拆分

微服务最难的不是代码拆分,而是数据库拆分.代码拆完可以独立部署,但如果还共享数据库,本质上没有解耦.

Database per Service 原则

每个服务拥有私有数据存储,其他服务不能直接访问--只能通过该服务的 API 或发布的事件获取数据.

落地方案有几个层次:

拆库后的 JOIN 问题

单体里一个 SQL JOIN 就能拿到的数据,拆分后怎么办?

• API 组合:在上层服务里调两个下游 API,在内存中组装(适合低频查询)
• 数据冗余:通过事件同步一份只读副本到本地(适合高频查询)
• CQRS:写入走各自服务,查询走专门的读模型(适合复杂报表)

服务间通信概览

微服务之间的通信方式是架构设计的核心决策.整体分为两大类:

下一篇将深入讲解 gRPC 同步通信,第三篇讲异步消息--两种模式互补使用是微服务通信的最佳实践.

真实世界的微服务长什么样

以一个电商系统为例,展示合理的服务划分:

┌─────────────┐
│ API Gateway │
└─────────────┘
       │
       ▼
┌──────────┐
│   用户服务   │
└──────────┘
┌──────────┐
│   订单服务   │
└──────────┘
      │
      ▼
┌──────────┐
│   商品服务   │
└──────────┘
┌──────────┐
│   搜索服务   │
└──────────┘
┌──────────┐
│   支付服务   │
└──────────┘
┌──────────┐
│   库存服务   │
└──────────┘

注意几个设计决策:

• 订单 → 支付 / 库存:同步 RPC(创建订单时需要立即确认扣款和锁库存)
• 订单 → 通知 / 数据分析:异步事件(不需要等它们处理完)
• 支付 → 订单:支付结果通过事件回调(解耦支付渠道的异步性)
• API Gateway 统一对外,内部服务之间直接 gRPC 通信