将单体应用程序迁移到微服务

多年来，我处理过多个单体应用，并将其中一些迁移到了微服务架构。我打算写下我所学到的东西以及我从经验中用到的策略，以实现成功的迁移。在这篇文章中，我将以AWS为例，但基本原则保持不变，可用于任何类型的基础设施。

单体架构

单体架构是一个大型代码存储库，所有功能都在一个地方实现。随着应用程序功能和复杂性的增加，这使得它变得复杂且难以维护。代码存储库不仅包含支持相关功能的所有核心逻辑，还包含支持不相关功能的代码。即使是一个小错误修复或功能发布也需要测试才能完成应用程序。我遇到的主要痛点是：

1. 协作：有“n”个工程师在一个存储库上工作。因此，合并冲突的可能性很大，这会导致解决冲突而不是专注于核心开发带来不必要的负担，从而减慢了功能发布的速度。

2. Bug：随着时间的推移，关注点分离、代码质量和最佳实践都会逐渐消失。因此，很可能会引入不相关功能的错误。通常，我们对核心功能进行健全性测试，但会错过这些错误，或者发现自己惊讶地发现与遥远无关的更改的错误。

3. 生产时间：在单体系统中，由于各种因素，创新的步伐受到阻碍。即使有完整的CI/CD系统和所有测试，由于仓库和测试的规模，开发测试、集成测试等需要时间，发布到生产也需要时间。

4. 技术栈：单体系统在单一技术栈中实现，这限制了适应新兴技术的灵活性。此外，这也引入了学习曲线。

5. 故障隔离：单体系统将所有组件捆绑在一起，一个模块/组件的故障可能会导致整个系统故障。

6. 修复时间：有时，识别错误并修复它并不容易。由于不同的组件捆绑在一起，一个模块的更改可能会导致另一个模块出现问题。这会增加调试、修复并将补丁应用到生产的时间。

7. 可扩展性：在单体系统中，扩展就时间和成本而言并不总是容易的。由