起重運輸機械與工程機械的監測云平臺研發及應用

周奇才 肖 樂 趙 炯 熊肖磊

同濟大學機械與能源工程學院 上海 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 擴充邊緣層的功能實現云邊協同作業，故云平臺具備良好的實用性和發展使用前景。