边缘与云架构
物联网的平台层不只是"一台服务器" ，而是一条从现场到数据中心的连续光谱：哪些计算靠近设备做、哪些放到云上集中做，决定了系统的时延、带宽、可用性与隐私边界。这一章讲清云-边-端如何分工、边缘计算与雾计算到底差在哪、什么时候必须把计算下沉到边缘，最后落到 IoT DC3 的平台层形态——一个网关加四个中心服务，协议驱动可贴近现场、中心服务可集中部署，由 Facade 模式在分布式与同进程之间一键切换。
读完你能判断：一个采集任务、一条告警规则、一次命令下发，应该落在端、边、还是云。
这一层是什么 / 为什么存在
把物联网的平台层拆成三段，是因为这三段的物理约束根本不同。
端是设备本身——传感器、执行器、PLC、电表。它算力极弱、只懂自己的协议，目标是把物理量变成可传输的信号、把命令落到寄存器。它不该承担业务逻辑，更扛不住大模型推理。
云是远端的数据中心——算力近乎无限、存储廉价、便于集中管理与全局分析。它擅长把成千上万台设备的数据汇到一处，跑历史分析、训练模型、提供统一的 API 与界面。它的代价是"远"：每一跳都要穿过广域网，时延、带宽、连接稳定性都不由你掌控。
边是夹在两者之间的那一层——部署在靠近设备的现场（车间、变电站、楼宇机房），算力比设备强、比云弱，但离设备只有一跳局域网 。它存在的全部理由，就是把那些"等不起云、也不该等云"的计算就地做掉。
为什么需要边缘？归根到底是四个现实约束：
- 时延：一条产线上的急停联锁要求毫秒级响应，命令绕一圈云端往返几十到上百毫秒，可能已经造成事故。控制闭环越紧，越必须就近做决策。
- 带宽 ：一台振动传感器每秒上千个采样点，几百台设备的原始波形全量上云，广域带宽既贵又扛不住。边缘先做降采样、特征提取、聚合，只把" 有意义的结果"上云。
- 可用性：现场到云的网络会断。断网期间，采集不能停、本地联锁不能失效、告警不能哑——边缘要能脱网自治，等网络恢复再补传。
- 隐私与合规：摄像头画面、产线工艺参数、能耗明细，往往不允许或不愿意离开厂区。敏感数据在边缘就地处理、只上传脱敏结果，是很多行业的硬约束。
换句话说，云负责"广"，边负责"快"与"稳"，端负责"接"。三者不是替代关系，而是按职责切开的连续体。
关键技术与权衡
边缘计算与雾计算：常被混用，但侧重不同
两个词都指"把计算从云下沉到靠近数据源处"，差别在下沉到哪一层、谁来承担：
- 边缘计算（Edge Computing）：计算发生在网络的最边缘——设备本身或紧邻设备的边缘网关上。强调"尽可能贴近数据产生点" ，单点、轻量、面向具体现场。
- 雾计算（Fog Computing）：由 OpenFog 等组织提出，强调在"端与云之间"构建一个分层、分布式的计算与网络层 ——可能横跨多个网关、本地服务器乃至区域机房，是一张协同的网，而不只是单个边缘节点。
实践中可以这样记：边缘计算是"把活儿放到边上做"这件事，雾计算是"把边上这些算力组织成一层有协同、有调度的基础设施" 。本章后续不强行区分二者，统一用"边缘"指代"端与云之间的就近计算层"。
端-边-云三层如何协同
下面这张图把三层的职责与数据/命令流向铺开。关键不在每个框里有什么，而在哪条边是局域网、哪条边是广域网——这决定了什么计算该放在哪一侧。
图里实线是上行数据、虚线是下行命令；端到边是"局域网一跳"，边到云才跨广域网。把这条边界看清，"该放哪"的答案就自然浮现：时延敏感、断网仍要工作的逻辑放在 边（甚至端），全局视角、海量存储、模型训练放在云。
边缘网关的职责
边缘网关是这一层的承重墙，它至少要扛起五件事：
- 协议适配：把现场五花八门的协议（Modbus、OPC UA、BACnet……）归一成平台能理解的统一数据形态。这是它最基础也最不可省的职责。
- 过滤与聚合：在上云前做降采样、去重、特征提取、窗口聚合，把带宽用在刀刃上。
- 本地缓存与补传：断网时把数据落到本地，恢复后按序补传，保证不丢点。
- 边缘自治：脱网期间维持采集、执行本地规则与联锁、就地产生告警，不依赖云端心跳。
- 安全边界：作为现场网络与外网的唯一出入口，承担鉴权、加密、最小暴露面——现场设备不直接裸露到公网。
权衡在于：网关承担越多，现场越自治、越抗网络抖动，但运维与一致性也越复杂（边缘节点多了，配置同步、版本升级、状态可观测都成问题）。 边缘做多少、云做多少，是这一层最核心的设计取舍。
数字孪生：物理实体在数字侧的镜像
数字孪生（Digital Twin）是给每一台物理设备/产线/工厂建一个持续同步的数字镜像 ：它聚合该实体的实时位号值、历史曲线、模型结构与运行状态，让你在数字侧观察、推演、甚至预测物理侧的行为。
它依赖前面整条链路：端采集、边聚合、云汇总，孪生体才有"活"的数据喂养。孪生通常落在云侧（需要全局数据与算力），但其实时刷新 依赖边缘把最新值及时上行。它的价值在于把"散落的位号值"重新组织成"以实体为中心"的视图——这正是从原始数据走向智能运营的关键一跃。
云平台的核心能力
云侧平台通常围绕四类能力构建，它们正好对应"设备怎么管、连接怎么管、数据怎么用、规则怎么跑"：
- 设备管理（Device Management）：设备/模板/位号的建模、注册、生命周期、远程配置与固件管理——回答" 系统里有哪些设备、它们能干什么"。
- 连接管理（Connection Management）：设备在线/离线状态、心跳与超时、鉴权与会话——回答"谁连着、连得稳不稳"。
- 规则引擎（Rule Engine）：在数据流上配置条件触发——阈值告警、联动、转发，把"数据"变成"动作"。
- 数据服务（Data Service）：时序存储、查询聚合、对外 API——把海量位号值变成可消费的数据资产。
这四类能力共同构成云平台的骨架。值得强调的是：它们并非全都必须留在云。规则引擎与部分数据服务完全可以下沉到边缘 ——这恰恰是"边云如何分工"的实践空间。
工程要点
设计一套云-边-端系统，几条经验贯穿始终：
- 按"等不等得起云"分配计算。先问一个问题：这段逻辑断网时还能不能停？不能停的（控制联锁、本地告警、采集缓存）下沉到边；能等、需要全局视角的（趋势分析、模型训练、跨厂对比）放到云。
- 上云的是"结果"而非"原始流"。边缘先做聚合与特征提取，广域带宽永远是稀缺资源，别拿它传可以在本地压缩掉的冗余。
- 边缘必须能脱网自治。把云当成"会断的依赖"来设计：断网期间核心功能不能瘫，恢复后能自动补传与对齐。
- 命令链路要有明确的失败语义。下行命令跨广域网更易超时，必须区分"成功""失败""超时"，失败不能伪造成成功——否则上层据假数据决策会酿成更大问题。
- 统一数据模型贯穿三层。端的原始信号、边的聚合值、云的入库值如果各说各话，孪生与分析就无从谈起。一套稳定的"位号语义" 应当从边一直贯通到云。
在 IoT DC3 中如何落地
IoT DC3 的平台层不是一个大单体，而是 一个网关加四个中心服务 ，南向由协议驱动接入现场。这套形态天然能在"边"与"云"之间分布。
协议驱动 = 可下沉到边缘的那一层。 DC3 的协议驱动（dc3-driver-*）负责协议适配与就近采集，正对应"边缘网关" 的核心职责。驱动与数据中心之间不直连，而是经 RabbitMQ 异步收发——位号值往北上行、命令往南下行。这层异步解耦正是边云能分开部署的前提：驱动可以贴近现场跑，把广域网的抖动挡在 MQ 这道缓冲之外，采集不会因为云端变慢而反压掉线。
**四个中心服务 = 可集中部署的云侧能力。 ** 鉴权中心 dc3-center-auth、管理中心 dc3-center-manager、数据中心 dc3-center-data、智能中心 dc3-center-agentic 覆盖了前面说的"设备管理 / 连接管理 / 规则引擎 / 数据服务"——其中连接管理（设备/驱动的在线离线状态、租约过期检测）与规则（告警）引擎主要落在数据中心 dc3-center-data，设备/模板/位号的元数据管理由管理中心承担；此外中心服务还提供鉴权租户、LLM 与工具调用等能力。位号值最终落入 TimescaleDB 时序库并对外可查，这是云侧"数据服务"的具体形态。
Facade 模式 = 边云分工的开关。 中心服务之间的相互调用面向 dc3-common-facade-api 的契约接口编程，运行时由 DC3_FACADE_MODE 决定实现：grpc（分布式默认） 让各中心独立成进程、跨进程协作，适合" 中心集中在云、驱动散布在边"的拓扑；local（单进程）把所有中心合一跑在一台机器上，适合本地与小型单机。也就是说，" 边云如何分工、要不要分布式"在 DC3 里被收敛成一个部署开关，而不是两套代码——同一份业务逻辑，换 DC3_FACADE_MODE 即可在两种形态间切换。
把这一章的概念映射到 DC3
- 边缘网关的"协议适配 / 过滤 / 采集" → 协议驱动
dc3-driver-* - 边云之间的异步解耦缓冲 → RabbitMQ（位号值上行 / 命令下行）
- 云侧"设备元数据管理" → 管理中心
dc3-center-manager - 云侧"连接/状态管理"（在线离线、租约过期）→ 数据中心
dc3-center-data - 云侧"数据服务" → 数据中心
dc3-center-data+ TimescaleDB - 边云分工的部署开关 → Facade 模式
DC3_FACADE_MODE
关于"边缘自治"的实现边界
本章描述的"边缘脱网自治"是云-边-端架构的通用目标。DC3 中驱动贴近现场部署、经 MQ 与中心解耦，为这种分工提供了结构基础；具体到某个驱动在断网期间维持多少本地能力，取决于该驱动的实现。需要确认时，以对应驱动源码与 系统架构 描述为准。
完整的服务拓扑、端口分配与启动依赖见 系统架构 与 服务与拓扑 ；边云分工背后的接口装配细节见 Facade 模式。