基于微服務架構的分布式測距系統的研究與設計

向彬彬 馬明星 童茂林 彭 瑾 蘇文秀 高秀敏

(杭州電子科技大學電子信息學院 浙江 杭州 310018)

0 引 言

近年來，隨著科學技術的不斷進步，諸多領域都取得了飛速發展。在距離測量方面，國內外也先后出現了紅外線測距[1]、微波測距[2]、超聲波測距[3]與激光測距[4]等技術。而隨著這些理論的不斷發展，適用于各種環境的測距系統也相繼出現。其中，激光測距技術由于激光高亮度、單色性和相干性好、方向性強的特點而被廣泛應用于衛星[5]、雷達[6]、汽車防撞[7]、移動機器人[8]等高精度的測距系統中。雖然測距系統在許多應用中都取得了飛速發展，測距技術也呈現出多樣化，但傳統的測距系統依然受到了測量范圍、擴展性等方面的限制。

基于微服務架構的分布式測距系統首先利用無限WIFI通信原理與Ad Hoc網絡技術[9]，實現了可以自組網的測距傳感網絡，使得系統很好地克服了測量范圍的限制。然后利用Hadoop對海量測量數據進行分析與處理，并利用負載均衡原理[10]實現了測量網絡與數據分析模塊的流量控制，平衡了網絡負載，提高了系統的計算能力。最后，根據微服務架構原理[11]將系統根據功能的不同拆分為獨立的服務，在實現了根據功能對系統進行橫向擴展的同時也簡化了服務的開發與維護。

1 系統架構

基于微服務架構的分布式測距系統作為分布式的測距傳感系統，通過對待測系統添加多個測距探針采集數據，然后通過數據分析模塊對采集的數據進行分析，最后將分析結果通過前端展示。系統架構如圖1所示。

圖1 系統架構

該系統底層是由多個測距探針組成的測距系統。測距探針是一個包含測距傳感器模塊、通信模塊與控制模塊的嵌入式系統，主要通過測距傳感器采集數據，并使用控制模塊對數據進行預處理，然后利用WIFI通信模塊將數據發送到數據分析模塊進行具體任務處理與持久化操作。

該系統底層所有測距探針采集到的數據首先都會發送到數據分析模塊進行處理和數據持久化操作。數據分析模塊主要使用Hadoop大數據進行數據處理，使用HBase和HDFS(Hadoop分布式文件系統)進行數據持久化。數據分析模塊可以有一個或多個，如果使用多個則需要使用負載均衡器選取最優的數據分析模塊進行數據處理。

該系統基于微服務架構將應用拆分為不同的服務，這些服務主要包括：基礎服務，為系統提供基本操作，包括用戶管理、日志服務等；任務分發服務，結合具體測距項目將數據處理封裝為一個或多個子任務，并將這些子任務分發到對應的數據分析模塊中進行數據處理；項目管理服務，可以獲取項目的拓撲結構，也可以對每一個單獨的探針進行創建、刪除、修改等管理操作；設備監控服務，對探針進行全面的監控，包括提供探針心跳檢測和溫濕度監控等功能。另外，系統根據微服務架構原理在服務層實現了服務自發現與服務注冊等功能。

該系統最上層為顯示層，用戶可以利用瀏覽器或手機客戶端通過域名訪問和使用測距系統平臺。Web Portal顯示層使用Spring框架通過調用REST API接口實現顯示層的功能[12]。顯示層并非直接調用服務層各服務API，而是統一通過API網關進行身份認證，然后利用API網關將請求轉發到對應的服務中進行處理。

2 測距探針的設計

2.1 測距探針結構

測距探針是該分布式測距系統的數據采集核心組件，該模塊實現了數據采集、數據預處理、WIFI通信與心跳檢測等功能。圖2顯示了測距探針的內部結構。

圖2 測距探針內部結構

測距探針的主體結構由一個STM32控制系統、數據采集模塊和WIFI通信模塊組成。其中，數據采集模塊主要用于采集測距數據。在一個測距系統中可能使用不同類型的傳感器，如激光傳感器、紅外傳感器、超聲波傳感器等，為了控制系統更好地適配各類型傳感器，需要添加轉換電路將不同傳感器的信號轉換為統一的模擬電壓信號量傳入STM32內部ADC轉換器中處理。基于STM32的控制系統則主要用于將采集到的數據進行預處理，轉化為Json格式，并通過WIFI通信模塊將數據發送到數據分析模塊進行進一步分析、處理和存儲。

2.2 測距傳感網絡

