Day31-42｜12.2.2 信息系统架构分类：从多种视角识别系统形态与设计约束

一、教材定位

本节是《系统架构设计师教程（第2版）》第12章第12.2节“信息系统架构”的第二个小节，承接 12.2.1“架构风格”。上一节讨论系统如何通过组件、连接器和约束形成结构风格，本节进一步说明信息系统可以从哪些维度进行分类，以及不同类型对业务边界、数据组织、部署方式、通信方式和质量属性有哪些影响。

“架构分类”并不是给系统贴一个唯一标签。一个真实系统可以同时是分层架构、客户机/服务器架构、分布式架构、数据中心架构和事件驱动架构。考试案例中，分类的作用是快速识别题目中的主要矛盾，选择适合的架构思路，并说明为什么采用某种形态而不是另一种形态。答题时要避免只写名词，要将分类维度与业务场景、质量属性和实施条件联系起来。

二、为什么需要对信息系统架构分类

1. 建立共同语言

不同团队对“平台”“分布式”“集中式”“三层”“微服务”的理解可能不同。分类框架可以帮助业务、开发、运维和管理人员在同一层次讨论系统结构，减少沟通歧义。

2. 识别设计约束

集中式架构强调集中资源和统一管理，分布式架构需要处理网络、部分失败和一致性；共享数据库强调数据集中，服务自治强调边界和独立演进。知道系统属于哪类，有助于提前识别风险。

3. 支持技术选型和迁移

分类可以帮助判断现有系统和目标系统之间的差距，制定渐进式演进路线。例如从两层 C/S 迁移到 B/S 和服务化，先增加接口层，再拆分业务能力，最后改变部署和数据治理。

三、按系统部署与控制范围分类

1. 集中式架构

集中式架构把主要计算、数据和控制能力部署在一个中心系统或少量中心节点。终端通常负责输入输出，中心负责业务处理和数据管理。

优点：管理统一、数据集中、权限和备份容易控制，适合规则统一、规模可控和对中心依赖可接受的场景。

缺点：中心可能成为性能、可用性和扩展瓶颈；网络中断影响所有终端；中心故障和升级风险集中。

2. 分布式架构

分布式架构把计算、数据或服务部署在多个通过网络协同的节点上。它可以提高扩展能力、就近处理和故障隔离，但引入网络延迟、部分失败、数据一致性、节点管理和分布式调试问题。

分布式不是“服务器多”这么简单，而是多个独立节点共同完成一个系统目标。设计时要考虑节点发现、负载、超时、重试、幂等、熔断、状态、版本和恢复。

3. 混合式架构

现实系统常采用中心平台与区域节点、边缘节点或本地系统相结合的方式。混合式架构可以在统一治理和现场自治之间取得平衡，但需要设计边界、同步、冲突和离线策略。

四、按客户端与服务器关系分类

1. 两层客户机/服务器架构

客户端负责界面和部分业务逻辑，服务器负责数据库或核心服务。它结构直接、早期开发快，适合规模较小、网络稳定、客户端可控的内部系统。缺点是客户端升级和部署困难，业务逻辑可能分散，数据库暴露范围较大。

2. 三层或多层架构

将表示、业务逻辑和数据访问分离，也可以进一步划分接入、应用、服务、数据和基础设施层。它便于职责隔离、扩展和安全控制，但调用链增加，接口和事务边界需要治理。

3. 浏览器/服务器架构

浏览器作为通用客户端，服务器提供页面或 API，降低客户端部署成本，适合公众和多终端访问。需要重点解决并发、身份、会话、缓存、前后端版本和网络安全。

4. 移动和多端架构

移动端、桌面端、设备端和第三方应用通过统一 API 访问平台。服务器必须承担核心业务校验，客户端不可信；弱网、离线、推送、设备权限和版本兼容成为主要问题。

五、按业务组织方式分类

1. 事务处理架构

围绕订单、支付、库存、账务和登记等事务组织，强调正确性、完整性、并发和一致性。适合采用明确事务边界、状态机、幂等和审计。

2. 流程驱动架构

以审批、协作和跨组织流程为核心，强调任务分配、角色、状态、超时、撤回、补偿和人工介入。流程引擎可以提高配置能力，但复杂流程需要治理版本和业务规则。

3. 数据驱动架构

