第2章：拆分策略（Splitting Strategies）

一、导读

第2章讲解如何将系统拆分为微服务。这是微服务架构中最困难也最重要的决策。

拆分粒度直接决定了微服务架构的成败。拆得太粗，失去了微服务的优势；拆得太细，运维成本难以承受。

如何确定服务边界？

限界上下文是什么？

数据所有权如何划分？

拆分粒度如何把握？

限界上下文（Bounded Context）来自领域驱动设计（DDD），是确定服务边界的核心工具。

电商系统的限界上下文：
- 商品目录（Catalog）：管理商品信息
- 库存（Inventory）：管理库存数量
- 订单（Order）：管理订单生命周期
- 支付（Payment）：处理支付
- 物流（Shipping）：管理配送
- 用户（User）：管理用户信息

按照业务能力（business capability）来拆分服务：

零售业务能力图：
├── 商品管理
│   ├── 目录管理 → 商品服务
│   └── 库存管理 → 库存服务
├── 订单管理
│   ├── 下单 → 订单服务
│   └── 退款 → 退款服务
└── 支付管理
    └── 支付处理 → 支付服务

按照子域（subdomain）来拆分：

核心域：订单管理、商品管理
支撑域：用户管理、库存管理
通用域：通知、日志

每个服务拥有自己的数据存储：

反模式：共享数据库
- 多个服务访问同一个数据库
- 服务之间通过数据库耦合

正确做法：数据库 per 服务
- 每个服务有自己的数据库
- 服务之间通过 API 通信

太粗（反模式）：
- 一个服务包含所有业务逻辑
- 本质上是分布式单体

太细（反模式）：
- 每个实体一个服务
- 运维成本过高

合适：
- 一个限界上下文一个服务
- 一个团队能维护的规模

拆分前（单体）：
- 一个应用，一个数据库
- 10 个模块，50 张表

拆分后（微服务）：
- 商品服务：商品 CRUD、搜索
- 库存服务：库存管理、预留
- 订单服务：下单、状态管理
- 支付服务：支付处理、退款
- 用户服务：注册、登录、权限
- 通知服务：邮件、短信、推送

服务拆分是微服务架构的核心决策。使用限界上下文确定边界，按业务能力或子域拆分，每个服务拥有自己的数据，拆分粒度要适中。

如何识别限界上下文？

拆分粒度如何权衡？

如何处理跨服务的数据一致性？

共享数据库有什么问题？

如何从单体逐步拆分？