一、底层规律：问题驱动架构演进

在展开具体脉络之前，先明确一个底层认知框架：

每一项新技术或新架构的出现，都对应着现有方案在特定场景下无法有效解决的问题。技术演进的过程本身是"理论-实践-理论"的反复迭代。

这一规律包含两层含义：

第一层：问题是演进的触发点。 技术进步的驱动力并非抽象的"追求更好"，而是具体场景下现有方案的能力边界被触及——解决方案在化解问题的同时，会在新维度引入新的约束条件，进而推动下一轮调整。

第二层：复杂度只能转移，无法消除。 每一项新技术的作用是将复杂度从需要人工直接处理的领域，转移到可以由工具或框架自动承载的领域。复杂度的总量并未减少，但处理方式发生了变化。

从这一规律出发，观察技术的视角可以从"是什么"转向"在问题链条中的位置"——对应化解了什么问题、会引入什么新问题。

二、脉络总览

单机时代
  │ 问题：数据孤岛
  ↓
集中式计算（大型机+哑终端）
  │ 问题：算力集中、成本过高
  ↓
C/S 胖客户端
  │ 问题：部署维护成本膨胀
  ↓
B/S 瘦客户端
  │ 问题：服务器压力集中 + 代码复杂度
  ├──→ [嵌入] 代码组织演进：分层→六边形→CQRS→事件溯源→DDD
  ↓
分布式集群 + 负载均衡
  │ 问题：数据一致性、跨节点状态协同
  ↓
分布式中间件（Redis/MQ/注册中心）
  │ 问题：单体代码复杂度
  ↓
SOA → 微服务
  │ 问题：治理逻辑与业务代码耦合
  ↓
Service Mesh
  │ 问题：基础设施运维负担
  ↓
Serverless / FaaS
  │
  │ （并行线）
  ├──→ 去中心化/区块链（问题：中心权威信任）
  └──→ 边缘计算（问题：云端延迟与带宽约束）

以下按阶段逐一展开。

三、第一阶段：单机时代

软件装在一台电脑上，数据也存在这台电脑上。

问题：数据形成孤岛，多人无法实时共享同一份数据。银行柜员A存的钱，柜员B看不到余额变化；北京售票处卖了的座位，上海售票处不知道。

数据孤岛问题推动软件从单机形态向联网形态演进。

四、第二阶段：集中式计算（大型机 + 哑终端，1960s）

4.1 解决的问题

为了解决数据共享问题，将所有数据和算力集中到一台大型机上，多个终端通过串口线连接，共享同一台机器的资源。

  • 终端是"哑"的：仅具备输入与显示能力，无本地算力
  • 所有计算在大型机上完成，终端仅传输字符流
  • 代表：IBM 大型机、银行核心账务系统、航空订票系统

4.2 引入的新问题

  • 大型机极其昂贵（几百万美元），只有大机构买得起
  • 算力集中在单点，扩展只能靠加硬件卡
  • 封闭架构，厂商锁定（IBM/DEC 各自一套）

集中式计算的核心局限：算力完全集中在一台机器上，无法通过增加机器节点来扩展。 大型机的高购置成本构成了信息化的准入门槛。

五、第三阶段：C/S 胖客户端（1990s）

5.1 解决的问题

PC 普及，每台电脑都配备 CPU、内存、硬盘，算力从大型机分散到个人桌面。

架构调整方向是利用 PC 的本地算力分担部分工作：UI 渲染、输入校验、部分业务逻辑在客户端运行，核心业务和数据存储仍由服务器承担。

  • 客户端是"胖"的：具备本地算力，可独立完成渲染与部分业务逻辑
  • 服务器端专注于核心业务处理与数据持久化
  • 代表：QQ 客户端、银行柜员系统、企业 ERP（Delphi/VB/PowerBuilder 开发）

5.2 引入的新问题

部署维护成本膨胀：用户数增长与终端数量线性相关，1000 个用户对应 1000 台需要安装、升级、排障的 PC。

痛点 量化代价
初始部署 逐台安装客户端，环境各异，失败要现场排查
版本升级 1000 台 PC 都要重新安装，有人没升级就和服务器版本不匹配
故障排查 平均每个问题要远程或现场排查 1-2 小时
安全风险 数据库连接串存在客户端，可被反编译

