前几篇文章讨论DSC时，我们更多从”五层能力价值链”的框架角度来理解它。现在，当我们进入开发与部署阶段，需要把视角切换到更工程化的层面，来关注DSC在运行时是怎么工作的？它的”实时管控”能力依赖什么样的架构设计？
DSC的实时智能管控中心架构给出了答案。
多源异构数据源的接入
DSC管控中心的底层是数据源层。它不是只接一种数据，而是接四种完全不同的数据来源：
物联网数据。 设备传感器和IoT网关产生的实时数据流，在工业数据空间中最常见的数据类型。物联网数据的特点是频率高、单个数据量小、对时效性要求极高。
数据仓库数据。 来自各参与方数据仓库的结构化数据，批量加载、低频更新，但数据质量高、结构化程度好。
流式数据。 持续产生的、需要被实时处理的数据流，金融交易流、设备监控流、行为日志流。流式数据对DSC的实时处理能力有最高要求。
跨数据空间数据。 来自其他数据空间的数据，当一个数据空间需要与另一个数据空间进行互操作时，跨空间数据源的接入质量直接决定了互联互通的效果。
DSC不是”把数据统一存到一个地方再处理”，它在数据来源处就进行分类和预处理，不同类型的数据走不同的处理管道。
实时智能管控中心
DSC的核心处理引擎是一个”实时智能管控中心”，包含两个并行的处理模块：
事件流处理。 这是DSC的”实时判断”能力。来自所有数据源的事件流（使用请求、策略变更、安全告警）被持续采集，经过事件流处理引擎的实时分析和转换，判断每个事件是否需要触发管控动作。
当使用方A发起一个数据查询请求时，DSC的事件流处理引擎实时分析：A的身份是否有效？A的请求目标是否在其权限范围内？当前是否有安全告警影响A的访问状态？如果全部通过，请求被放行。如果任一项不通过，请求被拒绝并记录。
实时管控看板。 这是面向运营者的”一面墙”。所有数据流通的实时状态，包括：当前活跃的连接数、正在运行的数据任务列表、成功/失败的数据流通记录、最近的告警事件，都在一个Dashboard（实时看板）上展示。
运营者在看板上可以做的事：看到一个使用方的数据请求被异常拒绝，可以点开查看原因（身份证书过期），通知使用方更新证书后手动放行请求。
在数据空间故障排查中，DSC的实时看板是最直观的诊断工具，运营者可以实时看到”数据流通到了哪个环节被卡住了”，而不是”出了事之后翻日志才能找到原因”。
数据结构与通信方式
DSC支持结构化数据（关系表）和非结构化数据（文档、图片、日志）的混合存储。它的存储层不是”统一用一种数据库”，而是”根据数据类型选择最合适的存储引擎”。关系型数据库存结构化数据，文档数据库存非结构化数据，时序数据库存物联网时间序列数据。
异构数据传输通过多种方式实现：接口传输（API）、中间件（消息队列）、面向消息的传输（MQ、HTTP、Otter、文件共享）。DSC同时支持”GET”模式（服务端主动发起请求）和”POST”模式（客户端主动推送数据）。
DSC的实时管控中心不是什么革命性的技术发明——它是对一个古老工程原则的坚持：可观测性。在数据空间中，”可信”的前提是”可见”——运营者能看到数据空间中正在发生的每一件事。DSC的实时智能管控中心，就是让”可见”成为工程现实的那个组件。
我是BSN联盟成员。有着十年区块链与隐私计算的产品开发和方案咨询经验，先后参与多个国家重大课题，亲手建过区块链、隐私计算、可信数据空间的落地项目。不追概念，写真的。