以数据采集、共享、分析、预测和决策为中心，强调统一模型、质量、血缘、生命周期和数据服务。适合数据仓库、数据湖、实时流和智能系统，但要防止只建设平台、不产生业务价值。

4. 事件驱动架构

以事件传播和异步响应为核心，适合解耦、实时通知、流处理和跨系统协同。要处理重复、乱序、延迟、最终一致性、死信和补偿。

5. 控制驱动架构

用于工业控制、机器人、交通和嵌入式系统，强调实时、确定性、反馈和安全。控制闭环通常靠近设备，不能把所有控制依赖中心平台。

六、按应用集成方式分类

1. 点对点集成

两个系统直接建立接口，初期简单、开发快；系统数量增长后接口数量可能快速增加，变更影响难以控制。适合少量、稳定、责任明确的集成。

2. 共享数据库集成

多个应用直接读写同一数据库，数据共享方便，但应用与表结构强耦合，权限和变更风险高。适合作为过渡或同一边界内的内部协作，不宜无限扩展到多个组织和服务。

3. 消息和事件集成

生产者通过消息或事件与消费者解耦，适合异步、削峰和多订阅者场景。需要消息可靠性、顺序、幂等、事务发布和重试治理。

4. 服务和 API 集成

通过明确的服务契约提供能力，便于复用、版本和安全治理。API 网关可以承担认证、限流、路由、审计和协议转换，但不能代替领域边界和数据治理。

5. 企业服务总线与集成平台

集成平台提供路由、转换、编排、监控和治理，适合大型组织和多系统集成。集中式总线可能成为瓶颈或单点，也可能造成过重的中心依赖，需要评估规模、实时性和组织边界。

七、按数据组织方式分类

1. 共享数据架构

多个模块围绕统一数据存储协作，适合需要强一致和统一事务的场景。缺点是数据结构变更会影响多个模块，服务自治较弱。

2. 数据库独立架构

每个服务或子系统维护自己的数据，通过 API、事件或数据复制共享结果。优点是边界清楚、独立演进，缺点是跨服务查询、一致性和事务处理复杂。

3. 数据仓库和数据湖架构

将多个来源的数据汇聚到分析平台，支持历史分析、指标和模型训练。需要数据目录、血缘、质量、权限、分层、冷热存储和成本治理。

4. 流式数据架构

数据以持续事件流进入处理链路，适合实时监控、风控、物联网和在线分析。需要时间语义、窗口、顺序、状态、回放和容错。

八、按处理时效分类

一个系统可能同时包含多种处理时效。架构师要将实时控制链路与批量分析链路分离，避免非关键任务争夺资源，也要设计结果汇聚和口径一致。

九、按系统规模和组织范围分类

1. 单组织系统

服务一个部门或组织，边界和权限相对简单，但仍要关注未来扩展和外部接口。

2. 企业级系统

覆盖多个部门和分支机构，需要统一主数据、流程、权限、标准和审计，同时支持组织差异和本地配置。

3. 跨组织平台

连接客户、供应商、合作伙伴、监管和第三方服务，强调开放 API、身份联邦、租户隔离、合同级服务质量和数据权属。

4. 社会化或生态系统

参与者数量多、变化快、边界开放，平台需要处理合作方接入、内容和行为安全、服务治理、计费、隐私和监管。生态系统架构的复杂性不仅来自技术，还来自多方利益和规则。

十、信息系统架构分类的综合对比

十一、架构分类与选型方法

第一步：识别主要业务矛盾

系统是更担心高并发、数据一致、跨组织协同、实时控制、快速变化还是数据分析？主要矛盾决定优先分类视角。

第二步：确定系统边界和权威

明确谁产生数据、谁修改数据、谁执行控制、谁负责运行。边界不清时，任何分类都可能变成空洞标签。

第三步：建立候选架构组合

从部署、客户端、业务、集成、数据和处理时效等维度组合，而不是单选一个风格。例如“B/S + 分层 + 服务化 + 事件驱动 + 独立数据 + 云边混合”。

第四步：评估质量属性和组织能力

比较响应、可用、扩展、安全、维护、数据一致和成本，同时评估团队、工具链、运维和供应商能力。复杂架构需要相应的治理能力。

第五步：设计演进路线

如果现状和目标差距较大，应选择旁路、适配、同步、灰度、双写、逐步替换或重构，并为过渡架构设置退出时间。

十二、案例分析：大型医院信息系统架构分类

