5.1 采集服务器 MTU：主站的内部构造

5.1 采集服务器 MTU：主站的内部构造

本节摘要：采集服务器（历史上称 MTU，主终端单元）是主站与广域的分界面：规约接入、点表映射、实时库、事件处理四大模块在这里协作，把成千上万个远方测点变成一份有序的实时态势。本节拆解它的内部构造，讨论服务拆分的原则与度，并针对两类典型风暴——事件风暴与重连风暴——给出设防方法。

主站不是一台服务器

口头语里「主站」常被当成一台机器，实际上它是一组协作服务。把「主站」等同于「那台服务器」会导致两类设计错误：其一，所有服务塞进一台机器，单点故障一死全死；其二，反过来把服务拆得过碎，服务间调用链长得排障都困难。本节先看清楚里面有哪些模块，再谈拆分的原则与度。

一、四大模块的职责与协作

规约接入（前置驱动）。 每种规约一个驱动实例：104 驱动管远动站，Modbus 驱动管直连设备，MQTT 桥接管上级数据。它的职责是把字节流解析成「点表语言」的数据条目。工程要点：驱动实例按通道隔离（一个通道一个实例），单通道异常不拖垮全部接入；驱动参数（超时、重试、缓存）支持按通道画像分组，呼应 4.2 节的看护契约。

点表映射。 把规约层的信息地址（公共地址、信息体地址、寄存器号）翻译成系统内部点名。这张映射表就是 3.4 节权威点表的中心侧投影——映射关系应当从点表生成，而不是手工在组态工具里点选。映射表与点表版本对齐，是联调阶段「数据对不上」问题的头号解药。

实时库。 每个点名维护「最新值 + 质量标记 + 时标 + 刷新时刻」。实时库是主站的数据中枢：画面取数、报警判断、历史落盘都以它为唯一实时事实源。工程要点：未刷新检测（超过若干周期没更新的点自动降级为「疑似停滞」）、人工置数机制（检修期间强制画面状态，必须带标志与期限）、以及变化的增量通知（避免每个消费方都来全量轮询）。

事件处理。 越限判断、变位捕获、报警生成与分发都在这里。它消费实时库的变化通知，按点表里的报警配置（限值、回差、延时、分级）生成报警事件。工程要点：判断逻辑与显示逻辑分离——报警事件的生成分级在服务端完成，客户端只负责呈现，这样报警统计与确认状态全网一致。

图 5-1 主站服务的分层与数据路径

二、服务拆分：原则与度

拆分的原则一句话：按故障域与负载特性拆，不按功能清单拆。据此，三类拆分几乎总是值得的：前置与后台分离（前置直面通道风暴，重启频率天然高于后台）；历史库独立（落盘负载平稳但量大，且它的故障不该波及实时监视）；报表与分析独立（分析型查询耗资源，不能与实时业务抢内存）。反过来的合并建议也有：中小项目的报警服务与前置合设、画面服务与 Web 服务合设——服务越少，排障路径越短。一个实用的判断法：写出你打算部署的每个服务，标注「它崩了影响谁、多久恢复」，如果两个服务的答案完全相同，就考虑合设。

三、风暴设防：主站的抗压设计

主站的宕机很少因为平均负载，几乎都因为风暴。两类典型风暴与设防：

事件风暴。 某工艺系统异常，数百个点同时越限，报警与上送报文瞬间叠加。设防三层：通道层，规约的事件队列与背压（4.2 节的带宽余量在这里兑现）；接入层，按优先级调度——事件报文先于周期报文处理；应用层，报警合并与风暴预案（同源同类报警在窗口期内合并成一条「风暴摘要」，细节进日志不进弹窗）。5.2 节的报警设计会继续展开。

重连风暴。 中心短时故障或广网抖动恢复后，上百个站同时重连补传，接入层瞬时负载可达平时数十倍。设防：站端网关重连退避（4.3 节实录一已用）、中心接入层分批放行（重连请求排队，按批次恢复调度）、补传窗口错峰（各站补传起点随机化）。某集团项目的实测：加了分批放行后，中心恢复过程的内存峰值从翻三倍降到抬升四成——风暴设防的收益都以「事发那一次」计价，平时完全隐形。

五、性能容量：主站的体检指标

主站需要一组持续的体检指标，投运后按月查看：接入健康度——各通道在线率、轮询超时率，反映通道与前置的耦合质量；实时库负载——每秒变化处理量、增量通知队列深度，队列持续增长是消费方拖垮实时库的先兆；事件通道时延——事件从产生到推送至操作员站的耗时，秒级内为正常，超过即查服务间链路；资源水位——前置与历史服务器的处理器与内存使用率，冗余系统的主备两侧要对称（一侧常年偏高说明负载不均，切换时风险不对称）。指标阈值写入运维手册，越限动作与责任人挂钩。这套指标的本质是给主站装上「心电图」：风暴来临前的征兆（队列增长、时延爬升）总能提前被看见，看见就有处置窗口。

容量规划的口径随之而来：接入点数按终期、变化率按实测、通知队列按风暴场景校核——数字都来自本节各模块的机理，不为凑数，只为在评审会上回答「凭什么这个配置够用十年」。

六、组态管理：主站的版本纪律

主站组态（点表映射、画面、报警配置、报表模板）的版本纪律与站端程序同等严格：变更走流程、发布有版本、可回退。特别强调两条。其一，组态与点表同源生成的部分不允许在组态工具里直接改——发现点表有错，修点表再重新生成，杜绝「图快直改」造成的两处不一致（3.4 节仲裁者地位的维护）。其二，发布窗口——组态发布安排在低负荷时段，发布前自动备份、发布后抽点核对（挑十个点核对画面取数与实时库一致）。主站组态错误的影响是全局性的：一个映射错位会让某个站的数据整体张冠李戴，且不易察觉——版本纪律是这类事故的唯一防线。

七、前置容量速算：评审会上要答得出的数

主站配置的合理性常被一句「按经验」带过，这里给出可直接用的速算口径。接入侧：通道数乘每通道轮询频率得请求速率，按规约单请求往返时延折算并发压力，前置的处理能力按峰值三倍配置；实时库侧：测点数乘平均变化率得每秒变化处理量，万点级水厂实测通常在每秒数千次变化，实时库与通知机制的容量按这个数校核；事件侧：按「同站全告警」风暴假设计算事件生成峰值，验证推送链路不积压。三个数算完，主站配置的每一项都能在评审会上给出「为什么够」的回答——这比任何厂商推荐配置都更有说服力，也让扩容决策有据可依。

本节要点回顾

• 四大模块：规约接入、点表映射、实时库、事件处理；映射表由权威点表生成，不手工维护。

• 按故障域拆分：前置、历史、分析独立值得；功能清单式的过碎拆分是排障灾难。

• 实时库是唯一实时事实源：未刷新检测、人工置数带期限，杜绝旧值伪装。

• 风暴设防三层：通道背压、优先级调度、应用层合并；重连要退避、分批、错峰。

数据在主站站稳了。下一节面对真正的用户——操作员：画面怎么排，才能让紧张时刻的判断又快又准。