微服务
单体架构
在项目早期通常项目较小，开发人员较少，因此存在一些优势：
- 开发、测试简单，只需要构建一个模块。
- 易于部署，只需要发布一个模块。
随着时间的推移，项目会不断的加入新功能，导致代码库急剧膨胀，并且会有越来越多的人员加入到团队中，使得单体架构的缺陷被放大：
- 复杂的代码，难以维护。随着代码量的增加会导致整个项目越发难以理解，每次更改都会让代码更难以理解，导致功能交付越来越困难。
- 开发效率低。由于项目过大，在每次编译、调试或启动项目时都比较耗时。
- 发布周期长。多个团队向同一个代码库提交代码，构建结果往往处于不可交付的状态，当采用多分支开发模式时，又带来了痛苦而漫长的分支合并的过程。此外，由于项目的复杂度，导致测试周期也被拉长，因为任何的改动都可能牵一发而动全身。
- 扩展困难。不同的功能模块对环境有不同的要求，这就要求环境需要满足所有模块的需求，比如CPU算力、内存容量等。
- 缺乏故障隔离。代码缺陷可能导致所有实例都不可用，比如内存泄漏。
- 难以切换技术栈。当需要使用新版本的依赖或切换技术栈时，需要承担牵一发而动全身的风险，又或者需要对项目进行完全重写，这需要耗费大量的人力。