6、微服务架构：建模与集成的关键要点

微服务架构：建模与集成的关键要点

1. 微服务拆分的经验教训

在进行微服务拆分时，过早地将系统分解为微服务可能代价高昂，特别是在对业务领域还不够熟悉的情况下。曾经有团队将服务拆分后，发现需要进行大量更改，成本极高，最终又将服务合并回单体系统，经过一年时间深入理解业务边界后，才成功将单体系统拆分为边界更稳定的微服务。实际上，基于现有的代码库进行微服务拆分，往往比从头开始构建微服务更容易。

2. 基于业务能力建模

在思考组织内的限界上下文时，应关注这些上下文为业务领域其他部分提供的能力，而非共享的数据。例如，仓库可能提供获取当前库存列表的能力，财务上下文可能提供月末账目信息或为新员工设置薪资的功能。这些能力可能需要信息交换（共享模型），但如果仅关注数据，容易导致基于 CRUD（创建、读取、更新、删除）的贫血服务。因此，应先问“这个上下文能做什么？”，再问“它需要什么数据来完成这些操作？”。当将这些能力建模为服务时，它们就成为了通过网络向其他协作者暴露的关键操作。

3. 嵌套限界上下文

一开始，可能会识别出一些粗粒度的限界上下文，但这些上下文内部可能还包含更细粒度的限界上下文。以仓库为例，可以进一步分解为与订单履行、库存管理或货物接收相关的能力。在考虑微服务的边界时，可先从较大、较粗粒度的上下文入手，再根据嵌套上下文进行细分。

嵌套上下文可以对其他协作微服务隐藏，外部服务仍在使用仓库的业务能力，但可能并未意识到其请求实际上被透明映射到了两个或多个独立的服务。是否选择嵌套方式还是完全分离的方式，应基于组织架构来决定。如果订单履行、库存管理和货物接收由不同团队管理，它们可能适合作为顶级微服务；如果由一个团队管理，嵌套模型则