两种通信模式的分工
客户端服务模式里，客户端主动发起浏览、读、写、订阅与方法调用，服务器逐条应答，通信建立在上面的会话与安全通道中，可靠但有往返开销。发布订阅模式里，发布者不管有没有人在听，按周期把数据集投递到网络上，订阅者自行接收，没有会话、没有应答，因此可以高效地一对多分发。判断标准很直接：需要确认、需要结果、需要浏览配置的用客户端服务；周期性强、接收方多、时延敏感的用发布订阅。
基本信息
| 客户端服务 | 请求应答，含会话与安全通道，逐条确认 |
|---|---|
| 发布订阅 | 无会话，周期投递，一对多，无逐条确认 |
| 传输方式 | 客户端服务走二进制 TCP 等，发布订阅走组播、二层、消息中间件 |
| 可靠机制 | 发布订阅靠序号与看门狗发现缺包，而不是应答 |
| 典型分工 | 配置与命令用客户端服务，周期数据用发布订阅 |
| 共存方式 | 同一服务器可同时提供两种访问方式 |
典型使用场景
- 一台机组的状态每秒广播给多台上位机：发布订阅避免多份独立轮询
- 边缘网关把数据经消息中间件送上云：用发布订阅对接，跨越企业边界
- 下发配方、启动动作、复位计数：这类需要结果确认的操作仍走客户端服务
- 组态调试：用浏览与读服务核对模型，比看发布订阅数据流直观得多
- 带宽受限的现场总线：发布订阅的紧凑编码显著减少开销
- 冗余接收：多个接收方同时收到同一份数据，无需服务器复制连接
两种模式对照
| 维度 | 客户端服务 | 发布订阅 |
|---|---|---|
| 通信方向 | 客户端主动拉取 | 发布者主动推送 |
| 会话 | 需要，含身份与授权 | 无会话，靠安全组保护 |
| 确认 | 每条请求有应答 | 无应答，靠序号检测丢失 |
| 拓扑 | 点对点 | 一对多，可组播或经中间件 |
| 典型用途 | 浏览、配置、命令、历史 | 高频周期数据、跨网域分发 |
| 故障感知 | 调用失败有状态码 | 需要看门狗与序列号判断 |
分工示意
分工示意
# 采集侧：订阅过程量，走发布订阅，周期 100 毫秒
# 控制侧：写设定值、调用方法，走客户端服务并检查返回状态
# 配置侧：浏览地址空间、读取工程参数，走客户端服务
# 不要把关键的启停命令塞进发布订阅：没有应答就无法确认是否执行
# 也不要为几十个接收方各建一条订阅，带宽会被重复消耗两种方式可以在同一台上位机共存：用客户端服务做组态与命令，用发布订阅接周期数据，是工程上最常见的组合。
发布订阅默认没有接收方确认机制，如果业务要求必须知道对方收到，就不能只依赖发布订阅，必须另加确认通道。