29、从单体架构到微服务架构：转型之路

从单体架构到微服务架构：转型之路

在当今的软件开发领域，从单体架构向微服务架构的转型是一个热门话题。下面将详细探讨如何从模块化单体架构过渡到微服务架构，以及如何处理大泥球单体架构向微服务架构的分解。

1. 模块化单体架构现状与挑战

模块化单体架构有两种构建方式：一是从一开始就构建模块化单体；二是通过逐步重构大泥球单体架构来恢复其模块化。以一个名为汽车保险系统的单一部署容器为例，其目标是形成八个上下文模块。然而，目前系统出现了一些新问题。

有五个团队负责八个子域和上下文模块的开发。其中，风险（Risk）和费率（Rate）模块变化尤为频繁，业务规则、精算处理算法和定价计算算法都在不断改变。而且，这两个模块因负载重、资源需求大，需要独立扩展。此外，公司计划扩展奖励（Rewards）服务，这意味着要将奖励模块从保单持有人账户（Policyholder Accounts）中分离出来。同时，定制的遗留计费子系统老旧，缺乏新的计费规则和支付选项，将被基于软件即服务（SaaS）的计费解决方案取代。

基于这些变化，需要从单体架构中提取以下上下文到微服务中：
1. 风险上下文（Risk Context）
2. 费率上下文（Rate Context）
3. 保单持有人账户上下文（Policyholder Accounts Context）
4. 奖励上下文（Rewards Context）
5. 计费上下文（Billing Context）

先对这五个业务能力进行逐步优化，有助于团队以较低风险积累经验。

2. 上下文模块提取过程

最初的任务是一次提取一个上下文模块。在较