C/S 架构的核心局限：部署维护成本与用户数成正比。 软件逻辑虽然只有一份，但运行实体分散在 N 台终端，对应的维护成本无法集中消化。

六、第四阶段：B/S 瘦客户端（2000s）

6.1 解决的问题

C/S 的部署成本问题本质是"软件的运行入口分散在 N 台终端上"。要彻底解决，只能让客户端"零部署"——用一个通用的、已经装好的程序来运行所有业务。

浏览器满足作为通用客户端的三个关键条件：

条件 说明
通用预装 任何操作系统都自带浏览器，用户不用手动装
标准化 HTML/CSS/JS 是 W3C 公开标准，不被某家厂商独占
向后兼容 1995 年写的 HTML，今天的浏览器还能打开

架构调整方向是将业务逻辑全部集中到服务器端，浏览器端仅负责页面渲染与用户交互。

  • 客户端是"瘦"的：浏览器只渲染页面、执行 JS，不跑业务逻辑
  • 服务器承担全部业务逻辑、数据存储、权限控制
  • 代表：企业信息化（ERP/CRM/OA）、电商、内容平台、SaaS

B/S 架构下 Java 服务器端的完整技术体系（Servlet 规范、设计模式、技术演进、Web 容器、会话管理），见 Java Web 技术体系。

6.2 引入的新问题

  • 计算集中于服务器端，单节点存在性能上限
  • HTTP 协议的无状态特性导致客户端身份无法在请求间保留
  • 交互体验受 HTTP 请求-响应模型约束（早期仅支持整页刷新，存在白屏间隔）

6.3 嵌入：代码组织架构的演进

B/S 架构将业务复杂度集中于服务器端，如果缺乏合理的代码组织，复杂度将快速超出可维护的范围。代码组织架构的演进由此在这一阶段并行展开。

分层架构（表示层/业务层/持久层）

触发问题：B/S 服务器端 UI 拼接、业务逻辑、数据访问代码耦合，无法独立修改。

化解方案：将不同关注点的代码进行物理隔离，使变化的影响范围可控。

引入约束：分层后业务逻辑仍依赖具体技术实现，更换持久化方案时业务代码仍需联动修改。

六边形架构 / 洋葱架构（端口与适配器）

触发问题：分层架构中业务逻辑依赖 DAO 接口的具体实现，更换底层技术需要改动业务代码。

化解方案：将业务逻辑置于架构中心，外围通过"适配器"对接外部技术。业务核心定义"端口"（接口），由外部技术实现适配。业务逻辑对外部技术无感知，更换数据库、消息队列或 HTTP 框架均不影响业务代码。

洋葱架构是六边形架构的进一步发展，更强调分层依赖的方向性：领域模型位于最内层，所有外层均依赖于它，它不依赖任何外层。

引入约束：读写操作共用同一数据模型，在读多写少场景下查询性能难以优化。

CQRS（命令查询职责分离）

触发问题：同一数据模型同时承担读写职责，读多写少场景下查询性能受限。

化解方案：采用分离的读写模型。写模型针对写入效率优化，读模型针对查询效率优化（通常反规范化为宽表或物化视图）。写入操作通过写模型完成，完成后发送事件异步更新读模型；查询操作直接走读模型，获取高性能查询能力。

引入约束：仅保存当前状态，变更过程的历史信息丢失。

事件溯源（Event Sourcing）

触发问题：传统数据库仅存储"当前状态"，变更过程不保留，无法回溯任意时间点的历史状态。

化解方案：不直接存储当前状态，而是存储所有状态变更事件。需要获取当前状态时，按顺序重放全部事件即可。该方案天然支持回溯任意历史时点，满足审计与追溯需求。

引入约束：业务领域语言与代码结构映射不一致时，易造成产品与开发沟通成本上升。

DDD（领域驱动设计）

触发问题：业务领域的术语体系与代码的结构映射不对应，同一业务概念在沟通与代码中含义存在差异。

化解方案：将业务领域中的概念直接映射为代码结构。通过限界上下文保证业务边界内术语含义唯一，通过聚合根控制一组关联对象的唯一访问入口，通过领域事件记录业务上有意义的状态变更。使代码结构直接反映业务语言体系。