該系統主要針對大規模測距系統應用而設計，因此需要使用大量測距探針組成測距傳感網絡。該系統使用AODV實現Ad Hoc自組網。AODV協議[13]是一種基于DSDV(目的節點序列距離矢量協議)的按需路由協議。在AODV協議中，當節點收到一個路由請求分組后，該節點可以反向學習到請求發送節點的路由信息。最終，目的節點收到路由請求分組后，可以根據學習到的路由回復路由請求。這樣，源節點和目的節點之間便建立了一條全雙工路徑。

在AODV協議的實現中，路由查找算法是傳感網絡實現的核心，該系統中路由查找算法的實現流程如圖3所示。在進行路由查找時，首先需要確定路由表中是否包含到該節點的路由，如果有且路由可用，則釋放空間直接結束處理。然后判斷是否到達RREQ路由請求報文發送時間，發送RREQ，如果沒到則直接結束處理。在查找過程中，如果查詢該節點的次數用盡，則說明沒有找到可以到達該節點的路由，此時刪除緩存中發送到該節點的數據包，然后結束處理。如果是第一次發送RREQ路由請求報文，則設置相應的初始值，如果不是第一次發送，便擴大轉發范圍，然后組裝數據包轉發到下一個節點。

圖3 路由算法流程圖

3 數據分析模塊的設計

3.1 分布式數據分析與存儲的實現

Hadoop是一個開源的分布式計算架構，它實現了一個高容錯性的分布式文件系統HDFS和一套海量數據計算框架MapReduce，另外還衍生了整套基于Hadoop的分布式計算生態圈[14]。該系統便是使用Hadoop實現對海量測距探針檢測數據的分析處理和持久化存儲。

測距探針采集到的數據通過WIFI通信模塊發送到Hadoop HDFS文件系統中創建臨時文件保存。然后，系統通過調用定時任務定時對臨時文件中的數據進行MapReduce任務處理，過濾異常數據和錯誤數據；進而將處理后的數據保存到HBase數據庫中。服務層的任務分發服務發送任務請求到數據分析模塊時，數據分析模塊根據請求內容調用指定的MapReduce任務分析和處理數據。另外，用戶還可以通過任務分發服務自定義MapReduce任務處理自定義分析過程。數據分析模塊的處理過程如圖4所示。

圖4 數據分析模塊處理過程

3.2 負載均衡的實現

在實際應用中，測距系統一般使用大量測距探針協同工作，為了更加準確快速地分析和處理海量測量數據，系統采用集群部署模式部署Hadoop數據分析模塊，因此一個高效的負載均衡器是必不可少的。

該系統的負載均衡器主要對數據分析模塊接收測距探針數據和接收任務分發服務的任務處理請求選擇最優節點。圖5描述了該系統負載均衡的均衡策略。測距探針和任務分發的處理請求首先都暫存到阻塞隊列中等待策略模塊過濾轉發。對于測距探針的數據接收請求，負載均衡器主要利用項目ID、區域和網絡流量等對數據分析模塊進行過濾選擇；而對于任務分發服務的數據處理請求，負載均衡器主要利用項目ID、任務數以及CPU利用率等進行過濾選擇。當選擇到最優的數據分析節點則將請求發送到對應的節點進行處理，而如果有多個符合條件的節點，則負載均衡器將隨機選擇其中一個轉發處理請求。

圖5 負載均衡策略圖

4 服務層的設計

4.1 服務層結構

該系統基于微服務架構將系統各功能拆分為獨立的服務。拆分出來的服務通過RPC(遠程過程調用)實現相互通信，為前端提供業務服務。服務層的具體結構如圖6所示。

圖6 服務層結構

服務層底層包含基礎服務和任務分發服務，其中基礎服務提供面向系統的基礎性服務，如用戶管理、授權管理、日志管理等；任務分發服務主要用于將項目和設備管理中的業務轉換為計算任務發送到數據分析模塊。服務層上層主要包含項目管理服務和設備監控服務，其中項目管理服務針對具體的項目提供管理服務，可以提供項目的詳細拓撲，還可以對測距探針進行增、刪、改、查等管理操作。另外，服務層還包含一個服務注冊中心，用于管理所有服務和監控服務健康狀況。各服務之間的交互通過RPC實現，如各服務模塊記錄操作日志都需要調用RPC的cast()方法發送消息到RabbitMQ消息隊列[15]中，對應的基礎服務日志管理模塊則監聽消費名為operation-log的隊列中的消息。

4.2 服務發現

該系統采用服務端發現方式實現服務自發現，客戶端通過API網關轉發請求到具體的服務處理請求。因此，該系統在服務層實現了一個服務注冊中心管理各個服務的注冊信息。

該系統利用將所有服務的IP和端口號以key-value(鍵值對)形式保存到etcd中；服務注冊中心則提供兩類API管理etcd中的配置信息。一類API為管理服務API，主要實現服務的注冊和注銷功能；另一類API為查詢服務API，API網關通過該API查詢相關服務的IP和端口號。

