起重运输机械与工程机械的监测云平台研发及应用

周奇才 肖 乐 赵 炯 熊肖磊

同济大学机械与能源工程学院 上海 201804

0 引言

起重运输机械与工程机械本身结构复杂，且其工作环境极其恶劣，突发的故障将会带来时间、资金方面的巨大损失。在这种情况下，有必要对其关键零部件进行实时的状态监测，以实现及时的故障处理措施，保证相关工作的顺利进行[1]。

大型工程机械设备有许多需要监测的关键零部件，以盾构机为例，电动机、刀盘、掘进机、排土机构等都需要进行故障监测，致使数据量巨大，数据结构和组成相当复杂[2]。工业现场投入使用的工程机械数量往往不止1 台，将所有监测程序部署在1 台高性能计算机上是极低性价比的做法，且庞大的程序难以满足数据处理的时效性、准确性要求，也不利于功能扩展。而且，如果为每个部分的监测程序单独配置1 台服务器，每台服务器都需要进行环境安装、功能测试等，这将会带来建设周期长、硬件资源浪费等问题。因此，更合理的方式是配置分布式计算机集群作为云平台，将监测程序部署作统一管理。

同一机械设备的不同部件监测对计算机集群的资源要求不均衡，也不总是同时工作，部件在运行高峰期需要的计算资源要求往往数倍于低谷期。为此，要求云平台不但要方便地部署和管理各监测程序，还能随时、便捷、按需进行资源的分配与释放，尽可能降低管理人员的介入频率。

针对以上需求，本文对一种基于K8s 开发的云平台架构进行研究应用，使具备该架构的高性能服务器集群可部署多部件乃至多设备的监测程序，对平台作容器化管理。在满足程序便捷部署和扩展的基础上，平台既能提供处理多种状态数据的中间件和数据库，又能依据业务需求管理程序，按需地调整程序获得的计算资源，且平台本身具备一定的故障处理能力。图1 为云平台应用场景示意图。

图1 云平台应用场景示意图

1 平台架构设计

1.1 功能要求

为了适应工业设备大数据环境下的业务需求，实现平台计算、存储资源的按需分配，在接入多个不同部件或设备的实时状态监测系统时，云平台应具备以下功能：1）平台上的微服务程序和消息中间件实现容器化，使其能统一进行全生命周期的维护管理，支持平台的调配；2）平台以1 套统一且便捷的流程部署对应监测部件的微服务程序，使云平台在硬件资源充分的情况下可以扩展或引入更多监测程序；3）平台可以监测业务程序对资源的使用状况，给出运维人员进行分析决策、调整资源的分配策略；4）平台具备高可用性和程序故障处理能力；5）平台可扩展与边缘设备协同处理业务的能力，提高业务的时效性和安全性。

1.2 平台整体架构

如图2 所示，根据工作属性的不同可将设备监测系统云平台的整体架构分为容器管理层、平台监控层、数据处理层、边缘层等4 个层次。

图2 平台各层次作用示意图

1）容器管理层 该层主要由容器编排工具及运维人员编写的系统任务组成，体现平台的核心功能。通过开发人员编写的配置文件或提交的指令，基于镜像仓库中存储的程序镜像，对监测系统各微服务容器进行快速创建或销毁，以及对平台的消息中间件进行扩缩容，进而实现平台计算资源的按需分配。同时，容器的故障发现与恢复、服务发现、负载均衡、安全防护、滚动更新、版本回退等功能都在该层实现，维持监测服务的持续稳定运行。

2）平台监测层 该层对云服务器的计算资源及运行于云服务器上的容器进行状态监测，并呈现可视化界面，可直观地显示整个云平台的运转状况，同时资源分配的信息可保存于日志文件中。该层可为运维者或开发者提供一个参考方向，使其能够完善计算资源的分配策略，制定相关的容器控制代码，或是考虑对平台的硬件资源进行提升。另外，对平台的可视化管理一般集成在可视化监控页面，故亦归于该层中。

3）数据处理层 该层由监测系统执行程序、平台提供的消息中间件的实例以及数据库等组成，可继续细分为数据输入处理、数据业务处理和数据持久化等3 方面。设备监测的数据经过这一层处理后，最终展示在可视化页面给用户查看。

