| 单体 | 只有一个进程，不需要考虑跨进程的各种问题。追求尽量不出错。 | 简单 | 项目初期快速上线 | 功能间难以自治和隔离，无法做到异常隔离，资源隔离。无法做到针对部分功能的单独维护（升级、停止、扩容）。无法支持异构系统。 | 不易拆分：实际上都是有纵向分层+横向分层。纵向拆分常可分为表示层+业务层+持久层+数据库层。横向拆分可以将不同功能放置不同模块。且也可以使用负载均衡器+多个单体副本提供面向流量的扩展性 |
| SOA | 基于SOAP的远程调用协议，依靠SOAP协议簇完成服务的发布、注册和治理；使用企业事务总线的消息管道完成子系统的之间的交互；使用服务数据对象来访问和表示数据；使用服务组件架构来定义服务封装的形式和服务运行的容器 | 每个子系统能单独部署、运行和更新； 统一的规范和约束来解决分布式下的各种问题。 | 可以满足多个大型复杂异构系统之间的交互 | SOAP协议以及上层的企业事务总线、服务组件架构、服务数据对象过于严格的规范带来的复杂性只有部分专业人员能够掌握，不具有普适性 | |
| 微服务 | 围绕业务能力构建，组织架构和产品功能对应，避免高成本的跨团队协作。分散治理，服务开发团队直接对服务质量负责，不受外界干预地掌握服务各个方面的权利。通过服务而不是类库来构建组件，类库本质上还是在调用者进程中执行。产品化思维，开发团队不仅关注开发，还要关注产品如何运作，用户如何反馈，调用方如何使用，关注产品的整个生命周期。数据去中心化，不同的微服务的数据提倡按照领域分散管理、更新、维护 和存储。强终端弱管道，只有基本的通信能力，额外的能力在终端实现，反SOAP和ESB的设计。容错性设计，接受服务总是会出错，需要进行错误检测，出错时隔离，恢复后联通。演进式设计，承认服务会被淘汰。基础设施自动化，CI/CD的发展 | 更加自由的架构风格，没有统一的规范和约束，可以自定义各种实现来解决分布式中的问题，按需选择解决哪些分布式问题。 | 复杂系统 | 架构者要求比较高，需要掌控的知识点比较多。 | |
| 后微服务 | SideCar+服务网格等技术，在微服务的基础上，将注册发现、跟踪治疗、负载均衡、通信传输等分布式问题解决方案从应用程序下沉到K8S | 业务与技术完全分离，远程和本地完全透明 | | | |
| 无服务 | 简单。后端设施即服务，数据库、消息队列、缓存、日志等作为技术组件运行在云中。函数即服务 | 相对意义的无限性能，不考虑技术组件，不考虑部署 | | 函数冷启动，耗时会比较长 | |
