呂亞聰 ， 劉子辰 ，張玉成

（1.重慶郵電大學(xué)通信與信息工程學(xué)院，重慶 400065；2.移動計算與新型終端北京市重點實驗室（中國科學(xué)院計算

技術(shù)研究所），北京 100190）

0 引 言

我國是農(nóng)業(yè)大國，實現(xiàn)農(nóng)業(yè)現(xiàn)代化是我國的一項長期奮斗目標(biāo)[1]。農(nóng)機車輛是現(xiàn)代農(nóng)業(yè)的物質(zhì)基礎(chǔ)，農(nóng)機車輛的智能化對發(fā)展現(xiàn)代化農(nóng)業(yè)有極大的推動作用。近年來，伴隨著互聯(lián)網(wǎng)技術(shù)的持續(xù)發(fā)展，農(nóng)機車輛的智能化水平不斷提高。在此基礎(chǔ)上，引入針對智能農(nóng)機車輛的監(jiān)控系統(tǒng)建設(shè)將很大程度上提高農(nóng)機車輛的運行效率和管理水平。而傳統(tǒng)的企業(yè)級系統(tǒng)開發(fā)的典型架構(gòu)是單體式架構(gòu)，系統(tǒng)特點是所有代碼在一個項目中完成所有的工作，包括功能代碼模塊和非功能代碼模塊[2]。隨著物聯(lián)網(wǎng)、大數(shù)據(jù)技術(shù)的高速發(fā)展和業(yè)務(wù)應(yīng)用范圍的不斷擴展，不同的業(yè)務(wù)需要快速部署，相互之間需要不斷調(diào)用，業(yè)務(wù)擴展能力需要敏捷且高效，這都將給系統(tǒng)的開發(fā)和運維帶來了挑戰(zhàn)[3-5]。如果繼續(xù)沿用傳統(tǒng)的系統(tǒng)開發(fā)架構(gòu)，將無法滿足農(nóng)機監(jiān)控系統(tǒng)未來發(fā)展的需要。

微服務(wù)架構(gòu)的出現(xiàn)和在世界范圍內(nèi)的一些成功應(yīng)用，使其越來越受到人們的關(guān)注，成為開發(fā)者在搭建系統(tǒng)架構(gòu)時的新選擇。微服務(wù)架構(gòu)的主要特點是把單塊的應(yīng)用軟件系統(tǒng)按照面向服務(wù)化的原則拆分為一組具備一定功能的微小的服務(wù)應(yīng)用，通過與平臺無關(guān)的通信協(xié)議，完成不同服務(wù)彼此之間的互相調(diào)用與配合，從而實現(xiàn)復(fù)雜的系統(tǒng)整體功能[6]。相較于傳統(tǒng)的單體式系統(tǒng)架構(gòu)，微服務(wù)架構(gòu)系統(tǒng)模塊間耦合度較低，單個服務(wù)便于開發(fā)、調(diào)試與維護，且復(fù)雜度可控。此外，不同服務(wù)能夠獨立部署，按需獨立擴展[7]。

綜上所述，本文提出將微服務(wù)架構(gòu)應(yīng)用于智能農(nóng)機監(jiān)控系統(tǒng)的架構(gòu)設(shè)計，系統(tǒng)組件全部采用微服務(wù)化架構(gòu)，各個服務(wù)能夠做到服務(wù)自主注冊與發(fā)現(xiàn)，良好地降低了系統(tǒng)耦合度，實現(xiàn)了資源的充分利用。此外，它滿足了服務(wù)的快速部署、相互調(diào)用、業(yè)務(wù)按需擴展、并發(fā)響應(yīng)低時延等要求。

1 微服務(wù)體系介紹

