30、微服务架构：从单体应用到细化开发的转型之路

微服务架构：从单体应用到细化开发的转型之路

1. 宏服务：单体应用的新形态

在软件开发中，虽然宏服务并非严格意义上的微服务，但它们几乎可以被当作微服务来处理，并且能带来许多相似的益处。其中最实用的一点是，我们常常可以将单体应用的各个部分纳入微服务部署管道。

1.1 宏服务的识别与划分

要将单体应用拆分为宏服务，首先需要分析其结构，以确定系统内的粗粒度边界。这些边界主要有两种类型：原始设计的遗留部分，以及反映组织架构的自然边界。不过，这些边界往往并不清晰，识别起来也比想象中困难，此时代码结构分析工具能派上用场。

例如，在单体应用的类结构中，支付提供商集成可能已经相对独立，因为最初的开发者希望能够方便地更换提供商。我们可以将这部分提取出来，作为一个独立的进程，并像部署其他微服务一样进行部署。

推荐使用 Structure101 这类工具来辅助识别边界，但需注意，使用时要确保其能准确反映系统的依赖关系。

1.2 宏服务提取的时机与策略

在迁移项目中，提取宏服务的时机至关重要。在全新的微服务基础设施准备好之前，提取宏服务意义不大，因为在旧基础设施上增加部署复杂性并不会带来太多收益。

在项目早期，我们可以着手强化边界。在单体应用上实现功能时，投入一些精力进行代码重构，以解耦代码结构。即使开始提取宏服务后，这项工作也应持续进行。因为团队在处理单体应用相关代码时，最适合进行重构，这样可以利用对单体应用内部复杂机制的临时了解，降低宏服务提取的成本。

当微服务基础设施就绪后，就可以开始进行宏服务提取。每次只尝试提取一个宏服务，以控制工作的复杂性。即使团队规模较大，也不要同