企业数字化转型-软件架构的演进历程

核心模式： 需要在用户设备上安装专门的客户端软件。典型的例子如 QQ、大型网游、专业 IDE 或企业内部的 ERP 软件。

• 逻辑分布： 客户端承担了大量的业务逻辑处理（胖客户端）。

• 优点： * 交互性极佳： 能够充分利用本地硬件资源（显卡、内存、硬盘）。

• 响应速度快： 部分逻辑在本地完成，减少了网络交互。

• 安全性高： 通信协议可以高度自定义。

• 缺点： * 更新成本高： 每次升级都需要用户下载安装包。

• 跨平台性差： Windows、Mac、Linux 需要分别开发适配。

2. B/S 架构 (Browser/Server，浏览器/服务器)

核心模式： 客户端就是浏览器（Chrome, Edge等），用户通过 URL 访问。本质上是 C/S 的一种特殊形式（浏览器是通用的客户端）。

• 逻辑分布： 绝大部分业务逻辑都在服务器端运行（瘦客户端）。

• 优点：

• 零安装： 只要有浏览器就能用，即开即用。

• 维护简单： 开发者只需在服务器更新代码，用户刷新页面即可完成升级。

• 跨平台： 理论上只要能跑浏览器，就能运行 B/S 应用。

• 缺点：

• 交互受限： 受限于浏览器的安全沙箱，对本地硬件（如打印机、传感器）的调用不如 C/S 灵活。

• 网络依赖： 几乎所有操作都需要服务器响应，断网即瘫痪。

3. C/S vs B/S：多维度对比

1. 单体架构 (Monolithic Architecture)

时代背景： 互联网早期，业务逻辑简单。

所有功能模块（如用户、订单、支付）都打包在同一个代码库中，部署在同一个进程里。

• 优点： 开发简单、部署方便、性能高（内部调用，无网络开销）。

• 痛点： 随着项目变大，代码修改“牵一发而动全身”，编译慢，扩展性差（无法针对特定模块扩容）。

2. 垂直架构 (Vertical Architecture)

时代背景： 流量增加，单体应用不堪重负。

为了解决单体应用的扩展问题，人们开始将大应用拆分为几个互不相干的小应用。例如，将“电商网站”拆分为“官网”和“后台管理系统”。

• 核心逻辑： 物理上的切分，各跑各的。

• 痛点： 重复造轮子。不同系统之间可能都有类似的用户管理逻辑，代码无法复用。

3. SOA 架构 (Service-Oriented Architecture)

时代背景： 企业级应用增多，需要整合多个异构系统。

引入了ESB（企业服务总线）的概念。它像一个翻译官，让不同语言、不同平台的系统能够通过总线进行通信。

• 核心特征： 强调服务的重用和标准化接口。

• 痛点： ESB 太重了，往往成为系统的性能瓶颈，且配置极其复杂。

4. 微服务架构 (Microservices Architecture)

时代背景： 云计算兴起，追求极致的敏捷开发和快速交付。

微服务是 SOA 的“瘦身版”和“去中心化版”。它主张将应用拆分为一系列细小的服务，每个服务运行在自己的进程中，通过轻量级协议（如 HTTP/REST）通信。

• 核心特征：

• 独立性： 每个服务有独立的数据库，可以独立部署。

• 去中心化： 不再依赖笨重的总线，而是使用注册中心（如 Eureka, Consul）。

• 痛点： 系统复杂度爆炸。分布式事务、链路追踪、服务容错（熔断/降级）成了架构师的新头发杀手。

5. 服务网格与 Serverless (Service Mesh & Serverless)

时代背景： 云原生（Cloud Native）时代。

• 服务网格 (Service Mesh)： 代表技术是 Istio。它将网络通信（发现、负载均衡、加密）从业务代码中剥离出来，交给“边车”（Sidecar）处理，实现业务逻辑与基础设施的解耦。

• Serverless (无服务器)： 代表技术是 AWS Lambda。开发者只需编写函数逻辑，完全不用关心服务器和运维，按调用次数付钱。

总结对比