4）边缘层 该层由传感器、嵌入式微处理单元、网络传输模块等组成，可实现数据采集、数据预处理、本地缓存、联网上传等功能。在该架构下，边缘层可扩展出与云平台协同处理数据的能力。

2 基础技术

2.1 微服务程序

各监测系统的软件端以SpringBoot ＋SpringMVC＋Mybatis 集成的框架技术为主体进行开发，使用高效的敏捷开发模式[3]。其执行程序可打包成多个微服务程序，其中微服务的概念是将一个系统按业务划分成多个子程序，每个子程序都是完整且可独立运行的。子程序间的交互可通过HTTP 协议进行通信（也可采用消息队列来间接通信，如RoocketMQ、Kafaka 等），这种子程序即本文所述微服务程序。

微服务架构的概念区别于传统的整体式架构。在整体式架构中，所有进程紧密耦合作为单项服务运行，这意味着如果应用程序的一个进程遇到需求峰值则必须扩展整个架构的载体。随着代码库的增长，添加或改进整体的功能变得更加复杂，也使未来添加或扩展新的功能变得更困难。同时，相互紧密耦合的进程会扩大单个进程故障的风险。使用微服务架构，针对业务各部分（本文中为监测个体或监测个体的组成部分）开发的应用程序作为独立组件，应用程序根据不同功能可继续拆分。所有轻量级的程序通过明确定义的接口进行通信，并合作完成业务功能。由于各业务为独立运行，故可轻松实现各项服务的更新、部署和扩展。

2.2 消息组件

云平台提供MQTT 服务器程序，用于接收采集端传递的数据，同时配有分布式数据处理软件、消息中间件（如Flink、Kafka、Redis 等），可承担起数据在微服务之间通讯中转、解析、缓存消峰等功能。数据库使用MySQL 与Hadoop 搭配，依据数据的特点提供不同类型的持久化功能。

1）Flink 是一款分布式的计算引擎，既可作数据的批处理（即处理静态的数据集、历史的数据集），也可作数据的流处理（即处理一些实时数据流），实时地产生数据的结果。

2）Kafka 是一种高吞吐量的分布式发布/订阅消息系统，其通过O(I)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB 的消息存储也能保持长时间的稳定性能。

3）Redis 是一款开源的基于内存的键值对存储系统，主要被用作高性能缓存服务器使用。Redis 独特的键值对模型使之支持丰富的数据结构类型，即其值可以是字符串、哈希、列表、集合、有序集合。同时，由于Redis 是基于内存进行工作，免去了磁盘I、O 速度的影响，故其读写性能极高。

2.3 容器化与K8s

程序容器化是指将程序代码、运行所需的环境、配置文件等打包形成一个可交付的镜像文件，该镜像可在需要时生成运行实例，而这个运行实例即被称作容器。容器之间相互隔离，相比使用虚拟机，其优势在于能够共用宿主机内核，占用资源小，启动快；而其可灵活部署、按需伸缩的特点适配微服务程序，故容器是微服务的优秀载体。

K8s 是用于自动化部署、扩展和管理容器化应用程序的开源系统。其能在1 组异构服务器上管理、编排多个容器实例组合而成的应用，并提供完善的管理工具，涵盖开发、部署测试、运维监控在内的各个环节[4]。在构建和管理容器云时，目前2 种主流的工具分别是Spring Cloud 和K8s。Spring Cloud 重点关注微服务架构的实现，且仅能使用Java 语言环境进行应用程序的开发；而K8s 重点关注容器编排技术，其设计目标就是支持通用的大规模容器集群，且支持多种语言开发的应用。在部署和管理容器化应用时，使用K8s 的集群通用性更强大，组件的生态圈更丰富，故本文所述监测云平台使用K8s 作为主体进行开发。

3 平台搭建

设备监测云平台整体架构围绕容器＋K8s 进行构建。容器技术将应用程序封装到容器中，K8s 进行容器编排，实现容器的自动化部署、集群管理及应用容器化管理。相比传统B/S 架构下的服务器，这种模式的云平台可提供DevOps 集成能力、持续发布策略以及扩缩容、服务治理等能力，让开发者更专注于业务逻辑的开发，充分利用容器云平台的能力，通过自动化缩短业务迭代上线周期、优化资源利用率、提高服务响应效率[5，6]。

