3. OPC UA通信模型：客户端/服务器架构 vs 发布/订阅模式（PubSub）

好，咱们今天来聊聊OPC UA的两种通信模型。说实话，很多刚接触OPC UA的朋友，一上来就被这两个模式搞晕了。我当年也一样，总觉得客户端/服务器就够用了，干嘛还要搞个PubSub？

嗯，别急。咱们先理清楚这两个东西到底是什么，再谈怎么选。

3.1 客户端/服务器架构：经典的一对一通信

这是OPC UA最传统的通信方式。说白了，就是客户端主动去问服务器要数据。你想想看，就像你去图书馆借书——你是客户端，图书馆是服务器。你问“这本书在哪儿？”，图书馆告诉你“在三楼A区”。

在工业现场，这种模式很常见。比如一个HMI（人机界面）去读取PLC里的温度值。HMI发起请求，PLC响应。就这么简单。

我在项目中遇到过一个问题：一个车间里有50台设备，每台设备都要被3个不同的系统读取数据。如果用客户端/服务器模式，每个系统都要跟每台设备建立连接。你算算，50×3=150个连接。服务器端压力山大，网络也容易拥堵。

3.2 发布/订阅模式（PubSub）：一对多的高效通信

PubSub模式，说白了就是“你只管发，谁爱看谁看”。发布者（Publisher）把数据扔到消息中间件里，订阅者（Subscriber）自己去取。发布者和订阅者之间没有直接连接，完全解耦。

这就像电视台播新闻——电视台只管播，你家里有电视就能看。电视台不知道谁在看，你也不用告诉电视台“我要看”。

PubSub在OPC UA里主要依赖两种底层协议：一种是MQTT（轻量级消息队列），另一种是AMQP（高级消息队列协议）。我个人习惯用MQTT，因为它更轻量，在工业物联网场景下特别合适。

3.3 两种模式的对比表格

对比维度	客户端/服务器	发布/订阅（PubSub）
通信方式	请求-响应	发布-订阅
连接数量	N×M（客户端数×服务器数）	N+M（发布者数+订阅者数）
实时性	中等（受轮询周期影响）	高（事件驱动，即时推送）
网络开销	高（频繁请求）	低（数据变化才发送）
适用场景	小规模、点对点控制	大规模、数据分发、边缘计算
安全性	成熟（会话加密、认证）	依赖底层协议（MQTT/TLS）
实现复杂度	低	中高（需要消息中间件）

3.4 什么时候用哪个？我的实战建议

说实话，没有绝对的好坏。我一般这样选：

• 场景一：如果你只是做一个小型控制系统，比如一个PLC带一个HMI，或者一个SCADA系统监控几台设备。客户端/服务器模式完全够用，别折腾PubSub。
• 场景二：如果你要做车间级的数据采集，几十台设备的数据要汇总到MES或者云平台。我强烈建议用PubSub。我在一个电子厂的项目里，就是用OPC UA PubSub + MQTT，把200多台设备的数据实时上传到云端，网络压力小了很多。
• 场景三：如果你需要高实时性控制，比如运动控制、机器人协同。客户端/服务器模式可能不够快。PubSub配合TSN（时间敏感网络）可以做到微秒级同步。这个咱们后面章节会细讲。

3.5 代码示例：一个简单的PubSub配置

嗯，这里我给大家看一个OPC UA PubSub的配置片段。用的是UA-.NET标准库，实际项目中我经常这么写：

// 配置发布者
var pubSubConfig = new PubSubConfigurationDataType
{
    PublishedDataSets = new DataSetMetaDataType[]
    {
        new DataSetMetaDataType
        {
            Name = "TemperatureDataSet",
            Fields = new FieldMetaDataType[]
            {
                new FieldMetaDataType { Name = "Temperature", BuiltInType = (byte)BuiltInType.Double },
                new FieldMetaDataType { Name = "Pressure", BuiltInType = (byte)BuiltInType.Float }
            }
        }
    },
    WriterGroups = new WriterGroupDataType[]
    {
        new WriterGroupDataType
        {
            Name = "WriterGroup1",
            PublishingInterval = 100, // 100ms发布一次
            LocaleIds = new StringCollection { "en-US" },
            DataSetWriters = new DataSetWriterDataType[]
            {
                new DataSetWriterDataType
                {
                    Name = "DataSetWriter1",
                    DataSetName = "TemperatureDataSet",
                    KeyFrameCount = 10
                }
            }
        }
    }
};

// 配置订阅者（在另一个节点上）
var subConfig = new SubscribedDataSetDataType
{
    // 这里配置订阅的目标数据集
    TargetDataSet = new DataSetMetaDataType
    {
        Name = "TemperatureDataSet"
    }
};

你看，发布者配置了100ms的发布间隔，订阅者只需要声明自己订阅哪个数据集就行。完全解耦，爽不爽？

3.6 总结一下

客户端/服务器和PubSub，不是谁替代谁的关系。它们是互补的。客户端/服务器适合点对点的控制和管理，PubSub适合大规模的数据分发和实时采集。

我个人建议：如果你刚开始做OPC UA项目，先从客户端/服务器入手，把基础搞懂。等遇到性能瓶颈了，再引入PubSub。别一上来就搞复杂的架构，容易翻车。

嗯，下一章咱们会深入讲PubSub和TSN的结合，那才是真正的高实时性玩法。到时候我会分享一个我在汽车生产线上的实战案例，保证让你大开眼界。