某大型医院有挂号、门诊、住院、检验、影像、药房和财务系统。医院希望建设统一患者服务平台，支持手机预约、院内自助机和医生工作站，检验结果需要实时通知，历史数据要支持科研分析，关键医疗流程不能因网络中断而停止。

问题一：从哪些维度分类现有和目标架构？

参考答案：部署上采用中心平台、院内边缘或区域节点的混合架构；客户端采用 B/S、多端和设备接入；业务上包括事务处理、流程驱动、实时通知和数据分析；集成上采用 API、消息和标准医疗接口，避免无限点对点；数据上区分业务系统权威库、临床数据中心和科研分析平台；时效上区分挂号交易、实时告警、交互查询和离线分析；组织上支持科室、院区、患者和外部医保等多方协作。

问题二：如何解决实时通知与历史分析互相影响？

参考答案：临床告警和关键消息通过实时消息通道或院内边缘服务处理，设置优先级、确认和审计；历史分析通过数据同步、CDC 或数据平台异步获取数据，避免直接扫描在线交易库；统一数据模型和指标口径，区分实时状态与历史快照；分析平台出现故障不能影响挂号、医嘱和告警主流程。

问题三：网络中断时应如何分类处理业务？

参考答案：设备安全、已有医嘱执行和必要的临床记录由本地系统或边缘节点保留有限自治；跨院查询、复杂分析和非关键通知可以延迟；交易和医疗记录在本地采用序列、签名和缓存，恢复后幂等同步；任何离线写入都要标记来源、时间和待确认状态，不能伪造中心权威结果。

十三、综合知识练习

题1

一个信息系统能否只用“集中式”或“分布式”一个标签描述？

参考答案：通常不能。架构分类有多个维度，一个系统可以在部署上分布式、在数据上共享中心库、在业务上事务和流程并存、在集成上事件驱动和 API 结合。多维描述才能反映真实约束。

题2

为什么架构分类要结合处理时效？

参考答案：实时、交互、批处理和离线分析对资源、数据、部署和容错要求不同。若不区分，批量任务可能影响交易和控制，或者用过高成本满足不必要的实时要求。

题3

共享数据库架构的主要优势和风险是什么？

参考答案：优势是数据集中、事务和查询方便，适合共享权威数据；风险是应用与表结构强耦合、变更影响范围大、数据库可能成为瓶颈和单点，权限与数据责任也更难隔离。

题4

为什么跨组织平台需要比企业内部系统更强的治理？

参考答案：参与者身份、权限、数据责任、服务质量和利益关系更复杂，组织之间不完全信任，接口和版本变化也更频繁。需要租户隔离、身份联邦、契约、审计、限流、隐私、计费和合作方生命周期管理。

十四、论文写作素材

论文可以围绕“企业级信息系统的多维架构分类与选型”展开。建议先说明业务规模和主要矛盾，再从部署、客户端、业务、集成、数据、时效和组织范围多个维度描述目标架构，最后写出质量权衡、迁移路线和验证。

可使用如下段落：

“本项目没有使用单一标签描述系统，而是建立多维架构视图：部署上采用中心与区域节点结合的混合模式，访问上支持浏览器、移动端和设备端，业务上区分事务、流程和分析，集成上采用 API 与可靠事件相结合，数据上明确交易权威、共享数据和分析数据边界，时效上将实时告警与批量分析隔离。分类结果直接指导组件、部署、权限和测试设计，并通过高峰并发、网络中断、重复消息、数据冲突和跨组织越权场景验证。”

十五、今日复盘

1. 信息系统架构分类是从多个视角识别系统结构和约束，不是给系统贴唯一标签。
2. 重要维度包括部署、客户端关系、业务组织、集成方式、数据组织、处理时效和组织规模。
3. 集中式强调统一管理，分布式强调扩展和隔离但要处理网络与一致性，混合式用于兼顾全局和现场。
4. 共享数据、独立数据、事件、API、实时和批处理都有适用边界与工程代价。
5. 选型要结合业务矛盾、质量属性、组织能力、现状约束和演进路线。
6. 案例与论文要使用多维架构语言说明方案，而不是只写“采用分布式或微服务”。

本节的核心结论是：架构分类的价值在于看清系统不同侧面的约束。架构师通过多维分类建立结构视图，再把视图转化为组件、接口、数据、部署、治理和验证方案，才能避免被单一技术标签牵着走。