七、第五阶段：分布式集群 + 负载均衡（2000s 中期）

7.1 解决的问题

B/S 架构将计算集中于服务器端，单节点存在性能瓶颈。解决方案是引入多台服务器组成集群，通过负载均衡分散请求压力。

  • 请求入口处部署 Nginx 等负载均衡设备，将流量分发至后端多台应用服务器
  • 多台服务器组成集群，实现算力的横向扩展

7.2 引入的新问题

  • 多节点间的数据一致性问题
  • 请求跨节点路由导致的 Session 失效问题
  • 分布式缓存一致性与跨服务事务处理问题

八、第六阶段：分布式中间件（2010s）

8.1 解决的问题

为了解决多节点间的状态协同问题，引入了一批专门的分布式中间件：

中间件 承担的职责
Redis 分布式缓存，用于 Session 共享、热点数据缓存
消息队列（Kafka/RabbitMQ） 服务间异步解耦、流量削峰填谷
分布式事务（Seata） 跨服务调用的数据一致性保障
注册中心（Eureka/Nacos） 服务实例注册与动态发现

8.2 引入的新问题

  • 服务器端代码规模持续增长，所有业务模块耦合在同一部署包中
  • 任意局部改动都需要全量编译、回归测试与重新发布
  • 单个模块的内存溢出会导致整个应用不可用
  • 代码规模膨胀后，模块边界的学习成本显著上升

九、第七阶段：SOA → 微服务（2010s 中期）

9.1 SOA（面向服务架构）

解决的问题：单体应用的代码复杂度持续增长。

采用的方案是将单体拆分为多个服务，通过企业服务总线（ESB）进行通信，由 ESB 承担路由、协议转换、消息编排等职责。

引入的新问题：
- ESB 自身功能不断膨胀，成为新的单点瓶颈与故障点
- 服务拆分粒度较粗，单个服务内部的复杂度并未有效降低

9.2 微服务

解决的问题：SOA 架构中 ESB 臃肿与拆分粒度不足的问题。

微服务进一步细化拆分粒度，服务之间通过 REST 或 gRPC 点对点直接通信，移除 ESB 中间层。通信模型从 SOA 的"哑终端 + 智能管道"转变为"智能终端 + 哑管道"。

  • 每个服务具备独立的部署、扩容与故障隔离能力
  • 按业务域划分服务边界，团队与服务一一对应，独立迭代
  • 代表：Netflix、Amazon、阿里的大型互联网系统

引入的新问题：
- 每个服务都需要独立实现服务发现、负载均衡、熔断、链路追踪等治理能力
- 多语言栈下，同一种治理逻辑需要为不同语言重复实现（Java 用 Hystrix，Go 需另行实现）
- 治理逻辑与业务代码耦合，存在重复建设且语言绑定

十、第八阶段：Service Mesh / 服务网格（2018+）

10.1 解决的问题

微服务模式下，服务发现、负载均衡、熔断等治理逻辑散落在各服务的业务代码中。解决方案是将治理逻辑从业务代码中剥离，下沉为独立的基础设施层。

  • 每个服务实例旁部署一个 Sidecar 代理（如 Envoy）
  • 所有进出服务的网络流量均经过 Sidecar，由其统一处理服务发现、负载均衡、熔断、加密、链路追踪
  • 业务代码仅包含业务逻辑，治理能力由 Sidecar 统一提供
  • 代表：Istio、Linkerd
微服务模式（治理逻辑位于业务代码内）：
  服务 A（业务代码 + 熔断 + 负载均衡 + 链路追踪）
  服务 B（业务代码 + 熔断 + 负载均衡 + 链路追踪）

Service Mesh 模式（治理逻辑下沉至 Sidecar）：
  服务 A（纯业务逻辑）←→ Sidecar A（治理能力）
  服务 B（纯业务逻辑）←→ Sidecar B（治理能力）

10.2 引入的新问题

  • Sidecar 代理自身带来资源开销（每个服务额外增加一个代理进程）
  • 网络链路新增一层跳转，请求路径从客户端→服务变为客户端→Sidecar→服务
  • 运维对象范围扩大，需额外管理 Sidecar 的部署、升级与配置