3.1 K8s 集群搭建

本文所述云平台搭建2 主2 从的具备高可用性的K8s 服务器集群，所有设备监测服务的数据处理都在集群内部实现。K8s 集群可由Kubeadm 工具进行快速搭建，其中2 台主节点需要额外配置Nginx，搭配Keepalived实现高可用性，并使集群可以通过虚拟IP 访问，增加安全性。在搭建完成后，选择专门的容器网络插件（如Flannel）使Pod（在K8s 中是最基本的调度单元，为1 个或1 组容器的集合）之间可以相互访问，Pod 和Service 等其他模块也能相互访问，实现K8s 集群内部的扁平化网络。操作者与集群的通信通过Kubectl 命令行工具实现。尤其是对K8s 集群的自动扩缩容策略、Pod 创建、公共资源的使用限制等相关功能进行配置，可通过编写Yaml 文件，用Kubectl 命令行上传并应用即可。

然后，安装Ingress Controller，其功能是对外部访问集群的流量进行路由转发。再用配置文件定义Ingress资源，确定流量路由规则与TLS 设置等信息，使数据能通过URL 访问到集群内部的Service，进而访问到指定的容器。需要说明的是，K8s 生态系统中有许多不同的Ingress 控制器可供选择，其中基于Nginx 的控制器提供了最广泛的配置项，是较主流的选择，故本文所述集群采用该控制器。

配置Harbor 作为平台私有的镜像仓库，制作的镜像都存储在该仓库中，即相当于存储在平台就近的服务器或可以专线连接的服务器中，在任务需要创建容器或故障调节时速度大幅提升。同时，镜像的升级、维护都可以由专门的操作人员负责，作到统一管理。

监测层由K8s-Dashboard 和Prometheus 对K8s 集群的资源状态进行监控，两者针对K8s 已有成熟的对接方案。其中，使用K8s-Dashboard 可通过一条调用配置文件的指令即可调用远程镜像部署在集群上，用于简单显示集群的状态；而Prometheus 搭配Grafana 这一高效的监控可视化模块开发工具，能呈现多样化的集群监控视图方案。通过页面观测集群状态，可以及时灵活调整云平台的资源配置方案。集群的整体架构及各软件的通讯关系如图3 所示。

3.2 数据输入处理

设备监测云平台搭建的目的是为了使设备监测系统能够快速上云，并使其开发流程变得简便高效。因此，平台内部应配置合理的消息中间件和数据库，并对微服务程序声明统一的接口。基于此，监测数据进入到云平台的K8s 集群内部后的处理流程如图4 所示。

图4 数据输入流程

MQTT 服务器负责接收各采集端传输的数据，由对应监测服务程序的订阅者接收。若设备的所有状态数据都具有结构简单、吞吐量小的特点，微服务程序可根据业务逻辑作数据解析，下一步即持久化进MySQL 数据库。若设备的状态数据是复杂异构的，且吞吐量大（如电动机振动数据采样频率可达7 万条/s，而温度数据采样频率则只需1 条/s），则需要经过订阅者快速将数据放入消息队列Kafka 中，以实现数据的缓冲、消除峰值，并作到异步处理。同时，流处理引擎Flink 时刻启动着对应程序的消费者任务，将Kafka 相应主题中的状态数据集（可能是一条条的Json 字符串），直接通过Iceberg 表格式，以字符串格式存储在Hadoop 中。这种方式能最大限度保证传输效率和格式兼容，足以应对多源异构的大数据，保证数据的一致性。在数据量巨大的特殊时段，可以通过K8s 增加Flink 的工作槽，提高处理任务的并行度。

3.3 数据统计与可视化

根据数据输入流程，数据以最高效率存储在了关系型数据库或分布式文件系统之中，还需进行统计处理或实时展示在可视化页面中供用户查看，其处理流程如图5 所示。

图5 数据可视化流程

