起重運輸機械與工程機械的監(jiān)測云平臺研發(fā)及應(yīng)用

周奇才 肖 樂 趙 炯 熊肖磊

同濟大學(xué)機械與能源工程學(xué)院 上海 201804

0 引言

起重運輸機械與工程機械本身結(jié)構(gòu)復(fù)雜，且其工作環(huán)境極其惡劣，突發(fā)的故障將會帶來時間、資金方面的巨大損失。在這種情況下，有必要對其關(guān)鍵零部件進行實時的狀態(tài)監(jiān)測，以實現(xiàn)及時的故障處理措施，保證相關(guān)工作的順利進行[1]。

大型工程機械設(shè)備有許多需要監(jiān)測的關(guān)鍵零部件，以盾構(gòu)機為例，電動機、刀盤、掘進機、排土機構(gòu)等都需要進行故障監(jiān)測，致使數(shù)據(jù)量巨大，數(shù)據(jù)結(jié)構(gòu)和組成相當(dāng)復(fù)雜[2]。工業(yè)現(xiàn)場投入使用的工程機械數(shù)量往往不止1 臺，將所有監(jiān)測程序部署在1 臺高性能計算機上是極低性價比的做法，且龐大的程序難以滿足數(shù)據(jù)處理的時效性、準確性要求，也不利于功能擴展。而且，如果為每個部分的監(jiān)測程序單獨配置1 臺服務(wù)器，每臺服務(wù)器都需要進行環(huán)境安裝、功能測試等，這將會帶來建設(shè)周期長、硬件資源浪費等問題。因此，更合理的方式是配置分布式計算機集群作為云平臺，將監(jiān)測程序部署作統(tǒng)一管理。

同一機械設(shè)備的不同部件監(jiān)測對計算機集群的資源要求不均衡，也不總是同時工作，部件在運行高峰期需要的計算資源要求往往數(shù)倍于低谷期。為此，要求云平臺不但要方便地部署和管理各監(jiān)測程序，還能隨時、便捷、按需進行資源的分配與釋放，盡可能降低管理人員的介入頻率。

針對以上需求，本文對一種基于K8s 開發(fā)的云平臺架構(gòu)進行研究應(yīng)用，使具備該架構(gòu)的高性能服務(wù)器集群可部署多部件乃至多設(shè)備的監(jiān)測程序，對平臺作容器化管理。在滿足程序便捷部署和擴展的基礎(chǔ)上，平臺既能提供處理多種狀態(tài)數(shù)據(jù)的中間件和數(shù)據(jù)庫，又能依據(jù)業(yè)務(wù)需求管理程序，按需地調(diào)整程序獲得的計算資源，且平臺本身具備一定的故障處理能力。圖1 為云平臺應(yīng)用場景示意圖。

圖1 云平臺應(yīng)用場景示意圖

1 平臺架構(gòu)設(shè)計

1.1 功能要求

為了適應(yīng)工業(yè)設(shè)備大數(shù)據(jù)環(huán)境下的業(yè)務(wù)需求，實現(xiàn)平臺計算、存儲資源的按需分配，在接入多個不同部件或設(shè)備的實時狀態(tài)監(jiān)測系統(tǒng)時，云平臺應(yīng)具備以下功能：1）平臺上的微服務(wù)程序和消息中間件實現(xiàn)容器化，使其能統(tǒng)一進行全生命周期的維護管理，支持平臺的調(diào)配；2）平臺以1 套統(tǒng)一且便捷的流程部署對應(yīng)監(jiān)測部件的微服務(wù)程序，使云平臺在硬件資源充分的情況下可以擴展或引入更多監(jiān)測程序；3）平臺可以監(jiān)測業(yè)務(wù)程序?qū)Y源的使用狀況，給出運維人員進行分析決策、調(diào)整資源的分配策略；4）平臺具備高可用性和程序故障處理能力；5）平臺可擴展與邊緣設(shè)備協(xié)同處理業(yè)務(wù)的能力，提高業(yè)務(wù)的時效性和安全性。

1.2 平臺整體架構(gòu)