十一、第九阶段：Serverless / FaaS（2018+）

11.1 解决的问题

在云基础设施与服务网格之上，服务器的运维管理、容量规划、闲置资源成本仍然是需要面对的问题。FaaS（函数即服务）将服务器运维责任交由云平台承担，开发者只需编写业务逻辑函数并上传。

  • 开发者上传函数代码至云平台，平台负责运行时调度
  • 函数按请求触发执行，无请求期间不产生运行费用
  • 平台根据并发量自动完成扩缩容，1000 个并发对应启动 1000 个函数实例
  • 代表：AWS Lambda、阿里云函数计算

11.2 引入的新问题

  • 冷启动延迟：首次调用或长时间空闲后调用需等待容器初始化，耗时可达数秒
  • 有状态服务支持受限：函数实例本身无状态，持久化状态需依赖外部存储
  • 供应商绑定风险：不同云平台的函数运行时与 API 存在差异，迁移成本较高
  • 调试链路复杂：本地开发环境与云端生产环境的运行条件存在差异

十二、第十阶段：去中心化 / 区块链（2009+，并行发展）

12.1 解决的问题

前述架构均为中心化形态——存在一个或一组作为权威节点的中心服务器。在部分场景中，单一中心的可信性无法满足业务需求：

  • 加密货币：不希望货币发行权由单一央行或银行掌控
  • 供应链溯源：参与方互不信任，需要中立的记录载体
  • 电子合同存证：存证机构自身的可信度可能被质疑

去中心化架构不设中心权威节点，所有节点各自保存完整数据副本。写入操作需经共识算法（PoW/PoS/PBFT）确认，获得多数节点同意后方可写入，写入后的数据具备不可篡改特性。

  • 代表：比特币、以太坊、Hyperledger（联盟链）
  • 共识算法：PoW（工作量证明）、PoS（权益证明）、PBFT（实用拜占庭容错）

12.2 引入的新问题

  • 共识确认吞吐量较低（比特币网络约 7 笔/秒）
  • 链上数据对所有参与节点公开，业务隐私保护难度大
  • 存储冗余度高：全节点需保存完整链上数据
  • 已写入数据在设计上不可修改，当代码逻辑与现实规则冲突时缺乏灵活调整空间（所谓"代码即法律"的困境）

12.3 演化方向：混合架构

纯去中心化架构在性能与隐私上的限制，催生了分层信任的混合实践：公开链承担存证职责，联盟链承担治理流程，中心化系统承担高频业务运算。通常由中心化系统处理业务逻辑，区块链仅作为存证与审计层。

十三、第十一阶段：边缘计算（2015+，并行发展）

13.1 解决的问题

IoT、自动驾驶、实时视频等场景中，海量数据回传云端的传输延迟与带宽占用成为瓶颈。

边缘计算将计算能力部署在离数据源尽可能近的位置，以降低传输延迟与带宽占用。

  • 摄像头端本地完成 AI 识别，仅向云端上报识别后的结构化异常结果
  • 自动驾驶车载芯片完成实时决策，不依赖云端响应
  • CDN 可视为边缘计算的早期形态：静态内容在离用户最近的节点缓存分发
  • 代表：AWS Greengrass、Azure IoT Edge、阿里云边缘节点

13.2 引入的新问题

  • 边缘节点算力、内存、存储资源普遍受限，复杂模型难以直接部署
  • 边缘节点数量多、地理分布广，统一运维与版本管理难度高
  • 数据分散存储于各边缘节点，全局一致性保障难度上升

13.3 演化方向：云-边-端三层协同架构

边缘节点的资源约束催生了三层分工的协同模式：云端负责模型训练与全局调度，边缘节点负责推理执行与本地决策，终端设备负责数据采集与呈现。

十四、脉络全景图

单机时代
  │ 问题：数据孤岛
  ↓
集中式计算（大型机+哑终端）
  │ 问题：算力集中、成本过高
  ↓
C/S 胖客户端
  │ 问题：部署维护成本膨胀
  ↓
