Web应用程序架构的比较
| 架构 | 技术优势 | 技术挑战 | 团队优势 | 团队挑战 |
| 单体 |
低延时 开发简单 没有重复的模型/验证 |
伸缩 由于代码库过大引起的复杂度 |
特性内沟通的开销低 |
失败的恐惧 特性间沟通的开销大 |
| 前端+后端 |
能够单独扩展前端和后端 将业务逻辑与表示分离 能够复用后端并构建多个前端 |
由于网络调用引起的复杂度 |
专业性 能够更快地迭代前端 通往面向服务架构的阶梯 |
沟通开销 知识壁垒 前后端开发互相阻塞 |
| 面向服务架构（SOA） |
细粒度的伸缩性 隔离 封装 |
运维开销 延时 服务发现 跟踪/调试/日志记录 热点服务 API文档，客户端 集成测试 数据碎片 |
自治 |
自治程度的困境 重复工作的风险 |
| 微服务 | 与面向服务架构一样，只会更多 |
与面向服务架构一样，只会更多 隐性耦合的风险 |
由于有界上下文会产生更多的自治 |
意味着需要DevOps 需要一个平台团队 需要思维方式的重要切换 |
一、单体
好处：
- 如果数据库查询已经进行了不错的优化，网站应该相当快。
- 开发相对简单，因为开发人员无需担心与调用远程API相关的各种挑战。
缺点：
- 只能通过部署整个应用程序的多个副本来扩展应用程序处理负载的能力
二、前后端分离
好处：
- 通过将业务逻辑（应用程序的内核）与表示层分离，代码应该更容易理解，应用程序更易于变更。这两个服务在概念上（和物理上）通过API隔离了，因此只要接口不变，任何一方都可以自由地进行内部更改。
- 用后端暴露API的另一个好处是它可以供多个前端使用。
- 独立地开发前后端意味着每个服务的开发都可以按照自己的步调进行。
缺点：
- 团队之间的某些阻塞几乎是不可避免的。
三、面向服务
优点：
- 强调独立性的面向服务架构，服务必须解耦，以便可以随时部署新的版本，而不会影响任何其他服务。
特点：
- 运维开销：一个面向服务架构可能包括数十个甚至数百个服务，以及各种数据存储和消息队列，所有这些都需要进行配置、部署、监控和维护。
- 延迟：在面向服务架构中，一个用户请求可能导致数十个服务间API调用。这可能包括链式调用，即服务A调用服务B，服务B调用服务C，等等。如果没有仔细的应用程序设计，这些请求的延迟会快速叠加，最终导致很延迟的用户体验。
- 服务发现：有几十种不同的服务，每种服务都有多个实例运行，因此需要一种容易的方法来找到它们想要通信的那个服务。
- 跟踪，调试，日志记录：当应用程序出现问题时，想要弄清楚问题所在是相当困难的。
- 热点服务：可能存在一些服务，几乎所有其他服务都依赖于它们。用户认证/身份服务是常见的例子。服务A被传递一个用户ID，使用认证服务来查找用户，执行一些处理，然后将用户ID传递给服务B，服务B也与认证服务联系，等等。这些热点服务最终可能接收大量的流量，因此可能成为单点故障和扩展的瓶颈。
- API文档和客户端：通过这么多的服务将API彼此暴露，团队将花费大量时间为这些API编写文档和客户端。它们需要保持最新，以保证有用。
- 集成测试：检查所有服务之间能否正确交互，以及应用程序能否作为一个整体运行，可能非常困难。
- 数据碎片：面向服务架构可能有许多小的数据库，这会使报表和数据分析变得很困难，因为你需要从多个数据库获取数据，将其压缩为通用格式，并将它们连接在一起。
- 平台团队应为所有团队编写一个通用库以供所有团队使用。
参考文献：人民邮电出版社《遗留系统重建实战》