如圖2 所示，根據(jù)工作屬性的不同可將設(shè)備監(jiān)測系統(tǒng)云平臺的整體架構(gòu)分為容器管理層、平臺監(jiān)控層、數(shù)據(jù)處理層、邊緣層等4 個層次。

圖2 平臺各層次作用示意圖

1）容器管理層 該層主要由容器編排工具及運維人員編寫的系統(tǒng)任務(wù)組成，體現(xiàn)平臺的核心功能。通過開發(fā)人員編寫的配置文件或提交的指令，基于鏡像倉庫中存儲的程序鏡像，對監(jiān)測系統(tǒng)各微服務(wù)容器進行快速創(chuàng)建或銷毀，以及對平臺的消息中間件進行擴縮容，進而實現(xiàn)平臺計算資源的按需分配。同時，容器的故障發(fā)現(xiàn)與恢復(fù)、服務(wù)發(fā)現(xiàn)、負載均衡、安全防護、滾動更新、版本回退等功能都在該層實現(xiàn)，維持監(jiān)測服務(wù)的持續(xù)穩(wěn)定運行。

2）平臺監(jiān)測層 該層對云服務(wù)器的計算資源及運行于云服務(wù)器上的容器進行狀態(tài)監(jiān)測，并呈現(xiàn)可視化界面，可直觀地顯示整個云平臺的運轉(zhuǎn)狀況，同時資源分配的信息可保存于日志文件中。該層可為運維者或開發(fā)者提供一個參考方向，使其能夠完善計算資源的分配策略，制定相關(guān)的容器控制代碼，或是考慮對平臺的硬件資源進行提升。另外，對平臺的可視化管理一般集成在可視化監(jiān)控頁面，故亦歸于該層中。

3）數(shù)據(jù)處理層 該層由監(jiān)測系統(tǒng)執(zhí)行程序、平臺提供的消息中間件的實例以及數(shù)據(jù)庫等組成，可繼續(xù)細分為數(shù)據(jù)輸入處理、數(shù)據(jù)業(yè)務(wù)處理和數(shù)據(jù)持久化等3 方面。設(shè)備監(jiān)測的數(shù)據(jù)經(jīng)過這一層處理后，最終展示在可視化頁面給用戶查看。

4）邊緣層 該層由傳感器、嵌入式微處理單元、網(wǎng)絡(luò)傳輸模塊等組成，可實現(xiàn)數(shù)據(jù)采集、數(shù)據(jù)預(yù)處理、本地緩存、聯(lián)網(wǎng)上傳等功能。在該架構(gòu)下，邊緣層可擴展出與云平臺協(xié)同處理數(shù)據(jù)的能力。

2 基礎(chǔ)技術(shù)

2.1 微服務(wù)程序

各監(jiān)測系統(tǒng)的軟件端以SpringBoot ＋SpringMVC＋Mybatis 集成的框架技術(shù)為主體進行開發(fā)，使用高效的敏捷開發(fā)模式[3]。其執(zhí)行程序可打包成多個微服務(wù)程序，其中微服務(wù)的概念是將一個系統(tǒng)按業(yè)務(wù)劃分成多個子程序，每個子程序都是完整且可獨立運行的。子程序間的交互可通過HTTP 協(xié)議進行通信（也可采用消息隊列來間接通信，如RoocketMQ、Kafaka 等），這種子程序即本文所述微服務(wù)程序。

微服務(wù)架構(gòu)的概念區(qū)別于傳統(tǒng)的整體式架構(gòu)。在整體式架構(gòu)中，所有進程緊密耦合作為單項服務(wù)運行，這意味著如果應(yīng)用程序的一個進程遇到需求峰值則必須擴展整個架構(gòu)的載體。隨著代碼庫的增長，添加或改進整體的功能變得更加復(fù)雜，也使未來添加或擴展新的功能變得更困難。同時，相互緊密耦合的進程會擴大單個進程故障的風(fēng)險。使用微服務(wù)架構(gòu)，針對業(yè)務(wù)各部分（本文中為監(jiān)測個體或監(jiān)測個體的組成部分）開發(fā)的應(yīng)用程序作為獨立組件，應(yīng)用程序根據(jù)不同功能可繼續(xù)拆分。所有輕量級的程序通過明確定義的接口進行通信，并合作完成業(yè)務(wù)功能。由于各業(yè)務(wù)為獨立運行，故可輕松實現(xiàn)各項服務(wù)的更新、部署和擴展。

