27、单体应用向微服务应用的转换

单体应用向微服务应用的转换

1. 不同部署方案的迁移挑战

在将应用迁移到微服务架构时，不同的部署方案面临着不同的挑战。具体如下：
|部署方案|挑战|解决方案|
| ---- | ---- | ---- |
|仅本地部署|部署在客户基础设施上，有不同版本，缺乏完全控制权|仅对最新版本提供迁移服务，迁移期间仅允许安全和关键修复，不提供新功能|
|云与本地混合部署|可能需要同步迁移，本地客户可能有定制化需求|先迁移云解决方案到微服务，再在本地复制|
|从本地部署转向云部署|现有代码可能是遗留技术栈，设计不够灵活|采用增量迁移，先分离 UI 应用并提供外部 API，再迁移服务器端代码|

2. 迁移前的代码准备

如果现有代码不是模块化的或者包含大量遗留代码，建议先进行重构，使其模块化。重构应逐模块进行，在迁移到纯微服务之前，尽可能分解和重构代码。

3. 成功迁移的方法和关键

3.1 增量迁移

应逐步将单体应用转换为微服务，而不是一次性迁移整个代码。这可以降低风险和成本，避免因一次性迁移导致的高失败概率。可以将代码分解为不同模块，逐个进行转换。对于耦合紧密、难以重构的模块，可考虑重写，但不建议从头开始编写整个解决方案。

3.2 流程自动化和工具设置

微服务环境需要流程自动化，应具备自动化的持续集成（CI）和持续部署（CD），并实施测试自动化。如果 CI/CD 管道中尚未进行交付物的容器化，应进行该操作，以确保新开发的微服务能够成功集成到现有系统或与其他新微服务集成。同时，应在首次微服务转换开始之前或并行设置服务发现、服务网关、配置服务器或任何基于事件的