【背景知识】主流系统部署架构的异同

推荐阅读

当计算机软件从大型机转变为分布式系统（将程序和数据通过网络分布在多台计算机的做法叫“分布式”，C/S、B/S都是典型的分布式系统的物理架构）。与Web“一统江湖”的前端相比，后端的多样性更强，在系统部署架构层面先后涌现出4种构型：单体、RPC、SOA、微服务。时至今日，4种构型共存，各自有其适用的场景，没有绝对的优劣之分。为了适配这些部署架构，软件的系统架构也随之进行分化，最终形成了不同的“最佳实践”。为了便于理解，多数技术文章会使用部署架构的名称来命名与之支配的系统架构实践，如“微服务架构”同时用来指代微服务部署架构和适配微服务的系统架构最佳实践。虽然部署架构与系统架构并没有一一对应的关系，但并不妨碍这种命名方式已经成为了主流。

• 单体架构：指按照调用顺序将应用分为表示层、业务层、数据访问层和数据库层，然后将这些层集成在一起，直接引用。因为单体架构通常采用MVC（模型、视图、控制器）设计框架，在部分书籍和文章中也被称为MVC架构

• RPC架构：RPC是远程调用（Remote Procedure Call）的缩写，在单体架构的基础上，实现前后端分离，前后端的耦合程度显著降低。将服务端的接口（即业务层）根据部署要求拆分部署到到若干服务器上，如将于第三方系统集成的能力部署在靠近第三方系统的服务器，前端应用通过远程调用这些接口实现完整的操作流程

• SOA：SOA是“面向服务的架构”（Service Oriented Architecture）的缩写，在RPC架构的基础上，强化服务端接口的复用性和规范性，如按照组件的思想对服务进行封装；将所有服务的提供方式统一为WebAPI，通过文档或ESB（企业服务总线，一种注册和调度服务调用的中间件）等手段，让应用层开发者可以准确定位到所需调用的服务端接口等。相比于RPC，SOA更像是一个指导思想，对具体的实现方式并没有严格的要求

• 微服务：微服务是SOA的一种实现方案，与传统的基于ESB的“中心化”SOA相比，微服务是去掉了ESB，采用更轻量化的协议（Restful）和部署方式（Docker容器），让服务端组件的粒度更细成为单一职责的“微服务”。微服务架构下，技术规范性被弱化了，每个微服务可以用最合适的技术栈开发，也可以按照自己的节奏实现敏捷交付

四种后端架构方式的对比如下：

简单总结如下：

• 单体架构通常用于个人开发简单的小型应用，虽然开发效率高，但可维护性偏弱

• RPC架构适合小型团队中型的开发企业级应用，开发效率略有下降，但可维护性高，技术管理较为容易

• SOA通常用于传统行业的大型集团企业（如政府和央国企），用开发效率的降低换来可管理性的提升，有被微服务架构取代的趋势

• 微服务架构才出现不久，配套的技术和方案快速发展，通常用于互联网应用开发，多数企业软件开发团队对其表达观望和尝试的态度

说明：

开发团队规模：低代码开发的团队比编码开发更小。小型低代码开发团队通常少于5人，中型团队在5-20人，超过20人即可认为是大型团队。以上人数均不含团队管理决策和公司级DevOps人员。低代码团队分工与技术能力模型

常见应用场景：部门/小组级应用指仅作用于部门或小组内部的应用，通常不会涉及企业核心业务；企业级应用是企业软件中最常见的场景，不论使用者的人数多少，只要涉及到企业的核心业务，或应用到多个部门的应用都是企业级应用；集团型应用在企业级应用的基础上增加了集团化管理相关的功能和更高的技术与运维要求。