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

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

0 引 言

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

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

1 系統(tǒng)架構

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

圖1 系統(tǒng)架構

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

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

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

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

2 測距探針的設計

2.1 測距探針結構

測距探針是該分布式測距系統(tǒng)的數(shù)據(jù)采集核心組件，該模塊實現(xiàn)了數(shù)據(jù)采集、數(shù)據(jù)預處理、WIFI通信與心跳檢測等功能。圖2顯示了測距探針的內(nèi)部結構。

圖2 測距探針內(nèi)部結構

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

2.2 測距傳感網(wǎng)絡

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

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

圖3 路由算法流程圖

3 數(shù)據(jù)分析模塊的設計

3.1 分布式數(shù)據(jù)分析與存儲的實現(xiàn)

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

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

圖4 數(shù)據(jù)分析模塊處理過程

3.2 負載均衡的實現(xiàn)

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

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

圖5 負載均衡策略圖

4 服務層的設計

4.1 服務層結構

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

圖6 服務層結構

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

4.2 服務發(fā)現(xiàn)

該系統(tǒng)采用服務端發(fā)現(xiàn)方式實現(xiàn)服務自發(fā)現(xiàn)，客戶端通過API網(wǎng)關轉發(fā)請求到具體的服務處理請求。因此，該系統(tǒng)在服務層實現(xiàn)了一個服務注冊中心管理各個服務的注冊信息。

該系統(tǒng)利用將所有服務的IP和端口號以key-value(鍵值對)形式保存到etcd中；服務注冊中心則提供兩類API管理etcd中的配置信息。一類API為管理服務API，主要實現(xiàn)服務的注冊和注銷功能；另一類API為查詢服務API，API網(wǎng)關通過該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″

}]

}

}

}

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

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

5 API網(wǎng)關的設計

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

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

6 實驗結果與分析

6.1 測距探針測試

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

圖8 56組測量數(shù)據(jù)折線圖

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

6.2 數(shù)據(jù)分析模塊與服務層性能測試

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

圖9 2、3、4個節(jié)點數(shù)據(jù)處理性能對比折現(xiàn)圖

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

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

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

6.3 前端顯示

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

圖10 測距探針監(jiān)控界面

7 結 語

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

參考文獻

[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波長衛(wèi)星激光測距技術和實驗研究[J]. 光學學報, 2015, 35:(a01):197-202.

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

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

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

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

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

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

[11] 李春陽，劉迪，崔蔚，等. 基于微服務架構的統(tǒng)一應用平臺[J]. 計算機系統(tǒng)應用, 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.