B/S 瘦客户端
  │ 问题：服务器压力集中 + 代码复杂度
  ├──→ [嵌入] 代码组织演进：分层→六边形→CQRS→事件溯源→DDD
  ↓
分布式集群 + 负载均衡
  │ 问题：数据一致性、跨节点状态协同
  ↓
分布式中间件（Redis/MQ/注册中心）
  │ 问题：单体代码复杂度
  ↓
SOA → 微服务
  │ 问题：治理逻辑与业务代码耦合
  ↓
Service Mesh
  │ 问题：基础设施运维负担
  ↓
Serverless / FaaS
  │
  │ （并行线）
  ├──→ 去中心化/区块链（问题：中心权威信任）
  └──→ 边缘计算（问题：云端延迟与带宽约束）

十五、问题转化对照表

阶段 化解的核心问题 引入的新约束
集中式计算 多用户数据共享 算力单点集中、硬件成本高
C/S 胖客户端 算力分散利用 部署维护成本与用户数线性相关
B/S 瘦客户端 客户端零部署 服务器端算力集中、压力汇聚
分布式集群 单节点算力瓶颈 多节点数据一致性、Session 跨节点共享
分布式中间件 多节点状态协同 单体代码规模持续膨胀
微服务 单体复杂度拆分 治理逻辑重复建设、全局治理复杂度上升
Service Mesh 治理逻辑从业务剥离 Sidecar 资源开销、新增运维对象
Serverless 服务器运维转移至平台 冷启动延迟、平台绑定、调试链路长
去中心化 单一中心权威移除 共识吞吐量下降、数据公开隐私受限
边缘计算 云端延迟与带宽占用 边缘节点资源有限、统一管理难度高

十六、架构形态共存互补

以上脉络按问题演化的时间线串联，但这不代表后续架构取代了前面的架构。各架构形态均有其适配的场景边界：

架构 适配场景 不可替代性
集中式 银行核心账务、航空订票 强一致性、单点权威、事务可靠性要求高
C/S 胖客户端 大型客户端游戏、专业设计软件（CAD/PS/IDE） 本地高性能渲染、低延迟交互、离线可用
B/S 瘦客户端 企业信息化系统（ERP/CRM/OA）、电商、SaaS 零部署门槛、多用户并发、高频功能迭代
去中心化 加密货币、供应链溯源、电子存证 无中心权威、抗审查、数据不可篡改
边缘计算 IoT 感知网络、自动驾驶、实时视频分析 延迟敏感、带宽资源有限
Serverless 突发流量场景、事件驱动型任务 按需弹性扩缩容、无需预先规划容量

现实中的系统通常是多种架构形态的混合体：

示例：现代电商系统的架构组合

用户接入层：
  Web 浏览器（B/S）     ← 电商网站入口
  手机 App（C/S）       ← 移动端购物入口
  小程序（B/S 变体）    ← 社交生态入口

服务端：
  微服务集群（分布式）  ← 订单、商品、用户等领域服务独立部署
  边缘节点（CDN）      ← 商品图片、静态资源就近分发
  核心数据库（集中式）  ← 交易链路核心数据强一致存储

基础设施：
  云服务器（云原生）    ← 业务负载按需扩缩容
  区块链节点（去中心化）← 商品溯源链路存证

不存在"过时的架构"，只存在"与场景不匹配的架构"。架构选型的本质是在特定约束下进行权衡，目标是选择该场景下综合代价最小、收益最大的方案，而非追求理论上的最优解。

十七、总结

软件架构的演进遵循问题驱动的规律：每一种新架构的出现，都对应着既有架构在特定场景下无法有效解决的问题。新架构在化解这些问题的同时，也会在新的维度上引入新的约束条件，进而推动下一轮的架构演化。

这条演进脉络不是新架构淘汰旧架构的线性链条，而是架构形态不断丰富的扩展过程。集中式计算、C/S、B/S、分布式、微服务、Service Mesh、Serverless、去中心化、边缘计算，每一种架构都有其适配的场景边界，在现实系统中往往以混合形态共存，各自承担最擅长的职责。

理解这一演进规律，有助于在面对具体技术选型时，跳出对新技术的盲目追逐，从问题本身出发，判断每项技术所对应的场景约束、所化解的核心问题，以及随之而来的代价。