Day28-36｜7.3.4 以数据为中心的体系结构风格：围绕共享数据组织处理能力

对应教材：《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”——7.3.4 以数据为中心的体系结构风格。

学习定位：本节是软件架构风格中的数据中心类风格，重点研究一个稳定的数据存储或数据中心如何成为多个处理构件协作的核心。教材中的典型思路包括仓库系统和黑板系统。高级系统架构设计师不仅要记住“共享数据”这一关键词，还要能分析数据中心、处理构件、控制构件和连接关系，说明集中共享带来的统一性、可扩展性和分析能力，以及中心瓶颈、模式耦合、并发一致性和安全治理等代价。

一、基本思想：数据是协作中心

以数据为中心的体系结构风格把系统看作一个或多个处理构件围绕中心数据存储协作。处理构件可以是业务模块、分析程序、编译阶段、规则引擎、报表工具或外部适配器；数据中心负责保存、检索、更新和管理共享事实，构件之间可以通过数据间接协作。

抽象关系可以表示为：

处理构件 A、B、C → 数据中心 ← 查询、分析、报表和规则构件。

数据中心可以是关系数据库、文件库、对象库、知识库、数据湖、共享内存或其他持久化平台。架构风格不由某个产品决定，关键在于多个处理构件是否围绕统一数据模型和共享事实组织起来。

这种风格适用于数据需要集中管理、多个构件需要共享和查询、处理过程依赖共同中间结果的系统。它与数据流风格不同：数据流强调数据依次经过处理步骤；数据中心风格强调多个处理构件围绕共享数据读写或协作，处理顺序不一定固定。

二、主要构件

2.1 数据中心

数据中心保存核心数据、元数据、状态、索引、知识或中间结果，并提供事务、查询、完整性、版本、备份和恢复能力。它的模式和访问策略是所有处理构件共同依赖的契约。

2.2 处理构件

处理构件负责特定的计算或业务处理，例如订单处理、库存分析、规则匹配、报表生成、语音识别和编译转换。构件应有明确的读写责任，不能把全部数据都当成自己的可修改对象。

2.3 控制构件

在普通仓库系统中，处理构件通常主动读取和更新数据；在黑板系统中，控制构件根据数据中心当前状态和知识源条件决定下一步激活谁。控制构件可以是工作流引擎、调度器、规则匹配器或人工操作台。

2.4 数据访问连接件

连接件包括查询接口、事务接口、数据访问层、文件读写、数据导入导出、消息同步和变化捕获机制。连接件应明确权限、超时、事务、版本、错误和审计，而不是只提供一个连接字符串。

三、仓库系统与黑板系统

3.1 仓库系统

仓库系统以稳定数据为中心，多个处理构件对仓库进行读写。传统信息管理系统、综合查询平台和许多数据库应用都体现这种结构。仓库通常负责数据持久化和一致性，业务构件负责具体处理。

仓库系统有利于统一主数据和跨模块查询，但如果所有构件直接访问全部表，数据结构就会成为强耦合接口。共享读取和共享写入必须区分，数据所有权、状态转换和写权限应明确。

3.2 黑板系统

黑板系统是以数据为中心风格的特殊形式，包括黑板、知识源和控制组件。黑板保存问题描述、中间假设、候选结果和处理状态；知识源根据黑板内容贡献自己的推理或处理结果；控制组件根据当前状态选择可激活的知识源。

黑板系统适合语音识别、模式识别、诊断、专家系统和复杂问题求解。它的优点是知识源独立、可以不断增加新策略；缺点是控制策略复杂，执行顺序不易预测，中间数据语义和一致性更难治理。

普通仓库更强调稳定业务事实和查询，黑板更强调问题求解过程中的动态中间状态，二者不能简单混为一谈。

四、风格的优点

4.1 统一事实和减少重复

多个构件围绕同一数据中心工作，有利于形成统一主数据，减少各模块自行保存和同步相同数据的成本。跨模块报表、审计和历史查询也更容易实现。

4.2 集中实施完整性

数据库约束、事务、版本、权限、备份和恢复可以在数据中心统一治理，减少客户端各自校验不一致的问题。对关键数据，集中完整性能够降低非法状态进入系统的概率。

4.3 处理构件可增加和复用