微服務(wù)架構(gòu)是近年來出現(xiàn)的一種新的軟件架構(gòu)設(shè)計模式，具備穩(wěn)定性更好、擴展性更強、并發(fā)響應(yīng)更優(yōu)的特點[8]。它的實質(zhì)是將一個大型的、單體的、復(fù)雜的應(yīng)用系統(tǒng)，按照業(yè)務(wù)功能或者獨立性原則進行組件化、服務(wù)化分離，將其拆分成一系列微小的應(yīng)用服務(wù)。每個應(yīng)用服務(wù)依據(jù)其具體的業(yè)務(wù)功能進行邊界劃定，職責(zé)相對單一，同時能夠?qū)γ總€應(yīng)用服務(wù)做到獨立部署，服務(wù)間更加靈活和易于調(diào)配。每個應(yīng)用程序服務(wù)都在自己獨立的進程中運行，服務(wù)之間是松耦合的，使用輕量級通信機制（通常是基于HTTP協(xié)議的Restful API）相互通信，再加上消息隊列等技術(shù)實現(xiàn)進一步解耦，能夠方便地進行服務(wù)拆分和業(yè)務(wù)擴展[2,7]。在平臺無關(guān)的通信協(xié)議支持下，各個微服務(wù)可以依據(jù)團隊開發(fā)語言的掌握程度和具體業(yè)務(wù)的需要選擇最適合的技術(shù)方案，因此業(yè)務(wù)的開發(fā)、部署和擴展變得更加靈活[9]。

在微服務(wù)技術(shù)的發(fā)展演變過程中，逐漸形成了阿里巴巴的開源框架dubbo體系和以Spring框架為基礎(chǔ)的SpringCloud體系兩種不同的技術(shù)架構(gòu)體系[10]。與dubbo技術(shù)體系相比，SpringCloud技術(shù)體系具備更加完整的服務(wù)熔斷機制，服務(wù)設(shè)施組件化更加有利于業(yè)務(wù)的擴展與開發(fā)，服務(wù)間的交互性更強。因此，本文采用SpringCloud微服務(wù)架構(gòu)設(shè)計農(nóng)機監(jiān)控系統(tǒng)。

SpringCloud具有豐富的開箱即用的開發(fā)組件，是一系列框架與組件的集合。以SpringBoot開發(fā)框架為基礎(chǔ)實現(xiàn)快捷開發(fā)，它大幅簡化了微服務(wù)架構(gòu)應(yīng)用的基礎(chǔ)設(shè)施組件的開發(fā)工作，提供了一套易使用、易部署、易維護的開發(fā)工具。核心組件包括Eureka服務(wù)注冊發(fā)現(xiàn)中心、Spring Zuul API服務(wù)網(wǎng)關(guān)、Spring Config統(tǒng)一配置中心、Ribbon負載均衡、Hystrix服務(wù)容錯與熔斷等。應(yīng)用上述微服務(wù)基礎(chǔ)設(shè)施組件，結(jié)合SpringBoot可快速開發(fā)、部署，實現(xiàn)微服務(wù)架構(gòu)體系的應(yīng)用，技術(shù)架構(gòu)如圖1所示。

圖1 SpringCloud微服務(wù)技術(shù)架構(gòu)體系

（1）服務(wù)注冊與發(fā)現(xiàn)組件主要用于服務(wù)注冊，以實現(xiàn)多個服務(wù)間的發(fā)現(xiàn)與調(diào)用。

（2）網(wǎng)關(guān)組件主要用于提供動態(tài)路由、監(jiān)控、鑒權(quán)、調(diào)度、負載均衡等邊緣服務(wù)[11]。

（3）統(tǒng)一配置中心組件主要提供統(tǒng)一的、集中的、動態(tài)的配置管理。配置文件一般放在遠端Git倉庫中，服務(wù)通過Git倉庫的URL地址動態(tài)加載所需的配置文件。當(dāng)倉庫中的配置文件發(fā)生改變時，配合著SpringCloud Bus可以實現(xiàn)服務(wù)不需要重新啟動便能夠感知到配置的變化并應(yīng)用新的配置[12]。