2.2 消息組件

云平臺提供MQTT 服務(wù)器程序，用于接收采集端傳遞的數(shù)據(jù)，同時配有分布式數(shù)據(jù)處理軟件、消息中間件（如Flink、Kafka、Redis 等），可承擔(dān)起數(shù)據(jù)在微服務(wù)之間通訊中轉(zhuǎn)、解析、緩存消峰等功能。數(shù)據(jù)庫使用MySQL 與Hadoop 搭配，依據(jù)數(shù)據(jù)的特點提供不同類型的持久化功能。

1）Flink 是一款分布式的計算引擎，既可作數(shù)據(jù)的批處理（即處理靜態(tài)的數(shù)據(jù)集、歷史的數(shù)據(jù)集），也可作數(shù)據(jù)的流處理（即處理一些實時數(shù)據(jù)流），實時地產(chǎn)生數(shù)據(jù)的結(jié)果。

2）Kafka 是一種高吞吐量的分布式發(fā)布/訂閱消息系統(tǒng)，其通過O(I)的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對于即使數(shù)以TB 的消息存儲也能保持長時間的穩(wěn)定性能。

3）Redis 是一款開源的基于內(nèi)存的鍵值對存儲系統(tǒng)，主要被用作高性能緩存服務(wù)器使用。Redis 獨特的鍵值對模型使之支持豐富的數(shù)據(jù)結(jié)構(gòu)類型，即其值可以是字符串、哈希、列表、集合、有序集合。同時，由于Redis 是基于內(nèi)存進行工作，免去了磁盤I、O 速度的影響，故其讀寫性能極高。

2.3 容器化與K8s

程序容器化是指將程序代碼、運行所需的環(huán)境、配置文件等打包形成一個可交付的鏡像文件，該鏡像可在需要時生成運行實例，而這個運行實例即被稱作容器。容器之間相互隔離，相比使用虛擬機，其優(yōu)勢在于能夠共用宿主機內(nèi)核，占用資源小，啟動快；而其可靈活部署、按需伸縮的特點適配微服務(wù)程序，故容器是微服務(wù)的優(yōu)秀載體。

K8s 是用于自動化部署、擴展和管理容器化應(yīng)用程序的開源系統(tǒng)。其能在1 組異構(gòu)服務(wù)器上管理、編排多個容器實例組合而成的應(yīng)用，并提供完善的管理工具，涵蓋開發(fā)、部署測試、運維監(jiān)控在內(nèi)的各個環(huán)節(jié)[4]。在構(gòu)建和管理容器云時，目前2 種主流的工具分別是Spring Cloud 和K8s。Spring Cloud 重點關(guān)注微服務(wù)架構(gòu)的實現(xiàn)，且僅能使用Java 語言環(huán)境進行應(yīng)用程序的開發(fā)；而K8s 重點關(guān)注容器編排技術(shù)，其設(shè)計目標就是支持通用的大規(guī)模容器集群，且支持多種語言開發(fā)的應(yīng)用。在部署和管理容器化應(yīng)用時，使用K8s 的集群通用性更強大，組件的生態(tài)圈更豐富，故本文所述監(jiān)測云平臺使用K8s 作為主體進行開發(fā)。

3 平臺搭建

設(shè)備監(jiān)測云平臺整體架構(gòu)圍繞容器＋K8s 進行構(gòu)建。容器技術(shù)將應(yīng)用程序封裝到容器中，K8s 進行容器編排，實現(xiàn)容器的自動化部署、集群管理及應(yīng)用容器化管理。相比傳統(tǒng)B/S 架構(gòu)下的服務(wù)器，這種模式的云平臺可提供DevOps 集成能力、持續(xù)發(fā)布策略以及擴縮容、服務(wù)治理等能力，讓開發(fā)者更專注于業(yè)務(wù)邏輯的開發(fā)，充分利用容器云平臺的能力，通過自動化縮短業(yè)務(wù)迭代上線周期、優(yōu)化資源利用率、提高服務(wù)響應(yīng)效率[5，6]。

