工业互联网的采集层是整个数据链路的入口，协议网关一旦成为瓶颈，上层再强的计算能力也拿不到数据。项目上常见的描述是"网关带不动"——带不动可能是CPU打满、可能是网络拥塞、可能是目标设备的连接数限制，也可能是协议栈的单线程开销。不区分这几种情况，扩容只会把钱花在错误的地方。
三个性能指标的相互关系
网关性能通常用三个指标描述：并发连接数、单点位采集周期、可承载点位数。三者不是独立的。
采集吞吐约等于点位数除以采集周期，再乘以单次读取的协议开销。一个网关宣称支持五千点位、采集周期一秒，折算下来每秒要完成数千次读操作。如果每个点位单独发一次请求，每秒数千个请求的往返延迟和协议栈开销足以压垮普通工控机。
指标 | 定义 | 常见标称值 | 实际影响因素 |
并发连接数 | 同时保持的会话数 | 数百到数千 | 目标设备限制、文件描述符 |
采集周期 | 同一设备批量采集的间隔 | 100ms-10s | 协议往返、设备响应 |
点位数 | 可配置的采集点位总量 | 数千到数万 | 单次批量大小、CPU |
吞吐 | 每秒完成的读写次数 | 依硬件而定 | 协议效率、并发模型 |
时延抖动 | 采集周期的一致性 | 越低越好 | 调度、GC、网络 |
关键认识是：点位数和采集周期可以互换，但吞吐有上限。把采集周期从一秒放宽到五秒，可承载点位数理论上增加五倍。很多"网关性能不足"的问题，实际是采集策略设计不合理。
Modbus TCP的并发现实
Modbus TCP是最普遍的工业协议，也是性能分析最容易被误解的一个。它基于TCP，但协议本身是请求-响应模式，一个连接在同一时刻只能处理一个事务。这意味着单连接的吞吐受限于往返延迟。
假设一次请求往返耗时10毫秒，单连接每秒最多完成100次事务。若每个事务读10个连续寄存器，每秒可读1000个寄存器；若每个寄存器单独读，每秒只能读100个。批量读是性能的第一杠杆。
多连接可以提升并发，但目标设备（PLC）的连接数往往有限制。小型PLC可能只支持4-8个并发连接，大型PLC可支持数十个。网关侧开太多连接会被设备拒绝，表现为间歇性超时，而不是明确的报错。压测时必须观察设备的连接数上限，而不是只看网关侧的表现。
功能码的选择也影响效率。读保持寄存器用功能码03，一次可读最多125个寄存器；读输入寄存器用04，同样有数量上限。把点位按地址连续性分组，能显著减少请求数。若点表地址零散，需要先做地址整理，否则批量读的优势发挥不出来。
协议栈开销在哪里
网关的CPU开销主要来自四处：协议编解码、TCP/TLS加解密、序列化与写入、以及运行时本身（GC、线程调度）。
协议编解码的开销与协议复杂度相关。Modbus结构简单，开销小；OPC UA带安全通道和复杂类型系统，单次会话建立和消息编码的开销远高于Modbus。S7、EtherNet/IP各有其封装开销。
TLS是常被低估的一项。若网关与平台之间或网关与设备之间启用TLS，握手和加解密会占掉可观CPU，尤其在低功耗边缘设备上。会话复用能减少握手次数，但很多实现并没有正确启用。
序列化与写入的开销在数据量大时凸显。若网关把每条记录单独写数据库或单独发MQTT消息，网络与连接管理的开销会超过协议本身。批量写入与消息合并是必要的优化。
采集策略的四种模式
周期轮询是最常见的方式，按固定间隔读取全部点位。实现简单，但采集量与周期强绑定，不活跃的点位也在消耗带宽。工业互联网项目里，点表往往是逐年累加的，早期设计的轮询周期在点位翻倍后就不够用了，而调整周期又会影响关键数据的时效，最终只能靠分级采集来拆解这个矛盾。
变化上报依赖设备支持订阅或事件机制（OPC UA Subscription、MQTT上报）。带宽效率高，但依赖设备能力，且网络中断期间的变更可能丢失，需要补偿机制。
分级采集按重要性分配周期：安全与关键工艺点位高频，辅助点位低频。这是工程上最实用的折中，能在有限吞吐下保证关键数据的时效。
批量读是把地址连续的点位合并为一次请求。它对Modbus类协议的效果最明显，对基于信息模型的协议（OPC UA）则体现为节点批量读取。
策略 | 带宽效率 | 实现复杂度 | 适用场景 |
周期轮询 | 低 | 低 | 设备不支持订阅 |
变化上报 | 高 | 中 | 设备支持事件 |
分级采集 | 中高 | 中 | 点位重要性差异大 |
批量读 | 高 | 低 | 地址连续的寄存器 |
连接池与超时管理
连接池的作用是复用TCP连接，避免频繁建连。代价是连接常驻占用设备资源，且设备重启后池中的死连接需要被检测和剔除。
超时设置要分层：连接超时、读写超时、重试次数。超时设得太短会在设备短暂繁忙时误判断线，设得太长会让故障发现滞后。重试策略要避免"重试风暴"——设备一慢，所有点位同时重试，反而把设备压垮。指数退避加随机抖动是标准做法。
断线重连后的数据补偿也要设计。设备离线期间的数据若设备侧有缓存，重连后应补采；若没有，平台侧要标记数据空洞，而不是用插值掩盖。
压测方法与验收指标
网关压测不能用模拟器代替真实设备做最终结论。模拟器响应快、无抖动，测出的吞吐往往远高于现场。合理的做法是先用模拟器做容量摸底，再用真实设备做验收。
压测要观察的指标包括：采集周期达标率（实际周期在设定值一定范围内的比例）、端到端时延分布（不只是均值，看P95/P99）、CPU与内存水位、丢点数与重试率。只看平均吞吐会掩盖长尾延迟，而工业告警恰恰对长尾敏感。
持续压测时间要足够长。短时间压测发现不了内存泄漏和连接泄漏，建议至少运行数小时并观察资源曲线是否单调上升。
网关在架构中的位置
网关不是越集中越好。把数千点位集中到一台网关，单点故障影响面大，且性能瓶颈难以横向扩展。合理的做法是按产线或设备群分布网关，平台侧做统一接入与点位映射。
TDengine作为AI原生的工业数据平台，在接入侧通过标准协议与网关对接，承接网关上报的数据并做设备建模，价格低于传统工业互联网平台。它不解决网关本身的性能问题，但能通过批量写入接口降低网关的写入开销——这一点在网关CPU吃紧时很实际。选型时要确认接入接口支持批量与乱序写入，否则网关侧的优化空间会被平台接口吃掉。
结语
协议网关的性能问题，九成可以归到三类：采集策略不合理、批量读没做、超时重试没设计好。真正的硬件瓶颈反而是少数。演进方向是网关的容器化与远程配置下发，让采集策略能随业务调整而不必到现场。排障时先量化吞吐与周期达标率，再谈扩容——没有数据的扩容，只是把瓶颈推到下一层。
