Day31-44｜12.2.4 信息系统常用4种架构模型：从集中式到分布式服务化的选型与演进

一、教材定位

本节是《系统架构设计师教程（第2版）》第12章第12.2节“信息系统架构”的第四个小节。前面已经学习架构风格、架构分类和一般原则，本节进一步把实际工程中常见的四类信息系统架构模型放在一起比较：集中式架构、客户机/服务器架构、浏览器/服务器架构和分布式架构。

这四种模型代表了信息系统从集中处理、客户端参与、浏览器访问到多节点协同的典型演进路径。它们不是严格互斥的技术时代，也不是“后者永远优于前者”。在考试中，题目经常给出现有系统、用户规模、网络条件、组织范围和改造目标，要求判断采用哪种模型，或者分析从一种模型迁移到另一种模型的收益与风险。因此，本节必须掌握“结构—特点—适用—问题—演进”的完整分析方法。

二、四种架构模型总览

实际系统可以混合使用。例如，企业内部仍有集中式核心主机，外围采用 B/S 门户，通过 API 与分布式服务和数据平台连接；工厂现场采用边缘节点，中心云使用服务化架构。分类模型帮助理解主结构，不能替代对具体系统边界的分析。

三、集中式架构模型

1. 基本结构

集中式架构将主要计算、数据、业务规则和控制能力部署在中心主机或中心系统，终端负责输入、输出或简单交互。所有或大部分请求发送到中心，中心完成处理后返回结果。

2. 主要优点

集中式架构便于统一数据、规则、权限、备份、监控和发布。对于需要强一致、流程统一和安全管控的核心业务，集中式模型可以降低数据分散和版本不一致风险。终端较薄时，设备更新和应用维护相对简单。

3. 主要缺点

中心节点可能成为性能、可用性和扩展瓶颈；网络中断会影响大量终端；中心升级或故障的影响范围大；数据和业务过度集中后，部门和区域自治能力不足。中心系统长期承载大量历史规则，也可能形成难以替换的遗留核心。

4. 适用场景

适合终端能力弱、用户和业务边界较集中、网络稳定、规则统一且需要集中控制的场景，如部分金融核心、批处理、集中管理和大型主机事务系统。若数据和业务必须本地自治，集中式就不一定适合。

5. 设计注意事项

集中并不等于只有一台服务器。可以通过集群、主备、分区、容灾和弹性资源消除单点；可以将查询、分析和外围服务分离，防止中心核心被非关键负载拖垮；可以设计本地缓存或有限离线能力，改善网络异常下的体验。

四、客户机/服务器架构模型

1. 基本结构

C/S 模型把处理职责分配到客户端和服务器。客户端通常负责用户界面、部分业务逻辑和数据处理，服务器负责数据库、共享服务和核心业务。常见有两层 C/S 和三层 C/S。

2. 两层 C/S

两层 C/S 中，客户端直接连接数据库或应用服务器，界面和部分业务逻辑集中在客户端，数据库负责数据存储和查询。它开发和交互效率较高，适合内部用户和网络稳定的组织，但数据库暴露、客户端升级、业务逻辑分散和并发管理是主要问题。

3. 三层 C/S

三层 C/S 将表示、业务逻辑和数据访问分离，通过应用服务器承载业务和连接池。它比两层结构更容易控制数据库访问、扩展业务和隔离安全，但增加了中间层配置、部署和通信复杂度。很多 B/S 系统的服务端也采用类似三层或多层结构。

4. C/S 的优点

客户端可以使用本地计算、缓存和设备能力，交互体验较好；服务器集中保存共享数据和核心服务；内部系统可以针对固定用户和网络优化。

5. C/S 的缺点

客户端需要安装、升级和兼容不同操作系统；核心逻辑可能分散到多个版本；外部用户和移动用户接入困难；客户端直接连接数据库会扩大安全边界和维护风险。

6. 适用场景

适合组织内部、终端可控、交互复杂、需要使用本地设备或离线能力的系统，例如生产控制台、设计工具、专业交易终端和内部管理软件。面向公众和多终端场景通常需要 B/S 或 API 化。

五、浏览器/服务器架构模型

1. 基本结构

