这篇演示项目其实是个比较特别的组合歌里的“Actorfromwork”估计是手滑正确拼写是LabVIEW的Actor Framework。我自己也是反复看了好几眼才确认你问的其实是两个东西——Actor Framework这个官方异步架构加上发布订阅观察者模式的事件总线。我专门把这个组合搭成了一个叫ESA的演示项目Event Subscription Architecture事件订阅架构用来解决LabVIEW上位机里最让人头疼的多模块数据分发问题。如果你写过超过三个并行循环的LabVIEW程序一定体验过那种滋味采集循环要给界面、日志、报警各传一个队列引用今天加个新窗口明天加个新模块采集那边就得跟着改。这篇文章就是这个ESA演示的手把手拆解从消息类定义到总线Actor实现再到我实际踩过的坑适合对Actor Framework有一点点了解、想摆脱全局变量和队列满天飞的开发者。1. 内容整体设计与思路拆解1.1 Actor Framework究竟在解决什么问题很多LabVIEW开发者从单线程转到多线程第一反应就是“循环加队列”。主界面一个循环采集一个循环存储一个循环三个循环靠队列互相传数据程序跑起来确实没问题。但问题是循环一多队列引用就要手动到处传。我见过一个测试机程序光是队列引用就建了十多个每个VI的输入面板上全是队列端子改一个地方得顺着数据流追半天。这个阶段还算好的真正崩溃的是你新增一个功能模块的时候采集数据原本只给界面显示现在要加日志、加报警、加数据库采集循环就得维护更多队列引用逻辑越来越臃肿。Actor Framework就是来治这个病的。它把每个并发单元封装成一个Actor每个Actor内部有一个独立信箱消息队列外部向Actor发消息Actor在自己的循环里处理形成了“消息驱动”的状态机。这样每个Actor只关心自己收到什么消息、怎么处理不用关心消息是谁发的。这就像公司里每个员工一个邮箱别人发邮件给你邮箱自动收你按轻重缓急逐个处理。框架本身还帮你处理了Actor的启动、停止和错误传递不用再自己手动管理循环的退出条件。Actor Framework的精髓是消息类。每条消息都是一个继承自Message.lvclass的对象里面打包了“你要让目标Actor做什么”的所有数据。当消息被投递到目标Actor的信箱框架会自动调用消息的Do.vi在目标Actor的上下文里执行对应逻辑。这种设计把“命令”变成了“数据”代码的可测试性和可扩展性一下子高了很多。不过呢Actor Framework默认只解决“点对点”通信你想让A把数据同时通知B和C还是得在A那里保存B和C的地址B和C改了A也得跟着改。这就引出了我加装发布订阅模式的核心动机。1.2 为什么要用观察者模式/发布订阅模式观察者模式在软件工程里已经存在几十年了思路很简单有一个被观察者Subject一群观察者Observer被观察者状态一变自动通知所有观察者。打个最生活化的比方就是微信公众号的关注关系你关注了一个公众号它一发文章你的微信就会收到推送。公众号不需要知道一共有多少粉丝也不需要挨个私聊拼命通知微信平台替你完成了分发。发布订阅模式是观察者模式的升级版。在观察者模式里被观察者通常还是直接持有观察者的引用只是抽象了通知接口而在发布订阅模式里发布者和订阅者中间隔着一个事件代理Broker发布者只负责把事件丢给代理订阅者只负责告诉代理“我对哪类事件感兴趣”双方完全不知道对方的存在。这个解耦非常重要新增一个订阅者时发布者代码一行都不用改只要新订阅者向代理注册它就能收到数据。落到LabVIEW上位机场景情况就更实际了。采集模块只负责产生温度、压力、振动等数据界面模块要显示曲线日志模块要写文件报警模块要判断阈值。如果采集模块直接认识这三个下游那每增加一个下游采集模块都要加一个队列引用。引入事件总线后采集模块只发送“DataUpdated”事件总线负责查到谁订阅了DataUpdated再逐个投递。我后面这套ESA演示就是围绕这个核心思路搭建的EventBus就是那个微信平台采集Actor是公众号界面和日志Actor是粉丝。1.3 ESA演示的整体架构解析先解释一下标题里的“ESA”不是什么官方名词是我给自己这套演示起的代号全称Event Subscription Architecture核心就是“Actor Framework 发布订阅”的组合。整个演示由下面几个部分组成角色Actor名称职责事件代理EventBrokerActor维护订阅表接收发布消息并广播给所有订阅者发布者ProducerActor模拟数据采集周期发布DataUpdated事件不关心订阅者订阅者SubscriberActor实例1UI注册DataUpdated事件收到广播后更新前面板波形图订阅者SubscriberActor实例2Logger注册DataUpdated事件收到广播后写入CSV日志我特意让UI和Logger用同一个SubscriberActor类只是用不同的ComponentID来区分行为。这样做的原因后面会讲主要是为了规避Actor Enqueuer类型不统一这个坑对新手来说能少折腾很多。数据流非常简单Producer每200毫秒生成一个模拟温度值构造一条PublishMessage发给EventBrokerEventBroker查到自己维护的“订阅表”里有UI和Logger两个订阅者就把这条数据包装成EventNotificationMessage分别发给两个订阅者ActorUI收到后更新波形图Logger收到后写日志。全部都是异步消息没有一个人等待另一个人处理完。2. 核心细节解析与实操要点2.1 观察者模式/发布订阅模式原理再讲透如果你以前只接触过LabVIEW对“观察者模式”这个词可能有点陌生。它本质上就是“状态变化自动广播”的一种设计套路。温度传感器是一个数据源界面上有温度计、记录仪、报警器三个显示模块它们都对温度变化感兴趣。传感器一变不用手动一个个调函数通知状态一触发所有观察者自动被调用。传统写法里被观察者需要维护观察者列表通知就是遍历这个列表逐个调用回调函数。发布订阅在抽象层级上比观察者模式又高了一层。观察者模式的Subject和Observer之间仍有直接耦合而发布订阅模式引入了“事件总线”作为媒介。用之前的公众号比喻你不是直接打电话让公众号把文章发给每个粉丝而是粉丝在微信平台里关注公众号微信平台完成匹配推送。公众号不知道粉丝是谁粉丝也不知道公众号的推送逻辑。这个区别在Actor Framework里还有一个现实意义观察者模式的通知通常是同步回调一个观察者处理慢了被观察者就被卡住但在我们的Actor实现里通知是“把消息塞进对方的信箱”这一操作几乎是线性的、微秒级完成完全不是同步等待。订阅者们各跑各的循环处理快慢互不影响这非常适合LabVIEW那种天然并行、但对实时性要求不太苛刻的上位机场景。2.2 Actor Framework默认通信方式和发布订阅的差异我刚接触Actor Framework的时候最不习惯的就是它没有现成的“广播”功能。你只能一对一发消息所以一开始我以为要自己给每个订阅者都发一遍消息后来才意识到这种作法违背了开闭原则。先看一张我看重对比表场景点对点消息Actor Framework默认发布订阅加装EventBus发送方是否需要知道接收方是必须持有目标Actor的Enqueuer否只要知道总线的Enqueuer新增一个接收模块发送方代码要改增加一条发送路径接收模块自行注册发送方不动一对多广播不适合代码会迅速膨胀天然适合请求-应答非常合适返回消息易控制不适合总线转发做不到精准回复实现复杂度框架内置零额外工作需要自己写总线Actor和订阅表典型用途控制指令、参数设置、查询状态数据分发、状态通知、事件上报从这张表能看出来发布订阅不是要替代Actor Framework默认的点对点通信而是补充。控制逻辑、参数下发这类强关联通信仍然应该走点对点消息只有“一对多、业务方不知道彼此”的场景才值得动用事件总线。2.3 发布订阅架构的四个关键设计点在动手写代码前我建议先想清楚这四个点否则后面改起来挺折腾的。第一事件类型要独立于消息类。我会单独建立一个EventType枚举DataUpdated、StatusChanged、FaultOccurred把它设置成严格类型定义。注册时用DataUpdated发布时也用同一个DataUpdated。如果学习时省事直接放字符串拼写错了很难查枚举至少能在编译期兜底。第二订阅表的数据结构要明确。在EventBrokerActor的私有数据里我放了一个字典Map键是EventType值是一个队列引用数组数组里保存的是每个订阅者的Actor Enqueuer。这样当收到一个PublishMessage时总线只需要按事件类型查字典就能拿到所有订阅者。第三消息类至少要分成注册类、注销类和发布类。注册消息里要提着“我订阅什么事件类型”和“我的回邮地址”发布消息里要提着“发生了什么事件”和“事件载荷”。我后面把这几个类的细节都列出来了照着建就行。第四注册动作要由订阅者自己发起。订阅者最清楚自己关心什么事件所以不应该由Main.vi去逐个给总线发注册消息而是每个订阅者在自己Actor Core最开始的地方发一条RegisterMessage。关闭时再发一条UnregisterMessage。这样你把一个订阅者模块丢到任何系统里它能自己“找到组织”。3. 实操过程与核心环节实现3.1 环境准备与Actor Framework项目模板开始之前先确认一下你的LabVIEW版本。Actor Framework在LabVIEW 2018及以后基本已经是内置模板新版本更是直接集成在“创建项目”向导里。如果你用的是老版本可能需要额外安装Actor Framework工具包但思路是一样的。打开LabVIEW后选择“创建项目”在模板列表里找到“Actor Framework Application”新建一个模板项目。这个模板会生成一个最基本的Actor包含Actor类、Message类、主VI和几个已经写好的Helper VI。我建议新手用这个模板起步因为Actor的启动信息、Launch Actor.vi、Send Message.vi这些标准件都已经连好了比自己从空白项目搭建省事很多。项目结构上我会在项目面板里建两个文件夹一个叫Actors一个叫Messages。所有自定义Actor类放在Actors里所有继承Message.lvclass的消息类放在Messages里。看起来只是收拾整齐但对后面增删模块很有帮助至少不会让项目越写越乱。3.2 定义事件类型与消息类第一步先在项目面板里新建一个严格类型定义的枚举命名为EventType.ctl里面加入三个条目DataUpdated、StatusChanged、FaultOccurred。每次如果你新增一种事件就到这里加一个条目总线那边完全不用动。第二步定义载荷簇。我建了一个DataPayload.ctl里面包含三个成员ChannelU16、TimestampDouble、ValueDouble。对于演示程序来说够用了如果你是真实项目可以扩充成采集通道号、设备ID、单位等等原则就一个载荷应当是不可拆分的整体不要塞大量零散参数。第三步创建消息类。在Messages文件夹右键新建LabVIEW类父类选择Message.lvclass。对每个消息类你都需要重写Do.vi否则框架不知道这个消息到达目标Actor后该干什么。下面是这套演示里用到的几个消息类消息类成员类型消息去向说明RegisterMessage.lvclassEventTypeEventType枚举EventBrokerActor订阅者注册自己RegisterMessage.lvclassSubscriberEnqueuerActor EnqueuerEventBrokerActor订阅者的回邮地址UnregisterMessage.lvclassEventTypeEventType枚举EventBrokerActor订阅者注销自己UnregisterMessage.lvclassSubscriberEnqueuerActor EnqueuerEventBrokerActor同上PublishMessage.lvclassEventTypeEventType枚举EventBrokerActor发布者产生事件PublishMessage.lvclassPayloadDataPayload簇EventBrokerActor事件载荷EventNotificationMessage.lvclassEventTypeEventType枚举各个订阅者Actor总线广播给订阅者EventNotificationMessage.lvclassPayloadDataPayload簇各个订阅者Actor载荷每个消息类的Do.vi怎么做拿RegisterMessage举例在Do.vi里你会得到一个输入叫Target Actor这个就是目标Actor的实例这里是EventBrokerActor。你在Do.vi里调用EventBrokerActor的RegisterSubscriber.vi把消息自带的EventType和SubscriberEnqueuer传进去。看起来绕但这正是Actor Framework的标准工作方式消息本身只是“载具”真正跑动作的是目标Actor上的方法。3.3 手把手实现EventBrokerActorEventBrokerActor是整个ESA演示的心脏。新建一个Actor类EventBrokerActor.lvclass在私有数据里加一个“EventSubscriptionMap”键是EventType值是一个数组数组元素类型是订阅者的Actor Enqueuer。然后实现RegisterSubscriber.vi。函数逻辑是这样的先判断Map里有没有传入的EventType键如果没有就新建一个数组把SubscriberEnqueuer放进去如果有先检查数组里是不是已经有这个Enqueuer避免重复注册没有就追加。这个检查很重要我见过程序在重复启动订阅者后总线给同一个Actor发了两条一模一样的通知排查很久才发现是重复注册导致的。再实现UnregisterSubscriber.vi。这个函数里要用“删除数组元素”的方式把订阅表中匹配的Enqueuer移除。如果移除后数组为空最好把对应的键也一起删掉保持Map干净。最核心的是Publish逻辑。在EventBrokerActor的消息处理循环中当收到PublishMessage时代码大致是找到订阅表中对应EventType的订阅者数组 for each subscriberEnqueuer in array: EventNotificationMessage CreateEventNotificationMessage(eventType, payload) SendMessage(subscriberEnqueuer, EventNotificationMessage)这里有一个容易被忽视的点SendMessage这个操作要尽量轻量入队本身是微秒级的所以总线的消息循环不应该做计算、文件写入、弹窗这类耗时操作。总线的职责只是投递不是处理业务。如果你发现总线里开始做业务逻辑那就是架构慢慢歪了。3.4 手把手实现Producer和SubscriberProducerActor的代码非常简单它的Actor Core里是一个while循环每隔200ms调用一次Wait(ms)然后生成一个模拟温度值组成DataPayload簇构造一条PublishMessage通过Send Message.vi发给EventBrokerActor。这里最关键的概念是Producer完全不认识任何订阅者它只知道总线的Enqueuer。所以你在ProducerActor里千万不要保存任何界面引用、日志路径、报警阈值那都不该由发布者操心。SubscriberActor稍微复杂一点但也不难。我设计了一个通用订阅者类里面有一个属性叫ComponentID枚举为UI和Logger两个值。在Actor Core正式开始处理消息前先构造一条RegisterMessage把ComponentID要订阅的事件类型这个演示里就是DataUpdated和自己Actor的Enqueuer发给总线然后进入消息处理循环。在消息处理循环中给EventNotificationMessage添加一个分支。当收到这条消息时检查ComponentID如果是UI就把Payload里的Value值更新到前面板上的波形图控件注意控制更新频率别让UI线程被频繁重绘拖死。更新前面板控件在Actor的消息处理循环里是安全的因为前面板属于UI线程而消息是异步进来的。如果是Logger就把时间戳和Value组合成一行写入一个CSV文件。写文件要用带缓冲的方式别每来一条都打开关闭一次文件我通常会提前在Actor初始化时打开文件句柄关闭时再关闭。理论上这个SubscriberActor类可以无限扩展加一个DB组件ID就能写数据库加一个Alert组件ID就能做阈值报警这就是发布订阅模式扩展性好的直观体现。3.5 主程序启动与停止流程这套验证程序里最容易翻车的就是启动和停止顺序。我在第一次写的时候主VI里面依次启动EventBroker、Producer、SubscriberUI、SubscriberLogger结果日志订阅者才注册了一半Producer那边已经丢了好几条数据。プロducer是急性子不会等别人准备好。标准的启动顺序应该是启动EventBrokerActor确保事件代理先起来。启动SubscriberUI和SubscriberLogger。等待注册完成最简单的方法是Main.vi里用一个小Detector或SendMessage做握手如果你只是想演示用Wait延时几百毫秒也能凑合但工程里别这么随缘。再启动ProducerActor。停止顺序正好反过来先给Producer发送StopMessage等它完全退出循环。再给两个订阅者发送UnregisterMessage并停止它们。最后才停止EventBrokerActor。为什么必须反着来因为如果你先把总线停了Producer再发PublishMessage就会往一个已经不存在的队列里投递轻则产生错误重则卡死。同样如果先把订阅者停了总线的广播消息就没人接部分消息会积压甚至丢失。顺序是整个Actor系统稳定性的隐形契约。3.6 模拟数据与运行效果我在ProducerActor里故意把数据做得稍微“像样”一点每200ms产生一个Value公式是25 10 * sin(time * 0.5) random(-1,1)模拟一个带噪声的温度信号。UI实例的波形图会实时滚动显示Logger实例则在后台疯狂写CSV。跑起来以后你会发现不管事后你把Producer停掉、重启、再加一个新订阅者Producer那端的代码几乎不用改。这就是这次演示最爽的地方逻辑解耦之后你面对的不是一团乱麻的队列引用而是清晰的“事件”和“订阅”。4. 常见问题与排查技巧实录4.1 收不到消息先查注册顺序这是这套演示里被问得最多的问题。症状很统一程序跑起来UI和Logger界面毫无动静但Producer明明在发消息。绝大多数情况是订阅者还没注册完Producer就已经开播了。你可以这么排查先在EventBrokerActor的RegisterSubscriber.vi里加一个探针看两个订阅者是否真的完成了注册。如果发现最终订阅表数组是空的先不要怀疑总线转发逻辑八成是启动顺序问题。解决方法是加一个“注册完成确认”的握手或者至少让Producer在启动前等500ms以上。我习惯用握手因为延时的魔法数字在不同电脑上解读不同换台慢电脑可能又踩坑。4.2 界面卡顿和广播风暴Actor消息处理和UI更新同属一个循环但如果你让UI订阅者每收到一条消息就马上更新波形图频率太快时LabVIEW里面的波形图控件重绘会成为瓶颈。尤其是发布者每10ms发一条UI就要刷100帧/秒这不是UI能扛住的频率。常见做法是节流订阅者内部维护一个“上次更新时间”当两次广播间隔小于某个阈值比如100ms时直接丢掉这次更新。Logger倒是可以全量记录因为文件写入有自己的缓冲机制。还有一个更隐蔽的坑如果广播消息的载荷过大比如打包了整张图片总线每次把大块数据入队内存会涨得很快。这种情况下建议广播一个“新数据就绪”事件让订阅者按需向发布者拉取数据而不是把数据塞进每条消息。这就是典型的“推模型”换“拉模型”取舍。4.3 启动和关闭时卡死如果你在停止时发现程序一直退不干净大概率是消息循环里出现了循环等待。最常见的一种死锁是Actor A的消息处理中发了一条消息给Actor B然后在同一个消息处理过程中等待Actor B的回复而Actor B处理回复时又发消息给Actor A两个Actor互相等正好卡成一个环。Actor Framework虽然封装了并发但没有真正解决你设计上的循环依赖。另一种场景是在关闭时你给所有Actor都发了StopMessage然后Between各Actor的停止顺序不对。亮的经验是停止消息也要按依赖关系从“数据源头”开始发逐个停用不要试图并行地关掉所有Actor。4.4 Actor Enqueuer类型不统一怎么办这个问题是我做这套演示时踩得最深的一个坑。如果你把SubscriberUI和SubscriberLogger设计成两个完全不同的Actor类它们的Enqueuer类型也是不一样的不能用同一个数组保存总线那边根本没法统一转发。有一个取巧方案是把不同的Enqueuer存成Variant广播时再从Variant转回原始类型但每次转发都要转换代码难看还容易出类型错误。我更推荐用“基类统一”的方案让所有订阅者继承同一个抽象基类至少保证Enqueuer的类型是一个基类类型这样总线就可以用一个数组存储全部订阅者。另一个更省事的做法就像演示里这样多个订阅者本来就是同一个Actor类的不同实例差别只在ComponentID上。等到你对Actor Framework的机制更熟悉了再去拆独立类也不迟。4.5 和单例模式、全局变量比值得吗有很多同行写上位机第一反应是把数据丢进一个全局变量或单例里谁想看数据谁自己去读。这种写法在简单程序里很管用但程序一旦进入多线程并发状态问题马上来两个线程同时写一个全局变量到底以谁为准你不得不再加一堆锁、互斥变量高耦合状态的调试难度成倍增加。Actor框架加事件总线这种模式前期会多写一些类和方法但后期加模块、改逻辑基本就是增删消息处理分支的事。开发周期的账算下来这套架构在模块数量超过4个以后收益远大于成本。最后再分享一个我的个人习惯这套ESA演示里的EventBus我已经在不同项目里用了好几轮最大的感受就是“发布者永远是松快的”。你只要把总线和消息类定义清楚后面的Actor基本是即插即用。建议你拿到这套思路后先别急着扩功能把EventBrokerActor的注册、注销和转发三个消息跑通再往里加自己的业务Actor这个过程会顺畅很多。
