九大服务集详解：OPC UA的通信骨架
说实话，OPC UA 协议里最核心的部分，就是这九大服务集。它们就像是一栋大楼的承重墙，所有上层应用都建立在它们之上。我最早接触 OPC UA 时，就是先啃透了这些服务集，后面做项目才顺手很多。
咱们一个一个来看。每个服务集我都结合自己的项目经验讲，保证你听完能记住。
1. 发现服务 (Discovery Service Set)
发现服务，说白了就是「找设备」。客户端怎么知道服务器在哪？支持哪些协议？这就是发现服务干的事。
它包含三个主要操作：
- FindServers：客户端发个广播，问「附近有哪些 OPC UA 服务器？」
- GetEndpoints：找到服务器后，问「你支持哪些连接方式？安全策略是什么？」
- RegisterServer：服务器主动向发现服务器注册自己。
我踩过的坑： 有一次现场调试，客户端死活连不上服务器。查了半天，发现是发现服务器地址配错了。你想想看，客户端连发现服务器都找不到，后面所有操作都白搭。所以我的习惯是，先单独测试 FindServers 能不能返回结果。
2. 安全服务 (Security Service Set)
安全服务是 OPC UA 的护城河。它负责三件事：身份认证、消息加密、权限控制。
核心操作包括：
- OpenSecureChannel：建立安全通道，协商加密算法和密钥。
- CloseSecureChannel：关闭安全通道，释放资源。
这里有个关键点：安全通道是独立于会话的。什么意思？一个会话可以对应多个安全通道，但实际项目中我建议一对一，省得管理混乱。
注意： 安全策略不能乱选。我曾经见过有人为了省事，直接选 None（无加密）。结果数据在网络上裸奔，被第三方抓包看了个精光。工业现场，安全无小事。
3. 会话服务 (Session Service Set)
会话服务管理客户端和服务器之间的「对话」。它解决的是：你是谁？你能待多久？
主要操作：
- CreateSession：客户端发起会话请求，服务器返回一个 Session ID。
- ActivateSession：激活会话，这时候才真正验证用户身份。
- CloseSession：结束会话。
嗯，这里要注意：会话是有超时时间的。我遇到过客户抱怨「连接老断」，一查是会话超时设得太短，只有 30 秒。后来改成 5 分钟，问题就解决了。
4. 节点管理服务 (Node Management Service Set)
这个服务集，是 OPC UA 地址空间的「增删改查」。你可以把它想象成数据库的 DDL 操作。
操作包括：
- AddNodes：添加节点（变量、对象、方法等）。
- AddReferences：添加节点之间的引用关系。
- DeleteNodes：删除节点。
- DeleteReferences：删除引用。
我的经验： 动态添加节点时，一定要先检查节点 ID 是否冲突。我见过一个项目，两个配置工具同时往服务器里写节点，结果 ID 重复，整个地址空间乱套了。加个互斥锁，能省很多麻烦。
5. 查询服务 (Query Service Set)
查询服务，就是 OPC UA 的「搜索引擎」。它让你能按条件查找节点，而不是一个个遍历。
核心操作：
- QueryFirst：发起查询，返回第一批结果。
- QueryNext：获取后续结果（分页用）。
查询语法基于 OPC UA 的查询语言，支持过滤条件、排序、投影等。说白了，就是 SQL 的简化版。
我个人习惯是，在大型系统中优先用查询服务，而不是遍历所有节点。效率能差几十倍。
6. 属性服务 (Attribute Service Set)
属性服务，用来读写节点的属性值。这是最常用的服务集，没有之一。
主要操作：
- Read：读取一个或多个节点的属性值。
- Write：写入属性值。
- ReadHistoricalData：读取历史数据。
- WriteHistoricalData：写入历史数据。
| 操作 | 用途 | 注意事项 |
|---|---|---|
| Read | 读取当前值 | 支持批量读取，减少网络往返 |
| Write | 写入新值 | 注意写入权限和数据类型 |
| ReadHistoricalData | 读取历史趋势 | 需要服务器支持历史数据存储 |
避坑指南： 我曾经在批量写入时，一次性写了 1000 个节点。结果服务器直接超时，一个都没写进去。后来改成每批 100 个，加上重试机制，就稳了。记住：大包拆小包，稳字当头。
7. 方法服务 (Method Service Set)
方法服务，允许客户端调用服务器上定义的方法。这就像远程过程调用（RPC）。
核心操作：
- Call：调用一个方法，传入参数，获取返回值。
方法可以定义输入参数和输出参数。比如，一个「启动电机」的方法，输入是电机 ID，输出是启动结果。
我建议你在设计方法时，尽量让每个方法只做一件事。单一职责原则，在 OPC UA 方法里同样适用。
8. 监控服务 (Monitor Service Set)
监控服务，用来订阅数据变化。它解决了「轮询」的低效问题。
主要操作：
- CreateMonitoredItems：创建监控项，告诉服务器「我要盯着这些节点」。
- ModifyMonitoredItems：修改监控参数（采样间隔、触发条件等）。
- DeleteMonitoredItems：删除监控项。
- SetMonitoringMode：启用/禁用监控。
监控服务配合订阅服务，是 OPC UA 实现实时数据推送的关键。你想想看，如果每个数据都靠客户端轮询，网络压力得多大？
9. 订阅服务 (Subscription Service Set)
订阅服务，是监控服务的「搭档」。它负责管理监控数据的发布和通知。
核心操作：
- CreateSubscription：创建一个订阅，设置发布间隔。
- ModifySubscription：修改订阅参数。
- DeleteSubscription：删除订阅。
- Publish：服务器主动向客户端推送数据变化。
我的习惯： 订阅的发布间隔不要设得太短。我见过有人设 10 毫秒，结果服务器 CPU 直接飙到 100%。工业现场，100 毫秒的刷新率已经很快了。除非你有特殊需求，否则别追求极致延迟。
总结一下
九大服务集，各有各的职责。发现服务负责找，安全服务负责守，会话服务负责管，节点管理服务负责建，查询服务负责搜，属性服务负责读写，方法服务负责调用，监控和订阅服务负责推送。
做 OPC UA 开发，你不需要把每个服务集的每个细节都背下来。但你要知道：遇到什么问题，该用哪个服务集。剩下的，查规范就行。
嗯，这章就讲到这里。下一章咱们聊聊 OPC UA 的地址空间模型，那可是 OPC UA 的灵魂所在。