（4）負載均衡組件是一種基于客戶端的負載均衡機制，主要是利用多種負載均衡策略，如隨機、輪詢、權(quán)重等，將請求分發(fā)到不同的服務(wù)器，提高網(wǎng)絡(luò)的吞吐量，增強網(wǎng)絡(luò)對數(shù)據(jù)的處理能力，提高網(wǎng)絡(luò)的可用性[13]。

（5）服務(wù)容錯組件主要用于通過熔斷機制控制服務(wù)，對延遲和異常提供基于熔斷策略的處理方式，保證系統(tǒng)中如果出現(xiàn)某些服務(wù)異常時系統(tǒng)能夠依然保證最低的可用度，而不會導(dǎo)致系統(tǒng)整體崩潰[14]。

當(dāng)服務(wù)處于被調(diào)用狀態(tài)或者客戶端發(fā)起訪問請求時，請求首先經(jīng)過Zuul API服務(wù)網(wǎng)關(guān)對其進行控制管理，根據(jù)所請求服務(wù)在注冊中心注冊的路由信息進行請求轉(zhuǎn)發(fā)；由負載均衡器Ribbon提供對請求負載的均衡分配服務(wù)；Eureka服務(wù)注冊與發(fā)現(xiàn)中心根據(jù)請求從已注冊的服務(wù)列表中尋找對應(yīng)的服務(wù)；由Spring Config統(tǒng)一配置中心對應(yīng)用服務(wù)所需要的相關(guān)配置項進行統(tǒng)一配置，實現(xiàn)配置與服務(wù)的解耦；當(dāng)服務(wù)出現(xiàn)異常時，由Hystrix熔斷器進行異常捕捉和熔斷等必要處理[15-16]。

2 系統(tǒng)總體架構(gòu)設(shè)計

智能農(nóng)機車輛監(jiān)控系統(tǒng)架構(gòu)設(shè)計以SpringCloud微服務(wù)技術(shù)架構(gòu)體系為基礎(chǔ)，對應(yīng)圖1中的服務(wù)部分，分別是數(shù)據(jù)采集微服務(wù)、數(shù)據(jù)處理微服務(wù)、應(yīng)用微服務(wù)、前端展示微服務(wù)和調(diào)度監(jiān)控微服務(wù)五大核心微服務(wù)。其中，應(yīng)用微服務(wù)又包括農(nóng)機車輛管理服務(wù)、農(nóng)機車輛定位監(jiān)控服務(wù)、用戶管理服務(wù)、農(nóng)機運行軌跡監(jiān)控服務(wù)、農(nóng)機計畝統(tǒng)計服務(wù)、農(nóng)機運行狀態(tài)監(jiān)控服務(wù)、農(nóng)機維修保養(yǎng)記錄服務(wù)、日志查詢服務(wù)和故障報警服務(wù)等。

相較于傳統(tǒng)單體式應(yīng)用系統(tǒng)，目的在于實現(xiàn)智能農(nóng)機監(jiān)控系統(tǒng)業(yè)務(wù)模塊的服務(wù)化，將復(fù)雜應(yīng)用按照業(yè)務(wù)功能邊界拆分成若干獨立運行的單個服務(wù)，降低服務(wù)之間的耦合度，從而達到快速開發(fā)和部署的要求，并對通用配置項進行統(tǒng)一管理，降低系統(tǒng)開發(fā)和維護成本，以便進行系統(tǒng)整體的擴展和調(diào)試[17-18]。

2.1 技術(shù)架構(gòu)設(shè)計

基于微服務(wù)架構(gòu)模式強調(diào)分散和獨立可運行的松耦合設(shè)計思想，在進行微服務(wù)設(shè)計時，本系統(tǒng)架構(gòu)采用微服務(wù)應(yīng)用集群和微服務(wù)基礎(chǔ)設(shè)施相結(jié)合的處理方式，技術(shù)架構(gòu)如圖2所示。

通過觀察架構(gòu)圖能夠看到，系統(tǒng)中每個服務(wù)的功能和數(shù)據(jù)獨立于其他服務(wù)，不同服務(wù)之間借助統(tǒng)一的JSON格式的API進行通信，保證了服務(wù)間的解耦，同時單獨服務(wù)的職責(zé)相對單一，便于快速開發(fā)、部署和擴展。