4.3 服務注冊

每個服務在啟動時都需要主動將服務注冊到服務注冊中心中。完成服務注冊首先需要在該服務中添加一個配置文件service-sdk.conf，該配置文件配置了服務相關信息。

ranging.service.sdk {

service:{

name:″task-allocation″,

description:″Task Allocation Service″,

module:″Task-Allocation″,

platform:″Ranging System″,

endpoint:{

target:″ranging/taskallocation″,

apis:[{

version:″1.0″,

state:″STABLE″

}]

}

}

}

上述配置文件描述了任務分發服務的配置信息。其中，service中配置了服務的所有配置：name表示服務的名稱，description表示服務的描述，module則用來在平臺范圍內唯一標識服務，platform表示平臺名；endpoint描述了該服務的endpoint信息，其中包含target表示服務API的基礎注冊點，apis則表示了所有API服務，每一個API對象都定義了API的版本狀態state以及API版本version。每個服務在完成注冊的同時也需要將對應的endpoint信息注入API網關中，這樣Web Portal層在訪問時便可以通過endpoint找到對應的服務。

添加配置文件之后，則需要為服務添加一個注冊方法register()來完成服務注冊。該方法接收一個InputService類型的參數，InputService類封裝了配置文件中服務的配置信息。register()方法調用服務注冊中心的管理API將服務的配置信息主動發送到服務注冊中心中注冊服務。

5 API網關的設計

該系統中，API網關有兩個作用：一是用于前端用戶身份認證和鑒權；二則用來將前端HTTP請求轉發的對應服務中進行處理。

API網關的處理流程如圖7所示。API網關接收到前端發送的HTTP請求時，首先會判斷該請求是否為登錄用戶驗證請求，如果是，則直接解析請求URL，并轉發請求到服務層驗證；如果驗證通過，則生成token令牌，并保存到Redis緩存中，然后將token添加到響應頭部返回；如果驗證未通過，則直接返回403錯誤。如果API網關判斷該請求不是登錄用戶驗證請求，則對請求頭部攜帶的token進行驗證。如果驗證不通過，則直接返回401錯誤；如果驗證通過，則解析請求的URL地址。前端通過Web Portal層發送HTTP請求的URL主要由三部分組成：前綴、版本和服務層URL，其中前綴和版本就是4.3節中服務注冊時配置的endpoint中的target和API的版本信息version。API網關通過解析的前綴和版本號在服務注冊中心中查找相應服務的IP和端口號。如果找到相應的服務信息，則使用查找到的IP和端口號以及服務層URL將請求轉發到服務層對應服務中進行處理；否則，直接返回404錯誤。

6 實驗結果與分析

6.1 測距探針測試

實驗中，采用激光測距傳感器(測量距離12 m，誤差±5 mm)，結合圖2所示的結構設計了測距探針的電路，并制作了測距探針實物。本文設置了56組測距模型，分別使用測距探針和人工方式測量了所有模型的距離。根據測量數據，繪制了如圖8所示的折線圖。

圖8 56組測量數據折線圖

由圖8可知，測距探針測量與人工測量的測量結果基本一致。當測量距離不超過10 m范圍，測距探針的測量誤差不超過±2 mm；而測量距離在10～12 m之間，測距探針誤差相對較大，但也不超過±5 mm。由此可知，測距探針的測量結果穩定、誤差較小、可靠性高。另外，由于測距探針利用轉換電路可以適配不同類型的測距傳感器，因此在大型項目中如果需要使用不同傳感器測量只需將不同的傳感器接入對應的轉換電路接口即可，簡化了電路的設計與開發。

6.2 數據分析模塊與服務層性能測試

本文使用Linux虛擬機搭建基于Hadoop集群的數據分析模塊測試環境。其中，包含一個namenode節點和4個datanode節點，所有節點的規格都為2核4 GB內存、50 GB硬盤、Ubuntu14.04操作系統。實驗中，使用Yarn(Hadoop2.0新MapReduce框架)分析多個測距探針采集的數據日志文件，從中提取出測距數據以及溫度、心跳等監控數據。該實驗分別使用2、3、4個節點處理同一量級的測距數據；然后將多組數據的處理時間繪制成如圖9的折線圖進行分析。

圖9 2、3、4個節點數據處理性能對比折現圖

由圖9可知，當數據量小于100 MB時，2個節點處理同一量級數據的速度比3個、4個節點的處理速度更快，這主要是由于此時2個節點map、reduce操作的數量較少，且可以滿足處理數據量的要求；而3個、4個節點還需要考慮到節點的調度與數據交互等多個因素。當數據量大于100 MB，3個、4個節點的處理速度明顯提高，這是由于此時兩個節點已經無法很好地滿足計算數據量的需求，需要通過擴展多個datanode節點達到更好的處理效果。