B/S 模型以浏览器作为通用客户端，服务器提供 Web 页面、API、业务处理和数据服务。用户不需要安装复杂客户端，系统可以通过网络访问。现代 B/S 通常由浏览器、网关、Web 服务、业务服务、数据和基础设施组成。

2. 主要优点

客户端安装和升级成本低，跨平台能力好，便于面向公众、分支和移动用户提供服务；服务器集中管理业务和数据，便于统一安全和版本；可以通过 CDN、缓存、负载均衡和弹性资源支持规模扩展。

3. 主要缺点

对网络和服务器可用性依赖强；高并发访问可能造成入口、应用或数据库压力；浏览器环境、脚本安全、兼容性和跨域问题需要治理；复杂本地设备和离线能力实现相对困难。

4. 适用场景

适合门户、电子商务、公共服务、企业协同、在线教育、客户服务和多终端应用。对于弱网、实时控制和复杂设备交互，可以结合本地应用、边缘节点或离线缓存，而不是纯 B/S。

5. B/S 的工程重点

需要考虑身份认证、会话、API 网关、缓存、限流、负载均衡、静态资源、数据库连接、前后端版本和浏览器安全。页面能访问不代表系统可用，还要验证峰值、网络中断、重复提交、接口超时和降级。

六、分布式和服务化架构模型

1. 基本结构

分布式架构将系统拆分为多个通过网络协同的节点、服务或组件，计算、数据和资源可以分布部署。服务化架构进一步按业务能力封装服务，通过 API、消息和事件协作；微服务是其中一种更强调自治和独立部署的实现方式。

2. 主要优点

可以按业务或负载独立扩展，隔离部分故障，支持多团队并行和快速发布；可以将服务部署到云、边缘和不同区域，满足多组织和多场景需求；服务通过契约协作，有利于复用和平台化。

3. 主要缺点

网络调用带来延迟、超时、重试和部分失败；数据分散后需要解决一致性、查询、事务和审计；服务数量增加后需要服务发现、配置、网关、链路追踪、日志、指标、发布和安全治理；分布式系统问题难以在单机环境复现。

4. 适用场景

适合用户和业务规模大、组织多、变化快、部分能力需要独立扩展、跨区域或跨云部署的系统。小规模、稳定、团队和运维能力有限的系统不必为了追求先进而过度分布式。

5. 分布式设计重点

要划分业务边界和数据所有权；设计超时、重试、熔断、限流和降级；处理幂等、消息、补偿和最终一致；建立统一观测、自动化发布、配置和安全；定义跨服务事务和对账方案。

七、四种模型的质量属性比较

比较不能脱离具体实现。集中式集群也可以高可用，B/S 也可以离线和边缘化，分布式也可能因为共享数据库而高度耦合。架构模型只是分析起点。

八、模型之间的演进路径

1. 集中式到 C/S

当终端交互和本地处理需求增加，可以把界面和部分交互下沉到客户端，中心继续负责数据和核心业务。迁移要考虑客户端版本、接口、网络、权限和数据一致性。

2. C/S 到 B/S

通过抽取服务层、建立 Web 接入和 API，把客户端逻辑逐步迁移到服务端或前端。不要直接重写全部业务，先对查询、报表和外围功能进行改造；核心交易通过兼容接口保持连续。

3. B/S 到分布式服务化

当单体 Web 系统达到规模和组织瓶颈时，按业务边界拆分服务，引入网关、消息、服务治理和独立扩展。先识别变化频繁、负载独立、边界清晰的模块，避免一开始把系统拆成大量碎片。

4. 中心到云边混合

将实时、敏感或现场自治功能部署到边缘，将训练、分析和全局管理保留在云端。必须设计状态同步、策略有效期、断网和安全边界。

九、架构模型选择的决策矩阵

决策矩阵不能机械打分。应选取关键场景进行原型和测试，用事实验证模型是否满足目标。

十、案例分析：集团财务系统的架构模型演进

某集团财务系统最初是总部集中式主机，分支机构通过专线访问；后来建设桌面 C/S 客户端；现在希望支持浏览器、移动审批、外部报销服务和多区域容灾，同时保留核心账务的强一致性。

问题一：如何评价现有三阶段架构？