2.2 系統(tǒng)模塊設(shè)計

系統(tǒng)主要微服務(wù)群組包括以下內(nèi)容。

（1）數(shù)據(jù)采集微服務(wù)群組由若干采集解析微服務(wù)組成的分布式微服務(wù)群組，采用Netty NIO技術(shù)和多線程技術(shù)，負責(zé)與農(nóng)機車輛上裝載的DRC終端模塊通信，包括數(shù)據(jù)采集、協(xié)議解析、數(shù)據(jù)校驗、數(shù)據(jù)加密/解密、數(shù)據(jù)上報等功能，提供Restful服務(wù)接口供其他微服務(wù)調(diào)用。

（2）數(shù)據(jù)處理微服務(wù)群組包含數(shù)據(jù)存儲服務(wù)、數(shù)據(jù)分析服務(wù)和數(shù)據(jù)緩存服務(wù)。數(shù)據(jù)存儲服務(wù)使用MySQL關(guān)系型數(shù)據(jù)庫，同時使用Redis非關(guān)系型數(shù)據(jù)庫存儲一些由數(shù)據(jù)采集服務(wù)上報的實時數(shù)據(jù)，提供給其他微服務(wù)作調(diào)用。數(shù)據(jù)分析服務(wù)提供對系統(tǒng)中的農(nóng)機車輛定位數(shù)據(jù)、發(fā)動機扭矩百分比、冷卻液溫度、燃油率、轉(zhuǎn)速等運行數(shù)據(jù)的分析功能，提供前端展示服務(wù)所需要的數(shù)據(jù)源。數(shù)據(jù)緩存服務(wù)解決對系統(tǒng)中高并發(fā)大數(shù)據(jù)場景下熱點數(shù)據(jù)的訪問性能問題，將熱點數(shù)據(jù)、靜態(tài)資源等作緩存處理，以提供高性能的數(shù)據(jù)快速訪問。

（3）展示微服務(wù)群組主要針對面向用戶的圖形展示畫界面，提供手機APP端和PC Web瀏覽器端兩種訪問渠道的支持。其中，手機APP端分為iOS和Android兩種系統(tǒng)版本，用于向農(nóng)機車輛終端個人用戶提供農(nóng)機信息的相關(guān)操作；PC Web瀏覽器端主要作為農(nóng)機廠商、經(jīng)銷商或其他組織機構(gòu)的后臺管理平臺，主要用于查看農(nóng)機車輛信息、車主信息、監(jiān)測所屬的農(nóng)機車輛運行狀況，以及配置農(nóng)機相關(guān)參數(shù)等。該微服務(wù)僅提供向用戶作前端數(shù)據(jù)展示的頁面，數(shù)據(jù)源由數(shù)據(jù)微服務(wù)提供。

（4）業(yè)務(wù)應(yīng)用微服務(wù)群組為該系統(tǒng)業(yè)務(wù)應(yīng)用功能實現(xiàn)的核心部分，由Web應(yīng)用接口服務(wù)、APP接口服務(wù)、農(nóng)機車輛信息管理服務(wù)、農(nóng)機定位查詢服務(wù)、農(nóng)機發(fā)動機實時監(jiān)控服務(wù)、農(nóng)機行駛軌跡服務(wù)、農(nóng)機維修記錄服務(wù)和農(nóng)機故障服務(wù)等微服務(wù)組成。智能農(nóng)機車輛監(jiān)控系統(tǒng)中，大部分的業(yè)務(wù)功能與其他群組中的微服務(wù)通過Restful通信協(xié)議實現(xiàn)數(shù)據(jù)交互。

圖2 農(nóng)機監(jiān)控系統(tǒng)技術(shù)架構(gòu)設(shè)計

2.3 業(yè)務(wù)應(yīng)用模塊設(shè)計

