图形化监控用数据动态刷新方法
码头的生产作业是一种需要多工种、多设备紧密配合的复杂过程，需要密切监控才能确保作业过程顺利完成。为此，码头生产操作系统（简称TOS）提供了图形化监控程序（简称监控程序），在码头地图背景上实时展示泊位、堆场、货位、货物、船舶、装卸设备和水平运输设备等各种图形对象，并用染色等方式标识出它们的当前状态、归属类别、作业计划等各方面特性，动态展示各作业线上装卸进度与效率等各种统计分析数据。这样，码头生产人员可以通过图形化监控界面（简称监控界面）全程掌握作业进度，以及场地、人员和设备等资源的调配情况，从而能及时发现问题并予以解决，减少船舶在港等待时间。 监控界面所展示的是大规模的生产作业数据，生产作业过程中随时有成百上千变化的数据被TOS提交到数据库，这些增加、删除或更改过的数据需要实时同步到监控程序上，刷新监控界面上相应的图形对象。为此，后台的动态刷新服务应该高效、准确地提取和组织好增量数据，推送给到处于N多个PC桌面/手持终端的监控程序，并能应对每个使用者在监控界面上展示自己关注数据的需求，即能定制局部数据的需求。 传统的动态刷新方法是一种基于触发器+日志表的技术，在TOS数据库相关表上添加触发器，将这些表的记录变化情况登记到专用日志表，然后由动态刷新服务定时轮询日志表获取日志并解析，再通过视图从TOS数据库中提取增量数据，推送到监控程序用于刷新监控界面的方法。在这个过程中，存在有以下两点问题，造成用户体验一般，效果不佳： 1，由于读写日志表、提取增量数据的数据库操作非常频繁，给数据库带来大的压力，轮询频率只能控制在秒级，动态刷新的实时性不高。 2，由于增量数据是由动态刷新服务群发到N多个监控程序上，再由监控程序自行过滤出局部数据的，这造成前后台持续有大流量数据，传输压力大。尤其是在稳定性差的无线网络环境，应尽量避免传输不必要的数据。 为提升用户体验，尽最大可能实时、准确和定制化地获取增量数据，减轻数据传输和数据库压力，本发明引入Actor分布式并行计算模型和面向切面编程方法： 1，Actor分布式并行计算模型：起源于Carl Hewitt在1973年提出的作为并行计算的概念模型。当今主流的云原生工具和运行时环境已能实现分布式系统架构下虚拟Actor计算单元的搭建、注册、寻址、激活、运行和释放，自动排除故障、恢复正常运行，实现分布式系统环境下的事件驱动和并行计算，具备实时性、可靠性、健壮性和可扩展性等技术特点，可支撑大规模实时数据处理和高性能计算，比如开源的Dapr云原生运行时环境和开发框架。 2，虚拟Actor计算单元（简称Actor）：指的是一个计算和状态独立的计算单元（相当于进程，不允许共享内存），可部署到分布式计算托管服务集群里，注册在集群的托管服务实例（即服务容器）上，由托管服务负责它们的寻址、激活、运行和释放，以及故障恢复。Actor对外界是透明的，由Actor关键字（简称ID）唯一标识，外界通过约定的ID访问具体某个Actor，而无需了解这个Actor在哪台服务器上运行，也无需关心怎么被激活和释放的。 3，发布-订阅模式（Publish-Subscribe Pattern，简称Pub/Sub）：是Actor实现事件驱动和并行计算的基础，也是动态刷新实时性和准确性的保证。Dapr的Pub/Sub组件封装了Pub/Sub中间件，包括主流的Kafka、RocketMQ、RabbitMQ等消息中间件，可以按需配置化使用。本发明在收发TOS增删改事件上采用的是RocketMQ。RocketMQ的事务消息机制可以保证本地事务和消息数据的一致性，确保TOS在执行本地事务和发送消息这两个操作上，要么都成功，要么都失败。而Kafka虽然也有事务消息机制，但只是为了保证它自己消息的Exactly Once语义上，不适用于本技术场景。 4，面向切面编程（Aspect Orient Programming，简称AOP）：是在不修改源代码的情况下，给程序动态统一添加额外功能的一种方法。AOP方法可以理解为对横切关注点的模块化封装，它包含了一组通知（Advice）和一个切入点（Pointcut）。通知定义了在目标方法执行的不同阶段（如方法执行前、执行后、抛出异常时等）需要执行的额外逻辑；切入点则用于精确匹配需要应用这些通知的目标方法。AOP方法有着广泛的用途，比如日志记录、性能统计、安全控制、事务处理、异常处理等等。现今主流的托管型语言如C#、Java等，都有现成的AOP开发框架和工具，具体取决于TOS服务用的语言，比如Java就选择AspectJ。AspectJ是一个开源的AOP框架，其定义了如何表达、定义AOP编程中的语法规范，还提供了编译器、调试工具等工具。本发明利用AOP方法截取TOS增删改数据，而没有采用类似Canal监听binlog日志的思路，主要出于数据库零压力、零侵入，以及自主可控、适配多数据库等方面考虑。TOS用的是Oracle、达梦等大型关系型数据库，而且不会捆绑在某个数据库上面，一套代码可以适配多数据库。本发明也采用同样思路，虽然类似Canal、OGG一些增量数据工具支持大多数主流数据库，但各自有原生适配的数据库，实际使用时会存在迁移适配、二次投入、单点故障等风险。 基于以上技术和思路，本发明构思如下：
如图一所示，监控界面所展示的数据并不一一对应到数据库表记录，大多需要通过多表关联查询获得，且局限于默认的范围。为规范起见，不管是单表还是多表查询，甚至是统计查询，都通过视图SQL语句获取全局数据，再由全局数据过滤为局部数据，供监控界面展示使用。界面刷新用到的增量数据，是TOS操作数据库产生的增删改数据，经历一系列数据整合和过滤处理，才被组织成增量数据。具体如下： 1，监控程序启动时，需要做初始化。一方面要从动态刷新服务获取全局/局部数据，用于构建监控界面，展示数据；一方面还要通过动态刷新服务订阅增量数据并建立起Socket连接，才能持续接收推送来的增量数据，刷新监控界面，直到程序关闭为止。 2，监控界面所展示的全局数据，具体是用视图名从动态刷新服务的全局Actor获取，全局Actor的ID用视图名标识。全局Actor在被激活时，先从TOS数据库中获取视图的SQL语句分析出查询的是哪些表，用这些表名作为Topic向Pub/Sub中间件订阅这些表的增删改事件，再用视图的SQL语句到TOS数据库上获取全局数据。视图SQL语句自带有条件语句，也就是可以有预设的默认范围。比如要展示堆场内的集装箱，也就是在场箱，视图的默认范围就是判断集装箱是否堆放在箱区，也就是其箱区ID属性有值的才被归类为在场箱。 3，监控界面所展示的局部数据，具体是用视图名和查询条件从动态刷新服务的局部Actor获取，局部Actor的ID用视图名+查询条件标识。局部Actor在被激活时，用视图名作为ID访问全局Actor，全局Actor根据提交来的查询条件，从全局数据中过滤出符合查询条件的局部数据，不需要操作数据库。比如要获取某个箱区的集装箱，可以用箱区ID作为查询条件访问在场箱的全局Actor，从在场箱清单中过滤出堆放在该箱区的集装箱。 4，增量数据的源头是持久层拦截器，替代传统的触发器+日志表模式。主要是利用AOP方法，在TOS持久层服务中织入（Weaving）持久层拦截器。当持久层服务提交增删改数据时，如果操作的表、增删改动作和更新的字段都在预设的监听范围内，则利用RocketMQ事务消息机制，把整个事务的增删改数据打包为增删改事件，用操作的表名作为Topic通过Pub/Sub中间件广播出去，供订阅这些Topic的全局Actor消费。另外，如果TOS持久层服务的框架可以修改，就直接将拦截器作为插件植入到框架中进行拦截，减少不必要的性能损耗。 5，全局Actor接收到持久层拦截器推送来的增删改事件，对增删改事件的内容进行解析，刷新全局数据的数据对象，将刷新过程组织成增量数据，广播给到Socket服务端和局部Actor。 6，局部Actor接收到增量数据，基于自己ID中的查询条件刷新局部数据，刷新完后将刷新过程组织成增量数据，广播给到Socket服务端。 7，Socket服务端接收到全局/局部Actor的增量数据，转发给到订阅的监控程序，用于监控界面的数据刷新。 以上构思，可以减轻码头图形化监控的数据传输和数据库压力，提升数据动态刷新的实时性与准确性，使得码头生产人员能够定制化实时监视生产作业过程，及时发现问题并予以解决，从而保证作业过程能够顺利完成。 |
