产品概览
NG Gateway 是一套面向 工业/边缘场景 的高性能 IoT 网关：以 Rust + tokio 为运行时基础，用 背压友好的数据管线 把南向多协议采集数据标准化，并以北向插件可靠转发到平台，同时提供运行时可插拔插件化扩展能力
核心优势
端到端系统设计：为什么能跑得快、跑得稳（Backpressure-first）：
- 有界队列 + 背压传播：下游变慢时系统自动“减速”，避免无界堆积导致 OOM
- 故障域隔离：以设备/通道/插件为粒度隔离任务，单点异常不扩散
- 结构化并发：stop/reload 有干净的取消路径与资源回收能力
- 可观测性内建：队列深度、重试/退避、延迟、丢弃都能被度量与告警，不靠“感觉”运维
- 统一模型与可组合流水线：协议/平台/规则的变化被限制在清晰边界内，核心演进成本可控
丰富的内置南向驱动与北向插件（开箱即用）：
- 南向驱动体系覆盖 Modbus / OPCUA / S7 / DNP3 / Ethernet-IP / IEC104 / DLT645 / CJT188 等多协议（内置 + 可扩展）
- 北向插件体系覆盖 MQTT / Kafka / Pulsar / ThingsBoard 等多平台对接（可按需启用，隔离风险与变更）
- 工程化交付：插件/驱动具备元信息探测（probe）、动态schema扫描（excel导入模版及ui层渲染）、版本与平台信息校验，便于治理与运维
南向采集“批处理计划算法”（现场友好、性能友好）：
- 批量读写与拆分策略：针对 Modbus / S7 等协议的帧长/PDU/时延约束，按点位集合自动分组与拆包，大量减少往返与系统调用开销
- 面向异常的调度策略：设备忙、超时、噪声帧、短暂断连等场景可恢复处理，并通过退避/限流把抖动限制在局部
- 资源可控：热点路径避免频繁分配，优先使用预分配、复用与零拷贝解析等最佳实践
大规模并发与资源可控（面向生产）：
- 海量设备并发模型：以设备/通道为粒度组织任务，结合有界队列实现背压传播，避免“慢平台拖垮全局”
- 故障域隔离：把失败限制在设备/通道/应用（App）/插件边界内，避免级联雪崩
- 可控降级路径：当下游不可用或拥塞时，优先选择“减速/丢弃/缓存/回执失败”等可解释策略，而不是静默堆积
便捷部署与多架构适配（低成本落地）：
- 低资源占用：Rust 原生二进制更利于低内存边缘环境（容器/裸机均可）
- 多架构交付：面向 x86_64 / aarch64 等常见架构适配，插件/驱动按平台拆分交付
- 多样部署方式：单机、Docker、Helm、离线包等方式可选，满足从试点到规模化的交付路径
运行时可插拔扩展（Web-UI / HTTP API 多入口）：
- 热插拔安装/卸载：支持通过 HTTP API 上传并安装南向驱动与北向插件（以及 Web-UI 的可视化入口）
- 治理约束清晰：当驱动仍被南向通道引用、或插件仍被北向应用（App）引用时，系统会阻止卸载，避免运行中断与配置漂移
- 扩展不污染核心：高变化能力（平台适配、行业规则、增强处理）优先沉淀在插件侧，核心保持稳定抽象与高吞吐路径
身份验证与安全性（默认安全基线）：
- 加密传输：API 服务支持 TLS/HTTPS 加密链路，降低边缘侧明文传输风险
- 认证授权：支持 JWT 认证与 RBAC/权限规则，满足多角色的运维与审计需求
- 供应链治理：插件/驱动具备探测与校验信息（版本/平台/校验和等），便于发布、回滚与审计
统一数据模型与数据类型（让“对接”可复用）：
- 统一语义：把“协议差异”限制在 driver 内，把设备/点位/值/时间戳/质量位等语义上收为统一模型
- 多载荷策略：北向可选 JSON/Proto/Raw（透传） 等载荷策略，兼顾调试效率与吞吐性能
一键进入更多垂直场景（只换插件，不改核心）：
- 上层应用与行业系统：MES / ERP / SCADA / 能耗 / 产线看板等
- 数据处理与存储：大数据平台、时序库、湖仓、告警与工单系统
- AI 分析与边缘智能：边缘侧预处理/聚合/过滤，云端 AI 推理/异常检测的闭环接入
核心概念
术语与边界
- gateway core（核心）：高吞吐异步管线与资源治理中心，提供背压、限流、重试/退避、观测与生命周期管理。
- southward（南向体系）：面向现场设备的接入边界（driver + channel + collector 等），负责连接、读写、解析、容错，并把协议语义映射为统一数据模型。
- driver（驱动）：面向一种协议或设备族的能力包，负责连接、读写、解析与容错；把协议语义映射为统一模型。
- channel（通道）：南向侧的连接与资源边界，通常对应一条串口、一条 TCP 连接或一个共享会话（通常它是一个南向驱动的实例化）。
- device（设备）：现场真实存在的对象（表计、PLC、传感器…），具备唯一标识、连接信息、点位集合与运行状态。
- point（点位/数据点）：设备上可读写的“变量”（寄存器/对象/节点）。point 是统一数据模型的最小粒度之一。
- collector（采集器）：运行时的采集执行单元，把采集策略（周期/批处理/订阅）转为可预测的调度行为。
- northward（北向体系）：平台连接器集合（MQTT/Kafka/Pulsar/ThingsBoard等），负责可靠投递与上下行闭环。
- plugin（插件）：运行时可插拔的扩展单元，通常承载 northward 平台对接、以及统一模型上的转换/增强能力；插件应具备清晰的资源边界与可回收性。
- app（应用）：北向侧的“业务编排单元”，用于把 southward 的数据流与 northward 插件/路由策略关联起来（通常它是一个北向插件的实例化）。
记忆法
southward/northward 是“边界面”，core 是“交通枢纽”。
统一数据模型：为什么它是“网关的心脏”
现实世界协议千差万别：Modbus 是寄存器，S7 是 DB/变量，OPC UA 是 NodeId，IEC104 是遥测/遥信……如果每个协议都定义一套上报结构，北向对接会迅速失控。
统一数据模型的目标是：
- 让北向只关心“业务语义”：设备、点位、值、时间戳、质量位、事件、动作、控制。
- 让规则/转换可复用：同一条规则可以对 Modbus/S7/OPC UA 的同类点位生效。
- 让可观测性可聚合：吞吐、延迟、错误率能够按 device/driver/channel/app 维度统计。
TIP
建议把“协议地址/寄存器号/NodeId”作为 meta 存放（如果必要），不要让它污染北向业务字段。
core pipeline：把一切串起来的数据流
一个典型的数据流（上行）是：
- collector 触发采集（或订阅回调触发）
- driver 执行读写并解析
- 产出统一事件/点位值
- core 做可选的转换/过滤/聚合（边缘计算）
- northward 编码并发送
- observability 记录日志与指标
对应的下行（控制）是反向流动：
- northward 收到平台命令
- core 校验/鉴权/限流
- southward 找到目标 device/driver
- driver 执行写入/控制
- 返回执行结果并回执（可选）
生命周期：启动、运行、停止（优雅退出）
在边缘网关里，“优雅退出”不是锦上添花，而是避免现场事故的刚需：
- 启动：加载配置 → 初始化日志/metrics → 加载驱动/插件 → 创建设备任务 → 建立北向连接
- 运行：采集/上报循环 + 健康检查（可选：热更新/热插拔）
- 停止：停止采集调度 → 取消 in-flight 任务（带超时）→ 关闭连接/串口 → flush 缓冲（可选）→ 退出
最佳实践
无论 stop 还是 reload，都要有“上限时间”