当数据模型和访问接口稳定时，新增报表、分析、搜索或规则构件不必修改全部既有构件。不同算法也可以围绕同一黑板或数据集进行组合。

4.4 便于全局分析

集中数据便于建立统一指标、历史趋势、数据质量检查和审计链路。对需要多主题关联分析的系统，数据中心比多个互不相通的数据孤岛更有价值。

五、风格的缺点与风险

5.1 中心瓶颈和故障集中

所有处理构件依赖数据中心，数据库性能、连接、存储和可用性会成为系统上限。即使应用有多个副本，数据中心故障仍可能造成整体不可用。因此必须设计冗余、故障转移、备份和恢复演练。

5.2 数据模式耦合

处理构件直接依赖表、字段和内部状态值时，任何模式变化都可能影响多个消费者。应通过外模式、视图、服务接口、版本契约和迁移窗口隔离变化。

5.3 数据所有权不清

多个构件同时修改同一实体，会造成业务规则分裂、状态覆盖、并发冲突和审计困难。共享数据不等于共享全部写权限，必须明确实体所有者和允许的状态转换。

5.4 事务和并发复杂

高并发写入可能导致锁等待、死锁、热点和长事务；跨模块事务扩大后会降低吞吐。若改用最终一致性，又需要事件、补偿、对账和中间状态查询。

5.5 技术替换成本高

当业务代码深入依赖数据库特性、存储过程、表结构和查询方言时，更换数据库、分拆数据中心或迁移到分布式存储会变得困难。

六、数据所有权和访问控制

应把数据访问划分为读取、提出变更和执行写入三种责任。其他构件可以读取脱敏视图、读模型或服务接口，但实体的状态写入由所有者完成。

数据库账户也应按构件和环境分权，避免所有服务使用一个超级账户。敏感字段需要列权限、脱敏、加密、审计和保留期限。若采用多租户仓库，还要在应用和数据层共同验证租户边界。

七、并发一致性与扩展

数据中心可以使用锁、MVCC、乐观版本、唯一约束、队列化或按实体分区控制并发。选择时要结合冲突概率、事务长度、读写比例和业务后果。库存扣减通常需要原子条件更新或版本校验；报表读取可以使用副本或读模型，但要注明数据延迟。

当中心负载增长时，可以采用索引、读副本、缓存、分区、分片、冷热分离、分析库和对象存储扩展。扩展前要分析查询模式、热点、事务范围和数据迁移，不能只增加服务器或数据库节点。

模式演化应尽量后向兼容：新增可选字段、兼容视图、双版本读写、逐步迁移消费者，再下线旧结构。数据迁移需要全量、增量、校验、对账、灰度和回退。若计划从共享数据库走向服务自治数据库，应先建立代码访问边界，再限制跨模块写入，最后分阶段迁移。

八、与其他架构风格的组合

以数据为中心的风格可以与分层、调用/返回、事件驱动和数据流组合。分层负责控制应用和基础设施依赖；仓库负责保存统一事实；事件负责传播数据变化；数据流负责批量清洗和分析。组合时必须避免多个事实来源和隐式写入。

例如订单平台可以让订单构件拥有订单主数据，数据库负责事务和持久化，订单变化通过事件通知库存和通知构件，报表通过只读模型或分析库读取。此时数据中心仍是事实来源，事件是变化传播机制，二者的职责不能混淆。

九、案例分析：科研数据与知识分析平台

某科研平台汇聚实验数据、设备数据、论文元数据和分析结果，研究人员可以使用不同算法进行检索、分类、关联分析和可视化。原始数据需要长期保存，分析算法经常增加，部分数据包含受限信息。

可以采用数据中心风格分层保存原始区、标准区和服务区。采集构件负责来源登记和质量检查，标准化构件将不同格式转换为统一模型，分析构件读取授权数据并写入带版本的分析结果，检索和可视化构件通过读模型和索引访问。数据目录记录来源、时间、质量、责任人、敏感级别和处理版本。

如果分析过程需要多个算法根据中间结果动态选择下一步，可以在分析区引入黑板机制；控制组件按候选结果和置信度调度知识源，并保存过程状态。原始数据只追加不覆盖，修订通过版本和派生关系表达，保证研究结果可重现。