关系型数据库中的监测数据体量小，直接由Java微服务处理，可实时输出到前端。Hadoop 中的数据体量较大，频率较高，仍需启动Flink 任务以流处理的形式进行解析。Flink 既可对大量数据或单条大体量数据以内存级别的处理速度解析，也可使用窗口函数进行聚合统计，然后快速写入缓冲数据库Redis。由于Redis直接使用内存进行数据的存储，使得前端视图层展示数据的时延尽可能低。同时，由于Redis 对数据只起到缓冲并中转的功能，故一般可设置其淘汰策略为全量LRU（All Keys-Least Recently Used）的策略。

在定义Redis 存储的数据结构形式后，各监测系统中负责可视化功能的微服务即可针对不同类型的展示数据，设置固定的前端模块，对接Redis 中的数据。这样增强了可视化端代码的可复用性，节省开发成本。

4 应用程序部署

以轨道打磨车的电动机监测程序为例，展示图6 所示云平台的部署容器流程。首先，将电动机监测系统的2 个Java 程序打包为可执行Jar 包，一个负责消费MQTT 服务器上的数据传入Kafka 消息队列，另一个负责将缓存数据库上的数据可视化展示至前端，将两者上传至云平台主节点。然后，为相应的微服务程序写一份Docker File 文件。在Docker 端执行构建指令后，文件中的一条条Linux 指令和参数按顺序执行，可将指定宿主机文件目录下的微服务封装成为镜像，进而将其推送至私有镜像仓库。

图6 平台部署流程

最关键的一步是编写Yaml 配置文件使微服务以定制化策略运行在云平台上。在配置文件中，指定构建Pod 用到的镜像以及容器需要暴露的端口等，指定Service 对端口进行映射，使外部对宿主机相应端口的访问能够转发给容器。在此基础上，根据业务特点编写资源配置策略，包括但不限于有：定义Deployment 对该服务进行健康检查和滚动更新，当程序实例出现问题时K8s 可自动将其从服务中删除，创建新的实例进行替换。定义HPA(Horizontal Pod Autoscaler）以配置自动缩放策略，使容器能根据业务运行时段的特点高效运行。在此案例下，电动机监测程序的2 个微服务的最大不可用实例和最大搜索实例设置为1，自动缩放的最多实例设置为10，并根据监听的CPU 占用率及占用率的上限来调整应用程序伸缩。K8s 的资源类型或是容器运行策略都是通过Yaml 文件中Kind 关键字声明的，较常用的配置项名称如表1 所示。

表1 配置文件常见项

以上配置文件可以写在一份Yaml 文件中，也可以写成多份Yaml 文件实现配置文件的复用，因为在实际工业环境下许多监测应用的健康检查、扩容策略等都是相同的。配置文件可通过ConfigMap 存储在K8s 中，与指定的Pod 进行绑定管理。

在完成以上步骤后，使用Kubectl 的Apply 命令即可让K8s 将仓库中的微服务镜像制作成实例，运行在云平台上。在命令成功执行后，即可在管理界面Dashboard 看到容器实例的运行状况。启动采集端进行数据上传，可在MQTT 服务器上看到有消费者链接，在Kafka 中创建消费者也能读取到采集的数据，以此证明微服务容器正常运行。

5 结语

本文研究了一种针对起重运输机械、工程机械或多设备监测系统均适用的云平台架构方案，尤其适用于大量设备需要监测的场景，实现了各部件或设备监测程序的高效部署和管理，并可兼容多类型数据监测的特点。根据设计方案，云平台内部使用容器化管理，搭建K8s集群，配套使用Nginx、Ingress、Harbor、Prometheus等工具进行平台管理。在数据处理端，设计了使用消息中间件搭配微服务的模式，确定了部署Kafka、Flink、Redis 等中间件进行数据中转、缓存处理，并使用MySQL、Hadoop 实现监测数据的混合持久化。

基于K8s 开发的云平台内部的应用管理、资源分配可进行直观监控和使用自动化策略。面对多源异构、吞吐量大的数据监测服务，该平台能实现良好的适配，胜任多种监测系统程序的部署。监测系统程序可拆分为多个微服务分别上传，只需定义好各自的数据接口即可部署应用在平台上，简化了开发和部署流程。

由于K8s 云平台符合云原生的架构理念，可进一步实现功能扩展（如DevOps 环境、持续交付、自动化部署等），还可使用KubeEdge 扩充边缘层的功能实现云边协同作业，故云平台具备良好的实用性和发展使用前景。