3.1 K8s 集群搭建

本文所述云平臺搭建2 主2 從的具備高可用性的K8s 服務(wù)器集群，所有設(shè)備監(jiān)測服務(wù)的數(shù)據(jù)處理都在集群內(nèi)部實現(xiàn)。K8s 集群可由Kubeadm 工具進行快速搭建，其中2 臺主節(jié)點需要額外配置Nginx，搭配Keepalived實現(xiàn)高可用性，并使集群可以通過虛擬IP 訪問，增加安全性。在搭建完成后，選擇專門的容器網(wǎng)絡(luò)插件（如Flannel）使Pod（在K8s 中是最基本的調(diào)度單元，為1 個或1 組容器的集合）之間可以相互訪問，Pod 和Service 等其他模塊也能相互訪問，實現(xiàn)K8s 集群內(nèi)部的扁平化網(wǎng)絡(luò)。操作者與集群的通信通過Kubectl 命令行工具實現(xiàn)。尤其是對K8s 集群的自動擴縮容策略、Pod 創(chuàng)建、公共資源的使用限制等相關(guān)功能進行配置，可通過編寫Yaml 文件，用Kubectl 命令行上傳并應(yīng)用即可。

然后，安裝Ingress Controller，其功能是對外部訪問集群的流量進行路由轉(zhuǎn)發(fā)。再用配置文件定義Ingress資源，確定流量路由規(guī)則與TLS 設(shè)置等信息，使數(shù)據(jù)能通過URL 訪問到集群內(nèi)部的Service，進而訪問到指定的容器。需要說明的是，K8s 生態(tài)系統(tǒng)中有許多不同的Ingress 控制器可供選擇，其中基于Nginx 的控制器提供了最廣泛的配置項，是較主流的選擇，故本文所述集群采用該控制器。

配置Harbor 作為平臺私有的鏡像倉庫，制作的鏡像都存儲在該倉庫中，即相當(dāng)于存儲在平臺就近的服務(wù)器或可以專線連接的服務(wù)器中，在任務(wù)需要創(chuàng)建容器或故障調(diào)節(jié)時速度大幅提升。同時，鏡像的升級、維護都可以由專門的操作人員負責(zé)，作到統(tǒng)一管理。

監(jiān)測層由K8s-Dashboard 和Prometheus 對K8s 集群的資源狀態(tài)進行監(jiān)控，兩者針對K8s 已有成熟的對接方案。其中，使用K8s-Dashboard 可通過一條調(diào)用配置文件的指令即可調(diào)用遠程鏡像部署在集群上，用于簡單顯示集群的狀態(tài)；而Prometheus 搭配Grafana 這一高效的監(jiān)控可視化模塊開發(fā)工具，能呈現(xiàn)多樣化的集群監(jiān)控視圖方案。通過頁面觀測集群狀態(tài)，可以及時靈活調(diào)整云平臺的資源配置方案。集群的整體架構(gòu)及各軟件的通訊關(guān)系如圖3 所示。

3.2 數(shù)據(jù)輸入處理

設(shè)備監(jiān)測云平臺搭建的目的是為了使設(shè)備監(jiān)測系統(tǒng)能夠快速上云，并使其開發(fā)流程變得簡便高效。因此，平臺內(nèi)部應(yīng)配置合理的消息中間件和數(shù)據(jù)庫，并對微服務(wù)程序聲明統(tǒng)一的接口。基于此，監(jiān)測數(shù)據(jù)進入到云平臺的K8s 集群內(nèi)部后的處理流程如圖4 所示。

圖4 數(shù)據(jù)輸入流程