智能農(nóng)機監(jiān)控系統(tǒng)主要實現(xiàn)以下目的：

（1）農(nóng)機車輛地理位置的監(jiān)控和顯示，便于統(tǒng)計農(nóng)機分布趨勢，調(diào)配農(nóng)機資源；

（2）農(nóng)機車輛運行軌跡的監(jiān)控和查詢，提高農(nóng)機運行的準(zhǔn)確性；

（3）農(nóng)機發(fā)動機運行監(jiān)控，實時監(jiān)控發(fā)動機運行各項指標(biāo)，及時掌握農(nóng)機車輛健康狀況，以便及時發(fā)現(xiàn)農(nóng)機運行故障并上報提醒；

（4）農(nóng)機計畝統(tǒng)計，用于計算收割機收割的耕地面積；

（5）建立信息完整的農(nóng)機車輛與用戶資料，便于掌握農(nóng)機的售出情況、用戶群分布等信息，支持廠商科學(xué)管理決策。

業(yè)務(wù)應(yīng)用微服務(wù)群組作為智能農(nóng)機監(jiān)控系統(tǒng)中的核心服務(wù)，應(yīng)該建立統(tǒng)一的信息標(biāo)準(zhǔn)化處理方式，建立統(tǒng)一的信息流轉(zhuǎn)機制，以滿足上下級之間、同級之間數(shù)據(jù)信息流轉(zhuǎn)的需求，功能架構(gòu)劃分如圖3所示。

圖3 業(yè)務(wù)應(yīng)用模塊設(shè)計

核心功能模塊說明：

（1）農(nóng)機車輛管理模塊主要負責(zé)各種農(nóng)機車輛的編號、型號、機型、歸屬等與農(nóng)機有關(guān)的信息統(tǒng)計和管理。

（2）農(nóng)機發(fā)動機實時監(jiān)控模塊主要對采集上報的各類農(nóng)機發(fā)動機運行數(shù)據(jù)進行統(tǒng)計和分析，如發(fā)動機燃油率、冷卻液溫度、轉(zhuǎn)速、油壓等，且可以通過對農(nóng)機車輛發(fā)送控制指令對農(nóng)機進行相關(guān)操作。

（3）農(nóng)機位置監(jiān)控模塊主要負責(zé)實時匯報農(nóng)機當(dāng)前的地理位置坐標(biāo)、位置信息等，以供數(shù)據(jù)統(tǒng)計服務(wù)等其他服務(wù)調(diào)用。

（4）故障報警模塊負責(zé)實時監(jiān)控農(nóng)機車輛各項運行指標(biāo)有無故障報警，如有故障，及時上報故障報警信息。

（5）計畝統(tǒng)計模塊負責(zé)統(tǒng)計一段時間內(nèi)農(nóng)機耕作或者收割的輪廓面積，用于統(tǒng)計每臺農(nóng)機車輛的收獲成果。

3 部署與測試

系統(tǒng)拆分成微服務(wù)架構(gòu)后，服務(wù)的數(shù)量增多，不再是以往的單個服務(wù)。無論是采用單個部署還是集群部署，不僅效率低下，且部署維護和硬件成本高，不能達到服務(wù)高可用和高容錯的要求。容器化技術(shù)能夠很好地解決系統(tǒng)微服務(wù)化后帶來的服務(wù)部署問題，簡化部署的流程，充分利用硬件資源，提高系統(tǒng)部署的效率[19]。Docker容器是目前使用較廣泛的開源容器引擎，使用它可以將項目快速打包構(gòu)建成系統(tǒng)鏡像，且可以上傳到鏡像倉庫，使得項目啟動部署更加快速便捷。因此，本系統(tǒng)即所有微服務(wù)通過Docker容器部署在阿里云服務(wù)器上。

3.1 項目結(jié)構(gòu)

根據(jù)系統(tǒng)設(shè)計，本系統(tǒng)采用SpringBoot構(gòu)建每個微服務(wù)。每個微服務(wù)作為一個子模塊存在于父項目。父項目采用POM打包方式，所有依賴版本信息在父項目中規(guī)定。項目結(jié)構(gòu)如圖4所示。