参考答案：集中式主机便于统一账务和规则，但分支依赖专线、中心扩展和容灾压力大；C/S 改善了交互和部分本地处理，但客户端版本和部署维护复杂，业务逻辑可能分散；目标 B/S 和服务化可支持多终端、开放接口和弹性，但核心账务、数据一致、权限和审计仍需集中治理，不能因为服务化而把账务拆成无法一致的碎片。

问题二：提出渐进式目标架构

参考答案：保留核心账务主机作为权威系统，通过服务层封装账务、预算、凭证和结算能力；新增统一身份、API 网关和 B/S 门户支持浏览器与移动审批；将报销、查询、通知和外围协作逐步服务化，采用消息和事件与核心系统同步；分析数据进入独立平台，避免压垮账务；跨区域部署入口和只读能力，核心账务采用主备或多中心灾备；涉及强一致的记账和支付保持明确事务边界。

问题三：迁移过程如何降低风险？

参考答案：先建立接口和数据对账，选择查询、报表和审批等低风险功能灰度；采用双读校验、必要时双写但明确权威和补偿；新旧系统并行运行，监控差异和性能；核心切换前进行账务对账、权限、容灾和回退演练；保留旧接口和客户端过渡期，分支按区域逐步迁移；所有变化纳入版本和审计。

十一、综合知识练习

题1

集中式架构是否一定存在单点故障？

参考答案：不一定。集中式描述的是计算和数据的组织范围，可以通过集群、主备、多副本、灾备和冗余消除物理单点；但中心控制和统一资源仍可能形成集中风险，需要评估故障域和恢复能力。

题2

C/S 架构的主要维护难点是什么？

参考答案：客户端安装升级、操作系统兼容、版本不一致、业务逻辑分散、终端安全和外部用户接入。可以通过三层结构、自动更新、服务化和逐步 B/S 化缓解。

题3

B/S 架构为什么不能解决所有客户端问题？

参考答案：它降低安装成本并改善跨平台，但仍依赖网络和服务端，浏览器安全、会话、并发、弱网、复杂设备和离线场景仍需设计。必要时需要本地应用、边缘或离线能力。

题4

什么情况下不适合直接采用微服务？

参考答案：业务边界不清、系统规模小且稳定、团队和自动化运维能力不足、强一致事务占主导或组织无法承担分布式治理时，不适合直接拆成微服务。可以先模块化、服务化接口和可观测，再按瓶颈演进。

十二、论文写作素材

论文可以围绕“传统企业信息系统架构模型演进”展开，说明为什么从集中式或 C/S 逐步向 B/S、服务化和混合架构演进，同时保留核心账务或控制业务的可靠性。重点写清模型选择依据和迁移风险，而不是单纯宣称新架构更先进。

可使用如下段落：

“本项目根据用户范围、网络条件、业务一致性和演进需求选择混合架构。核心交易继续采用集中治理和明确事务边界，以保证账务正确与审计完整；面向多终端的访问通过 B/S 和 API 统一接入；报表、通知和外围协作以服务化和事件方式解耦；分析负载进入独立数据平台；对弱网和区域业务保留缓存与有限自治。迁移过程中先通过接口层隔离旧系统，再对低风险功能灰度，使用双读校验、对账、监控和回退控制风险，避免因追求分布式而破坏核心业务连续性。”

十三、今日复盘

1. 常见信息系统架构模型包括集中式、客户机/服务器、浏览器/服务器和分布式/服务化。
2. 模型差异体现在计算分工、数据位置、客户端职责、通信方式、扩展和运维治理。
3. 集中式适合统一和强一致，C/S 适合可控终端与丰富交互，B/S 适合多终端和开放服务，分布式适合规模化和独立演进。
4. 没有绝对优劣，实际系统往往采用组合模型，必须结合业务、质量、组织和现状约束。
5. 架构迁移要保护核心业务，通过接口、同步、灰度、对账、演练和回退逐步推进。
6. 案例和论文要写“现状模型—目标模型—选择依据—演进路线—风险控制—验证指标”。

本节的核心结论是：架构模型是理解系统形态和制定演进路线的工具，而不是技术潮流排行榜。成熟的架构设计会保留适合核心业务的集中能力，同时用 B/S、服务化、云边协同和数据平台解决新的访问、扩展和智能化需求。