MQTT 服務(wù)器負責(zé)接收各采集端傳輸?shù)臄?shù)據(jù)，由對應(yīng)監(jiān)測服務(wù)程序的訂閱者接收。若設(shè)備的所有狀態(tài)數(shù)據(jù)都具有結(jié)構(gòu)簡單、吞吐量小的特點，微服務(wù)程序可根據(jù)業(yè)務(wù)邏輯作數(shù)據(jù)解析，下一步即持久化進MySQL 數(shù)據(jù)庫。若設(shè)備的狀態(tài)數(shù)據(jù)是復(fù)雜異構(gòu)的，且吞吐量大（如電動機振動數(shù)據(jù)采樣頻率可達7 萬條/s，而溫度數(shù)據(jù)采樣頻率則只需1 條/s），則需要經(jīng)過訂閱者快速將數(shù)據(jù)放入消息隊列Kafka 中，以實現(xiàn)數(shù)據(jù)的緩沖、消除峰值，并作到異步處理。同時，流處理引擎Flink 時刻啟動著對應(yīng)程序的消費者任務(wù)，將Kafka 相應(yīng)主題中的狀態(tài)數(shù)據(jù)集（可能是一條條的Json 字符串），直接通過Iceberg 表格式，以字符串格式存儲在Hadoop 中。這種方式能最大限度保證傳輸效率和格式兼容，足以應(yīng)對多源異構(gòu)的大數(shù)據(jù)，保證數(shù)據(jù)的一致性。在數(shù)據(jù)量巨大的特殊時段，可以通過K8s 增加Flink 的工作槽，提高處理任務(wù)的并行度。

3.3 數(shù)據(jù)統(tǒng)計與可視化

根據(jù)數(shù)據(jù)輸入流程，數(shù)據(jù)以最高效率存儲在了關(guān)系型數(shù)據(jù)庫或分布式文件系統(tǒng)之中，還需進行統(tǒng)計處理或?qū)崟r展示在可視化頁面中供用戶查看，其處理流程如圖5 所示。

圖5 數(shù)據(jù)可視化流程

關(guān)系型數(shù)據(jù)庫中的監(jiān)測數(shù)據(jù)體量小，直接由Java微服務(wù)處理，可實時輸出到前端。Hadoop 中的數(shù)據(jù)體量較大，頻率較高，仍需啟動Flink 任務(wù)以流處理的形式進行解析。Flink 既可對大量數(shù)據(jù)或單條大體量數(shù)據(jù)以內(nèi)存級別的處理速度解析，也可使用窗口函數(shù)進行聚合統(tǒng)計，然后快速寫入緩沖數(shù)據(jù)庫Redis。由于Redis直接使用內(nèi)存進行數(shù)據(jù)的存儲，使得前端視圖層展示數(shù)據(jù)的時延盡可能低。同時，由于Redis 對數(shù)據(jù)只起到緩沖并中轉(zhuǎn)的功能，故一般可設(shè)置其淘汰策略為全量LRU（All Keys-Least Recently Used）的策略。

在定義Redis 存儲的數(shù)據(jù)結(jié)構(gòu)形式后，各監(jiān)測系統(tǒng)中負責(zé)可視化功能的微服務(wù)即可針對不同類型的展示數(shù)據(jù)，設(shè)置固定的前端模塊，對接Redis 中的數(shù)據(jù)。這樣增強了可視化端代碼的可復(fù)用性，節(jié)省開發(fā)成本。

4 應(yīng)用程序部署

以軌道打磨車的電動機監(jiān)測程序為例，展示圖6 所示云平臺的部署容器流程。首先，將電動機監(jiān)測系統(tǒng)的2 個Java 程序打包為可執(zhí)行Jar 包，一個負責(zé)消費MQTT 服務(wù)器上的數(shù)據(jù)傳入Kafka 消息隊列，另一個負責(zé)將緩存數(shù)據(jù)庫上的數(shù)據(jù)可視化展示至前端，將兩者上傳至云平臺主節(jié)點。然后，為相應(yīng)的微服務(wù)程序?qū)懸环軩ocker File 文件。在Docker 端執(zhí)行構(gòu)建指令后，文件中的一條條Linux 指令和參數(shù)按順序執(zhí)行，可將指定宿主機文件目錄下的微服務(wù)封裝成為鏡像，進而將其推送至私有鏡像倉庫。

圖6 平臺部署流程