3.2 構(gòu)建Docker鏡像與項目啟動

3.2.1 Dockerfile

項目編寫完成需要打包成Docker鏡像，才可以在Docker中運行。打包鏡像需要在項目中添加Dokerfile作為構(gòu)建鏡像的指令腳本，如下：

FROM openjdk∶8-jdk-alpine

VOLUME/tmp

ARG JAR_FILE

COPY ${JAR_FILE} app.jar

ENTRYPOINT [“java”,”-jar”,”/app.jar”]

圖4 項目結(jié)構(gòu)

3.2 .2 Maven插件

在需要構(gòu)建鏡像的項目pom.xml中添加對應(yīng)的maven-docker插件依賴：

（1）添加屬性配置，規(guī)定docker鏡像的前 綴名

3.2.3 構(gòu)建Docker鏡像

在服務(wù)器中使用命令mvn install dockerfile∶build， 就可以對項目進行鏡像構(gòu)建。構(gòu)建成功會有如圖5鏡像構(gòu)建示例所示。

將所有的項目進行鏡像構(gòu)建后，用命令docker images查看鏡像列表，部分鏡像列表如圖6所示。

之后可以用docker run在服務(wù)器上啟動服務(wù)。啟動服務(wù)需要指定對應(yīng)的端口，如eureka服務(wù)啟動在8761端口：

docker run-d-p 8761∶8761 imageId;

按照上述過程依次啟動每個微服務(wù)，可以使用docker ps查看所有服務(wù)的啟動情況。

3.3 測試結(jié)果

本系統(tǒng)使用阿里云服務(wù)器部署，服務(wù)器為2CPU 8 GB內(nèi)存配置，服務(wù)器上已部署cenos7、docker、redis、rabbitmq、maven、jdk等基礎(chǔ)環(huán)境，部分微服務(wù)實例如圖7所示。系統(tǒng)部分測試用例和測試結(jié)果如表1所示。

圖5 鏡像構(gòu)建示例

圖 6 docker容器中部分鏡像

圖7 Eureka中部分微服務(wù)實例

測試結(jié)果驗證了系統(tǒng)微服務(wù)化后服務(wù)間發(fā)現(xiàn)與注冊機制、系統(tǒng)的響應(yīng)速度較快、位置監(jiān)控這類需要多個微服務(wù)配合的訪問需求，系統(tǒng)的響應(yīng)速度有所降低，但平均鏈路響應(yīng)時間控制在300 ms以內(nèi)，滿足系統(tǒng)的響應(yīng)時間需求。模擬測試部分服務(wù)異常不可用后服務(wù)的熔斷機制，服務(wù)可以捕獲異常且及時采取熔斷回滾機制，返回對應(yīng)熔斷降級的處理措施，熔斷降級響應(yīng)時間在1 s以內(nèi)，保證了系統(tǒng)整體的可用性和良好的用戶體驗。

表1 系統(tǒng)功能測試

4 結(jié) 語

本文對目前主流的微服務(wù)架構(gòu)進行介紹，分析了微服務(wù)架構(gòu)的優(yōu)勢，闡述了智能農(nóng)機監(jiān)控系統(tǒng)微服務(wù)實現(xiàn)時的需求要素，并針對其特點設(shè)計了微服務(wù)實現(xiàn)的總體架構(gòu)、技術(shù)實現(xiàn)架構(gòu)，重點論述了業(yè)務(wù)應(yīng)用模塊的設(shè)計劃分?；谠撐⒎?wù)架構(gòu)進行智能農(nóng)機監(jiān)控系統(tǒng)開發(fā)，能夠快速建立一個高內(nèi)聚、低耦合的智能農(nóng)機車輛監(jiān)控系統(tǒng)，提高了系統(tǒng)的擴展和響應(yīng)能力，具有較高的應(yīng)用價值。