安全上采用最小权限、受限字段、访问审批和审计；性能上用分析副本和异步计算隔离在线检索；数据迁移和模型升级通过兼容字段、批次校验和回放验证。这样既发挥共享数据的统一价值，又避免所有程序直接修改同一套内部表。

十、综合知识练习

练习1：单项选择

以数据为中心的体系结构风格最突出的特征是什么？

A. 数据必须依次经过固定过滤器
B. 多个处理构件围绕统一数据中心共享和协作
C. 所有处理必须由一个主程序控制
D. 每个构件必须完全隔离数据

答案：B。 该风格以共享数据中心为协作核心，但共享数据不等于所有构件拥有全部写权限。

练习2：多项选择

采用仓库或黑板风格时，需要重点考虑哪些问题？

A. 数据所有权和写入边界
B. 数据模式、并发和一致性
C. 数据中心的性能、可用性和恢复
D. 中间状态、控制策略和过程可追踪性
E. 所有构件共享超级账户

答案：A、B、C、D。 超级账户会扩大越权和误操作风险，不属于合理架构措施。

练习3：案例题

某平台由订单、仓储、财务和报表模块组成，所有模块都能直接修改同一批表；报表在交易高峰执行复杂关联查询；数据库触发器还会自动更新多个业务状态。系统经常出现状态覆盖、锁等待和无法定位的级联更新。请分析问题并提出改进方案。

参考答案：

1. 共享数据中心被误用为共享写空间，实体所有权和状态责任不清。
2. 报表查询与交易写入争用同一资源，复杂查询造成锁等待和性能下降。
3. 触发器隐藏了业务控制流，状态变化来源不透明，调试、测试和迁移困难。
4. 缺少版本、幂等和审计，多个模块更新同一状态可能互相覆盖。

改进时应明确订单、库存、财务和报表数据的所有者，限制构件只能通过受控接口或授权视图访问；核心状态采用状态机、版本控制、唯一约束和审计；将复杂报表迁移到读副本、分析库或读模型，并设置数据刷新延迟；对稳定的完整性约束可以保留数据库约束，对跨模块业务规则逐步移出隐式触发器，改为显式用例、可靠事件和补偿；完善事务边界、慢查询、锁等待和容量监控；模式和触发逻辑变更采用版本、回放和灰度验证。

十一、论文写作素材

论文论述以数据为中心的体系结构时，应从统一主数据、跨模块查询、知识推理或数据分析需求切入，说明数据中心、处理构件、控制构件和访问契约；重点写数据所有权、并发一致性、读写隔离、模式演化、备份恢复和安全审计。

可直接使用的句式：

针对多来源数据需要统一管理、多个处理构件需要共享事实且分析算法持续增加的特点，我采用以数据为中心的体系结构。数据中心负责持久化、完整性、版本、权限和恢复，处理构件通过受控接口访问数据，并明确各主题数据的唯一所有者和写入边界。交易写入、在线查询和离线分析分别通过事务区、读模型和分析副本隔离；对于中间结果需要动态求解的流程，引入黑板式控制并保存过程状态。通过数据质量检查、并发测试、备份恢复、模式迁移和权限审计验证架构目标。

论文中应主动写出共享数据的代价：中心数据容易形成瓶颈和模式耦合，多个构件直接写表会造成规则分裂。因此要配套读写权限、版本、状态机、契约、缓存、副本、审计和迁移机制，避免把“集中”误解为“任意共享”。

十二、今日复盘

本节主线是：

数据中心 → 处理构件 → 共享数据契约 → 所有权与权限 → 并发一致性 → 性能扩展 → 模式演化与恢复。

请回答以下问题：

1. 仓库系统与黑板系统有什么共同点和区别？
2. 为什么共享数据不能等同于共享写权限？
3. 数据中心成为瓶颈时，可以从哪些方面扩展？
4. 数据库触发器为什么可能让业务控制流变得难以维护？

最后选择一个订单、数据中台、知识库或分析平台，列出数据中心、处理构件、控制构件、数据所有者、写入权限和故障恢复方式。再设计一次模式升级和数据迁移，写清兼容、对账、灰度和回退条件，这些内容正是案例分析和论文中体现架构深度的关键。