3、OPC UA通信模型：客户端/服务器架构、发布/订阅模式

聊到OPC UA的通信模型，我估计很多刚入行的朋友第一反应就是「客户端/服务器」。没错，这是OPC UA最经典、最常用的模式。但如果你只懂这个，那在实际项目中可能会吃不少亏。

我记得几年前做一个大型产线数据采集项目，现场有200多台设备，每台设备都要实时上报温度、压力、振动等参数。如果用传统的客户端/服务器模式，服务器端压力会非常大，而且网络稍微波动一下，数据就丢了。后来我换成了发布/订阅模式，问题迎刃而解。

所以今天咱们就把这两种模式掰开揉碎了讲清楚。

3.1 客户端/服务器架构（Client/Server）

这个模式说白了就是「一问一答」。客户端主动发起请求，服务器被动响应。就像你去食堂打饭，你跟阿姨说「我要一份红烧肉」，阿姨给你打一份。你不说话，阿姨不会主动给你打菜。

在OPC UA里，客户端和服务器之间通过会话（Session）来通信。建立会话的过程大概是这样：

1. 客户端发现服务器（通过Discovery Endpoint）
2. 创建通信通道（Secure Channel）
3. 创建会话（Session）
4. 激活会话（Activate Session）

嗯，这里要注意，每次通信都要走完这四步，开销其实不小。我在项目中遇到过一种情况：客户端每秒钟轮询一次数据，结果网络带宽被握手包占了一大半，真正传数据的包反而没多少。后来我调整了会话复用策略，才把性能提上来。

你想想看，这种模式最适合什么场景？我个人的经验是：配置下发、参数修改、历史数据查询。因为这些操作不需要太高的实时性，但要求可靠性和安全性。

举个代码例子，用Python的opcua库创建一个客户端：

from opcua import Client

# 创建客户端实例
client = Client("opc.tcp://192.168.1.100:4840")

try:
    # 连接服务器
    client.connect()
    
    # 获取根节点
    root = client.get_root_node()
    
    # 读取变量值
    temp_node = root.get_child(["0:Objects", "2:Device1", "2:Temperature"])
    temp_value = temp_node.get_value()
    
    print(f"当前温度: {temp_value} °C")
    
    # 写入参数
    setpoint_node = root.get_child(["0:Objects", "2:Device1", "2:Setpoint"])
    setpoint_node.set_value(75.5)
    
finally:
    client.disconnect()

这段代码看起来简单，但实际项目中坑不少。我曾经因为忘记调用disconnect()，导致服务器端会话泄漏，最后服务器直接拒绝新连接了。所以建议你用with语句或者try/finally来确保资源释放。

3.2 发布/订阅模式（Pub/Sub）

这个模式就完全不一样了。它像是一个「广播电台」——发布者只管往外发数据，订阅者只管收数据，双方不需要建立直接的连接。你想想看，这解决了什么问题？

对，就是解耦。发布者不需要知道谁在订阅，订阅者也不需要知道数据从哪来。而且最关键的是，数据是推送的，不是轮询的。这就意味着实时性更好，网络开销更小。

我记得在做一个风电场的监控项目时，风机分布在方圆几十公里的山头上。如果用客户端/服务器模式，每个风机都要跟中控室建立会话，网络延迟大不说，还经常断连。后来改用Pub/Sub模式，风机只管往MQTT Broker发数据，中控室订阅就行了。网络断了也不怕，Broker会缓存数据，等网络恢复后再补发。

OPC UA Pub/Sub支持两种底层传输方式：

传输方式	特点	适用场景
UDP多播	低延迟，不保证可靠	局域网内实时控制
MQTT	可靠传输，支持QoS	广域网、跨网络部署
AMQP	企业级消息队列	与IT系统集成

我个人习惯用MQTT，因为它生态好、部署简单。而且OPC UA基金会专门定义了OPC UA over MQTT的标准，用JSON或者UADP格式来序列化数据。

来看一个简单的Pub/Sub发布者代码示例：

from opcua import ua, Server
import json

# 创建服务器实例
server = Server()
server.set_endpoint("opc.tcp://0.0.0.0:4840")

# 注册命名空间
uri = "http://example.pubsub.demo"
idx = server.register_namespace(uri)

# 创建发布者配置
pub_config = server.create_publisher_config(
    publisher_id="PLC_001",
    writer_group_id=100,
    transport_profile=ua.PubSubTransportDataType.MQTT,
    address="mqtt://broker.emqx.io:1883"
)

# 添加数据集
dataset = pub_config.add_dataset("TemperatureData")
dataset.add_variable("Temperature", ua.Variant(25.0, ua.VariantType.Double))
dataset.add_variable("Pressure", ua.Variant(101.3, ua.VariantType.Float))

# 启动发布
server.start()
print("发布者已启动，正在发布数据...")

订阅者这边就更简单了：

from opcua import Client

# 创建订阅者客户端
sub_client = Client("opc.tcp://localhost:4840")
sub_client.connect()

# 创建订阅
subscription = sub_client.create_subscription(100, None)

# 添加监控项
node = sub_client.get_node("ns=2;i=1001")
handle = subscription.subscribe_data_change(node)

# 回调函数处理数据
def data_change_notification(node, val, data):
    print(f"收到数据: {node} = {val}")

subscription = sub_client.create_subscription(100, data_change_notification)
subscription.subscribe_data_change(node)

3.3 两种模式的对比与选择

说了这么多，到底什么时候用C/S，什么时候用Pub/Sub？我总结了一张表：

对比维度	客户端/服务器	发布/订阅
通信方式	同步请求-响应	异步推送
实时性	中等（受轮询周期影响）	高（事件驱动）
网络开销	高（频繁握手）	低（一次连接持续推送）
可靠性	高（会话保证）	中（依赖底层传输）
扩展性	差（服务器压力大）	好（支持一对多）
典型场景	参数配置、历史查询	实时监控、数据采集

我个人建议：不要非此即彼。实际项目中往往是两种模式混用。比如用Pub/Sub做实时数据采集，用C/S做参数配置和诊断。我上一个项目就是这么干的，效果非常好。

最后说一句，OPC UA的通信模型设计得其实很灵活。你完全可以根据自己的需求来组合使用。关键是理解每种模式的本质，而不是死记硬背概念。

下一章咱们聊聊订阅机制的具体实现，包括订阅参数怎么调优、数据变更通知怎么处理。到时候我会分享一些我在现场调试时踩过的坑，保证让你少走弯路。