隨著項目的不斷增加，處理的數據也將不斷增長。為了提高數據分析模塊的處理速度，降低節點的流量，系統可以繼續增加一個或多個datanode節點，并通過3.2節中提出的負載均衡器實現各節點的負載均衡。需要注意的是，集群節點并不是越多越好，而是應該根據需要選擇合適的節點數。使用多節點存儲和處理數據，避免了系統的單點故障，也可以實現系統的橫向擴展。

實驗中，服務層的所有應用都部署在Docker容器中，然后通過Kubernetes管理所有容器。如果需要添加服務，只需要根據4.3節所提出的方法在對應服務中實現服務注冊功能，然后將其制作成Docker鏡像并以Docker容器的方式啟動即可。這樣，各服務都只需要通過服務注冊中心進行管理，并利用API網關對外提供統一接口，實現松耦合，簡化了各服務的開發，降低了系統的復雜度。

6.3 前端顯示

系統Web Portal層為用戶提供界面友好的測距系統界面，方便用戶通過手機和瀏覽器訪問和管理系統。圖10展示了測距探針的測量數據的監控界面。

圖10 測距探針監控界面

7 結 語

測距系統廣泛應用于環境、電力、鐵路、軍事等領域，對于一些精度要求高、測量范圍廣的場景，測距系統的可靠性、精確性和擴展性顯得尤為重要。本文首先提出了一種基于微服務的分布式測距系統架構。然后分別深入闡述了測距探針、數據分析模塊、服務層以及API網關的設計與實現。本文提出的測距系統通過WIFI接入網絡，方便快捷，使用戶只需通過PC機或手機便可以遠程監控測距探針的狀態和測量數據。系統采用了Ad Hoc自組網技術，使得測距探針可以自動匹配路由信息，降低了組網難度，從而使得添加或刪除測距探針更加容易。本文設計的分布式測距系統利用分布式和負載均衡的思想，避免了由于單一計算節點導致的單點故障和測量數據不準確等問題，大大提高了測距系統的可靠性。另外，系統基于微服務架構實現服務自發現和服務注冊功能，不僅簡化了開發和降低了系統復雜度，還提高了測距系統的橫向擴展性。

參考文獻

[1] Garcia M A, Solanas A. Automatic Distance Measurement and Material Characterization with Infrared Sensors[C]//RoboCup 2004:Robot Soccer World Cup VIII. DBLP, 2004:451-458.

[2] Zhang F, Ge X, Gao B, et al. Phase-coded microwave signal generation based on a single electro-optical modulator and its application in accurate distance measurement[J]. Optics Express, 2015, 23(17):21867-21874.

[3] Kelemen M, Virgala I, Kelemenova T, et al. Distance Measurement via Using of Ultrasonic Sensor[J]. Microelectronics Journal, 2015, 33(5):479-486.

[4] 孟文東, 湯凱, 鄧華榮,等. 1064nm波長衛星激光測距技術和實驗研究[J]. 光學學報, 2015, 35:(a01):197-202.

[5] 衛志斌, 瞿鋒, 項清革,等. SESAM鎖模激光器在衛星激光測距領域應用研究[J]. 測繪科學, 2009, 34(6):5-6.

[6] 侯建剛，陶然，單濤，等. m系列在激光測距雷達中的應用[J]. 兵工學報, 2005, 26(1):37-41.

[7] 賀大松，門延會. 激光測距技術在汽車主動安全裝置中的應用研究[J]. 應用激光, 2011, 31(2):160-163.

[8] 隋金雪，楊莉，賀永強. 激光測距在移動機器人自主導航中的應用[J]. 傳感器與微系統, 2007, 26(7):114-117.

[9] 李勇，黃均才，王鳳碧，等. Ad Hoc網絡體系結構研究[J]. 計算機應用, 2005, 25(1):163-164.

[10] 張松，杜慶偉，孫靜，等. Hadoop異構集群中數據負載均衡的研究[J]. 計算機應用與軟件, 2016, 33(5):31-34.

[11] 李春陽，劉迪，崔蔚，等. 基于微服務架構的統一應用平臺[J]. 計算機系統應用, 2017, 26(4):43-48.

[12] 宋濤，徐慶增，呂思思. 淺談基于Spring MVC的REST功能[J]. 電腦知識與技術：學術交流, 2016, 12(12):86-87.

[13] Perkins C, Belding-Royer E, Das S. Request for Comments:Ad hoc on-demand distance vector (AODV) routing[J]. Experimental Internet Society, 2003, 6(7):90.

[14] 曹旭，張云華. Hadoop平臺下計算模型中調度策略的研究[J]. 計算機應用與軟件, 2013, 30(9):208-214.