单体 VS 微服务
一、单体(monolithic)
单体架构的优点：
易于部署 – 一个可执行文件或目录使部署更容易.
开发 – 使用一个代码库构建应用程序时，开发更容易.
性能 – 在集中式代码库和仓库中, 一个API能够执行在多个微服务中多个API执行的相同功能(即微服务架构功能存在冗余，比如每个微服务都有登录模块)。
简化测试 – 由于单体应用程序是一个单一的集中式单元，因此可以比分布式应用程序更快地执行端到端测试.
易于调试 – 所有代码都位于一个位置，更容易跟踪请求并找到问题.
单体架构的缺点：
较慢的开发速度 – 大型的单体应用程序使开发更加复杂和缓慢.
可扩展性 – 您无法扩展单个组件.
可靠性 – 如果任何模块出现错误，都可能影响整个应用程序的可用性.
技术采用的障碍 – 框架或语言的任何更改都会影响整个应用程序，使更改通常昂贵且耗时.
缺乏灵活性 – 单体应用受到单体应用中已经使用的技术的限制.
部署 – 对单体应用程序的小改动需要重新部署整个单体应用程序.
二、微服务(microservices)
微服务的优点：
敏捷性 – 促进与经常部署的小型团队合作的敏捷方式.
灵活扩展 – 如果微服务达到其负载能力，该服务的新实例可以快速部署到随附的集群以帮助缓解压力.
持续部署 – 更频繁和更快的发布周期，以前每周发布一次更新，现在每天发布大约两到三次.
高度可维护性和可测试性 – 团队可以试验新功能并在出现问题时回滚。这样可以更轻松地更新代码并加快新功能的上市时间。此外，很容易隔离和修复单个服务中的故障和错误.
可独立部署 – 由于微服务是单独的单元，它们允许快速轻松地独立部署各个功能.
技术灵活性 – 微服务架构允许团队自由选择他们想要的工具.
高可靠性 – 可以为特定服务部署更改，而不会威胁到整个应用程序的崩溃.
微服务的缺点：
开发蔓延 – 与单体架构相比，微服务增加了更多复杂性，因为多个团队在更多地方创建了更多服务。如果开发蔓延没有得到妥善管理，则会导致开发速度变慢和运营性能下降.
基础设施成本 – 每个新的微服务都可以有自己的测试套件、部署手册、托管基础设施、监控工具等成本.
缺乏标准化 – 如果没有通用平台，语言、日志标准和监控可能会激增.
缺乏明确的所有权 – 随着更多服务的推出，运行这些服务的团队数量也在增加。随着时间的推移，很难知道团队可以利用的可用服务以及与谁联系以获得支持.