最關(guān)鍵的一步是編寫Yaml 配置文件使微服務(wù)以定制化策略運行在云平臺上。在配置文件中，指定構(gòu)建Pod 用到的鏡像以及容器需要暴露的端口等，指定Service 對端口進行映射，使外部對宿主機相應(yīng)端口的訪問能夠轉(zhuǎn)發(fā)給容器。在此基礎(chǔ)上，根據(jù)業(yè)務(wù)特點編寫資源配置策略，包括但不限于有：定義Deployment 對該服務(wù)進行健康檢查和滾動更新，當(dāng)程序?qū)嵗霈F(xiàn)問題時K8s 可自動將其從服務(wù)中刪除，創(chuàng)建新的實例進行替換。定義HPA(Horizontal Pod Autoscaler）以配置自動縮放策略，使容器能根據(jù)業(yè)務(wù)運行時段的特點高效運行。在此案例下，電動機監(jiān)測程序的2 個微服務(wù)的最大不可用實例和最大搜索實例設(shè)置為1，自動縮放的最多實例設(shè)置為10，并根據(jù)監(jiān)聽的CPU 占用率及占用率的上限來調(diào)整應(yīng)用程序伸縮。K8s 的資源類型或是容器運行策略都是通過Yaml 文件中Kind 關(guān)鍵字聲明的，較常用的配置項名稱如表1 所示。

表1 配置文件常見項

以上配置文件可以寫在一份Yaml 文件中，也可以寫成多份Yaml 文件實現(xiàn)配置文件的復(fù)用，因為在實際工業(yè)環(huán)境下許多監(jiān)測應(yīng)用的健康檢查、擴容策略等都是相同的。配置文件可通過ConfigMap 存儲在K8s 中，與指定的Pod 進行綁定管理。

在完成以上步驟后，使用Kubectl 的Apply 命令即可讓K8s 將倉庫中的微服務(wù)鏡像制作成實例，運行在云平臺上。在命令成功執(zhí)行后，即可在管理界面Dashboard 看到容器實例的運行狀況。啟動采集端進行數(shù)據(jù)上傳，可在MQTT 服務(wù)器上看到有消費者鏈接，在Kafka 中創(chuàng)建消費者也能讀取到采集的數(shù)據(jù)，以此證明微服務(wù)容器正常運行。

5 結(jié)語

本文研究了一種針對起重運輸機械、工程機械或多設(shè)備監(jiān)測系統(tǒng)均適用的云平臺架構(gòu)方案，尤其適用于大量設(shè)備需要監(jiān)測的場景，實現(xiàn)了各部件或設(shè)備監(jiān)測程序的高效部署和管理，并可兼容多類型數(shù)據(jù)監(jiān)測的特點。根據(jù)設(shè)計方案，云平臺內(nèi)部使用容器化管理，搭建K8s集群，配套使用Nginx、Ingress、Harbor、Prometheus等工具進行平臺管理。在數(shù)據(jù)處理端，設(shè)計了使用消息中間件搭配微服務(wù)的模式，確定了部署Kafka、Flink、Redis 等中間件進行數(shù)據(jù)中轉(zhuǎn)、緩存處理，并使用MySQL、Hadoop 實現(xiàn)監(jiān)測數(shù)據(jù)的混合持久化。

基于K8s 開發(fā)的云平臺內(nèi)部的應(yīng)用管理、資源分配可進行直觀監(jiān)控和使用自動化策略。面對多源異構(gòu)、吞吐量大的數(shù)據(jù)監(jiān)測服務(wù)，該平臺能實現(xiàn)良好的適配，勝任多種監(jiān)測系統(tǒng)程序的部署。監(jiān)測系統(tǒng)程序可拆分為多個微服務(wù)分別上傳，只需定義好各自的數(shù)據(jù)接口即可部署應(yīng)用在平臺上，簡化了開發(fā)和部署流程。

由于K8s 云平臺符合云原生的架構(gòu)理念，可進一步實現(xiàn)功能擴展（如DevOps 環(huán)境、持續(xù)交付、自動化部署等），還可使用KubeEdge 擴充邊緣層的功能實現(xiàn)云邊協(xié)同作業(yè)，故云平臺具備良好的實用性和發(fā)展使用前景。