架构对比
一、核心概念
1. 架构和系统的区别
XXX架构是「设计蓝图」，XXX系统是「落地的实体产物」，二者是**“设计理念”与“实际实现”**的对应关系，所有具备明确设计范式的技术方向，都能套用这个对应逻辑。
| 对比维度 | XXX架构 | XXX系统 |
|---|---|---|
| 本质定位 | 抽象的设计规范/架构风格，是系统的“骨架设计图” | 具体的软硬件运行实体，是架构落地后的“血肉成品” |
| 核心目标 | 解决“如何设计更合理”的问题，关注分层、组件关系、通信方式、扩展性等 | 解决“如何实现业务功能”的问题，关注稳定性、性能、业务逻辑落地 |
| 存在形式 | 文档（架构图、设计文档）、理念、规范 | 可运行的程序（服务进程、容器）、数据、硬件集群、配套工具链 |
| 举例 | 分布式架构、微服务架构、SOA架构、单体架构 | 分布式存储系统、电商微服务系统、银行SOA核心系统、单体CRM系统 |
典型例子：
分布式
分布式架构：定义“多节点协同、数据分布存储、远程通信”等设计原则；
分布式系统：基于这些原则构建的Hadoop分布式计算系统、Redis分布式缓存系统。
微服务
微服务架构：定义“按业务域拆分为独立服务、服务注册发现、API网关路由、分布式事务”等设计规则；
微服务系统：基于上述规则，用Spring Cloud + Nacos + Gateway 搭建的、包含订单/支付/库存服务的电商系统，是可以直接对外提供服务的运行实体。
SOA
SOA 架构：定义 “面向服务封装、企业服务总线（ESB）通信、跨技术栈服务复用、统一服务契约” 等设计规则；
SOA 系统：基于上述规则，用 Spring + Apache CXF + ESB 搭建的银行核心业务系统，是整合账户、信贷、清算、风控等异构服务的可运行实体。
单体（集中式）
- 单体架构：定义 “单一应用承载全业务功能、模块高度内聚耦合、集中式开发部署、共享数据库” 等设计规则；
- 单体系统：基于上述规则，用 Spring Boot + MySQL 搭建的小型企业 OA 系统，是包含用户管理、审批流程、考勤统计等所有功能的单进程运行实体。
2. 架构和系统相关的概念
架构风格（Architectural Style）
是架构的“分类模板”，是经过验证的、可复用的设计范式，定义了组件类型和组件间的通信规则。
例如：分布式、微服务、SOA、单体、分层（MVC）、事件驱动（EDA）都属于架构风格。
👉 关系：架构风格 → 指导具体架构设计 → 落地为对应系统。
部署模式
是系统的“运行形态”，描述系统如何部署到硬件资源上，决定了系统的高可用、扩展性能力。
常见类型：
- 单体部署：单个进程运行所有功能，适用于小型系统；
- 集群部署：多节点运行相同服务，通过负载均衡分发请求（如你熟悉的Nginx集群、微服务集群）；
- 分布式部署：多节点运行不同功能模块，通过网络协同（如分布式存储系统的分片部署）。
👉 关系：架构决定部署模式的选择（微服务架构必须用集群/分布式部署），部署模式影响系统的最终性能。
技术栈
是构建系统的“工具集合”，是架构落地的技术载体。
例如：微服务架构的技术栈通常包含 Spring Cloud（核心框架）+ Nacos（服务注册发现）+ Spring Cloud Gateway（网关）+ MySQL（数据库）+ Redis（缓存）。
👉 关系：架构是“选方向”，技术栈是“选工具”，系统是“用工具按照规范造出来的产品”。中间件
是架构的“核心组件”，是解决分布式/微服务架构痛点的关键技术，属于技术栈的核心部分。
日常接触的 Nacos、Gateway、RocketMQ（消息队列）、Seata（分布式事务） 都属于中间件。
3. 常见“架构-系统-技术栈-中间件-部署”对照表
| 架构风格 | 对应典型系统 | 核心技术栈 | 关键中间件 | 典型部署模式 |
|---|---|---|---|---|
| 分布式架构 （宽泛型，含微服务/SOA） | 1. 大数据处理系统（日志分析、数据仓库） 2. 分布式存储系统（对象存储、分布式文件系统） 3. 高并发后台系统（直播弹幕、秒杀平台） | 1. 后端语言：Java、Go、Python 2. 基础框架：Netty（网络通信）、Hadoop Common 3. 开发规范：RPC 通信标准、分布式一致性协议 | 1. 协调治理：ZooKeeper、etcd 2. 数据存储：HDFS（分布式文件）、Ceph（对象存储）、MongoDB（分布式文档库） 3. 任务调度：Elastic Job、XXL-Job 4. 通信框架：gRPC、Dubbo | 1. 分布式部署（多节点分工承载不同功能模块） 2. 集群部署（核心模块多副本冗余） 3. 混合部署（部分模块物理机+部分模块容器） |
| 微服务架构 （分布式架构的轻量化演进） | 1. 电商系统（订单/支付/库存/用户服务拆分） 2. 出行平台（派单/计价/用户/车辆服务） 3. SaaS 平台（多租户微服务拆分） | 1. 后端语言：Java（主流）、Go、Node.js 2. 核心框架：Spring Cloud、Spring Cloud Alibaba、Istio 3. 容器化：Docker、Kubernetes（K8s） 4. 服务网格：Envoy | 1. 服务注册发现：Nacos、Eureka、Consul 2. API 网关：Spring Cloud Gateway、Zuul 3. 分布式事务：Seata、Saga 4. 消息队列：RocketMQ、Kafka、RabbitMQ 5. 缓存：Redis 集群、Memcached 6. 链路追踪：SkyWalking、Zipkin | 1. 容器化部署（Docker 打包+K8s 编排） 2. 服务集群部署（每个微服务多副本） 3. 服务网格部署（Istio 管控流量） 4. 混合云部署（部分服务公有云+部分私有云） |
| SOA 架构 （面向服务的传统分布式架构） | 1. 银行核心业务系统（账户/信贷/清算服务） 2. 政务平台（多部门系统对接） 3. 大型 ERP 系统（用友/金蝶等） | 1. 后端语言：Java、.NET、C++ 2. 核心框架：Spring、Apache CXF（WebService） 3. 企业服务总线：Apache ServiceMix、Mule ESB | 1. 服务总线（ESB）：Apache Camel、IBM WebSphere ESB 2. 服务注册中心：UDDI、Nacos（兼容） 3. 数据转换：Apache Velocity、XSLT 4. 流程引擎：Activiti、JBPM | 1. 集中式部署（ESB 单独部署+各服务集群部署） 2. 混合部署（核心服务物理机+非核心服务虚拟机） 3. 跨域部署（多机房同步服务节点） |
| 单体架构 （对比参考） | 1. 小型管理系统（OA/CRM 小版本） 2. 内部工具平台（数据统计/权限管理） 3. 创业初期 MVP 产品 | 1. 后端语言：Java（Spring Boot）、PHP、Python 2. 基础框架：Spring Boot、Laravel、Django 3. 前端：Vue、React（前后端分离/不分离均可） | 1. 关系型数据库：MySQL、PostgreSQL 2. 缓存：本地缓存（Caffeine）、Redis 单机 3. 日志：Log4j2、SLF4J | 1. 单节点部署（测试/小型生产环境） 2. 主从部署（生产环境双节点热备） 3. 容器化单实例部署（Docker 打包简化运维） |
- 架构风格的层级关系
- 分布式架构是泛称，微服务和 SOA 都属于分布式架构的具体实现风格；
- 微服务是 SOA 的轻量化演进版本，去掉了 SOA 中重量级的 ESB，改用轻量级网关+RPC 通信。
- 技术栈与中间件的灵活性
- 同一架构风格可混搭不同技术栈，例如微服务架构既可以用 Spring Cloud Alibaba，也可以用 Go+Istio；
- 部分中间件是跨架构通用的，例如 Redis、Kafka 既可以用于分布式，微服务和 SOA 架构。
- 部署模式的选择依据
- 单体架构优先选单节点/主从部署，成本低、运维简单；
- 微服务架构优先选K8s 容器化部署，便于弹性扩缩容；
- SOA 架构优先选集中式+集群部署，保障 ESB 总线的稳定性。
二、分布式、微服务、SOA
分布式
分布式架构是一个大范畴，它指的是将应用系统的不同组件部署在不同的计算节点上，这些节点通过网络进行通信。
分布式系统的目标是提供高可用、可扩展性和容错性。
分布式架构是指将单体架构中的各个部分拆分，然后部署不同的机器或进程中去；
SOA是⼀种⾯向服务的架构，系统的所有服务都注册在总线上，当调⽤服务时，从总线上查找服务信息，然后调⽤；
微服务是⼀种更彻底的⾯向服务的架构，将系统中各个功能个体抽成⼀个个⼩的应⽤程序，基本保持⼀个应⽤对应的⼀个服务的架构。
核心概念定位
| 架构 | 定义 | 典型特征 |
|---|---|---|
| SOA | 面向服务的架构，通过服务总线整合企业系统 | ESB中心化、粗粒度服务、WS/SOAP协议 |
| 微服务 | 更细粒度的分布式架构，强调独立部署和自治 | 轻量级HTTP、容器化、去中心化治理 |
| 分布式 | 将系统拆分为独立模块，部署在不同节点协同工作 | 多节点、网络通信、CAP理论 |
通俗比喻：
SOA → 老师公交枢纽：所有线路必须通过中央车站（ESB）换乘
分布式 → 地铁网络：多条线路独立运行但需统一调度
微服务 → 共享单车+网约车：完全自治，按需灵活组合
技术演进关系
关键转折点：
- 2000s SOA：解决ERP等大型系统集成（如SAP用ESB连接财务/HR模块）
- 2010s 微服务：应对互联网高并发（Netflix通过API网关重构单体架构）
- 分布式：贯穿始终的基础理念
典型案例：
- SOA：银行核心系统（ESB整合柜面/信贷/风控）
- 微服务：美团外卖（独立部署订单/配送/支付服务）
- 分布式：早期淘宝（MySQL分库分表）
分布式与微服务：
- 概念：分布式是一种系统架构模式，将应用程序的组件分布在不同的计算机上，通过网络进行通信。微服务是一种软件架构模式，将应用程序拆分为一组小型、独立部署的服务，这些服务可以独立开发、部署和扩展。
- 实现方式：微服务是一种实现分布式系统的方式，通过将应用程序拆分为多个小型服务来实现分布式架构。而分布式系统可以采用不同的架构模式，比如基于消息传递、远程过程调用或分布式数据库等。
- 通信机制：微服务通常会使用轻量级的通信机制（如HTTP或消息队列）进行服务之间的通信。分布式系统则可能采用不同的通信方式。
- 关注点：微服务通常会引入一些额外的复杂性，比如服务发现、负载均衡、容错处理等，但能够提供更高的灵活性、可伸缩性和可维护性。分布式系统则更侧重于整个系统的设计和架构。
三、微服务、SOA
SOA与微服务：
- 复杂性：SOA是一种更加综合和复杂的架构风格，它通常包含多个服务和中间件组件。而微服务是一种更加简单和轻量级的架构风格，每个微服务独立部署和运行。
- 粒度：SOA的服务通常是比较大的、面向业务功能的服务。微服务则更加细粒度，每个微服务通常只关注一个特定的业务功能。
- 通讯：SOA通常使用基于SOAP的Web服务进行通讯，而微服务通常使用更轻量级的通讯机制，如RESTful API。
- 拆分与自治：SOA的服务划分通常由企业的架构团队进行，而微服务架构鼓励团队自主决策和拆分服务。
- 部署和扩展：SOA的服务通常是集中部署和扩展的，而微服务可以独立部署和扩展，使得系统更加灵活和可伸缩。
- 技术栈：SOA通常使用企业级集成平台和中间件，如ESB（企业服务总线）。微服务架构则更加灵活，可以使用各种适合的技术栈和工具。
- 生命周期管理：在SOA中，服务的生命周期管理由中央仓库进行管理。而微服务则更加注重分散的服务治理，每个服务都有其独立的生命周期管理。
- 数据库的使用：在SOA中，每个服务可能会使用相同的数据库。而在微服务中，每个服务都有其独立的数据库。
服务化的思想：
- SOA和微服务都是基于服务化的思想。它们都将系统分解为多个服务，服务之间通过网络通信来协同工作。
- 在SOA中，服务通常比较大，功能较为复杂，包含多个子模块。而在微服务中，服务粒度较小，每个服务通常只负责单一业务功能。
SOA
微服务
微服务架构、分布式系统
SOA和微服务都可以视为分布式架构的实现方式。它们都是通过网络将不同的组件分布在多个节点上来实现系统的高可用性、扩展性和容错性。
从应用程序的扩展角度考虑
微服务和分布式都是对大型应用程序的扩展，只是扩展方向不同：
分布式系统更多是偏水平扩展，在
ops（Operations：运维 / 运营）方面的解决办法，利用部署系统环境的空间分布性，比如SOA架构中利用分布式集成大型、复杂的单体应用程序；比如对实例进行克隆，以副本的形式对应用的数据和服务提供一种冗余方式(数据副本和服务副本)，从而对外提供高可用，高并发的服务。分布式需要解决分布式数据一致性以及分布式环境通信异常、网络分区等问题。比如通过Zookeeper解决分布式数据一致性的问题。分布式系统可以理解为以解决硬件层面的压力从而对应用进行扩展。
微服务架构更多的是垂直方向的扩展，在dev（Development：开发）方面解决问题，利用应用程序的功能性分解，把应用拆分为一组服务，每个服务负责特定的功能。每个服务都相对较小并容易维护，使大型的复杂应用程序可以持续交付和持续部署。服务可以独立部署、可以独立扩展。同时微服务架构可以实现团队的自治。更容易实验和采纳新的技术。更好的容错性。即服务之间松耦合，但是单个服务又是高内聚的。
微服务架构可以理解为解决软件层面的压力对应用进行扩展。
微服务架构和分布式系统之间的关系
个人认为，不属于包含关系，都是是对于应用扩展的不同解决办法。一般情况下，微服务架构的应用一般为分布式系统。但分布式系统不一定是微服务架构。
SOA和微服务基本上都是分布式架构的
四、分布式、集中式
参考资料
致谢