基于SOA的云機器人服務框架設計

劉曉軍，類成玉，吳 皓+，楊 勇

(1.中國石油大學勝利學院 機械與控制工程學院，山東 東營 257000；2.山東大學 控制科學與工程學院，山東 濟南 250061；3.濟南皓源自控系統工程有限公司 技術部，山東 濟南 250000)

0 引 言

服務型機器人較普通機器人在人機交互時面臨著更大的計算和存儲開銷，而傳統服務型機器人僅僅依靠本地資源進行任務的求解已無法滿足其實時性和計算能力的需求。文獻[1-5]通過將云計算與機器人結合不僅緩解了機器人的本地計算壓力，而且實現了機器人之間的協作和信息共享，使機器人具有了更高的智能性。然而這些工作普遍采用的使點對點的機器人服務提供方式，機器人與云平臺架構不統一，缺乏機器人服務的可拓展性。為了使云機器人服務具有更高的可拓展性，文獻[6-9]基于SOA架構實現了機器人應用的服務化，提高了機器人應用的拓展性、可維護性和可管理性，并且實現了異構機器人之間服務的相互調用。然而上述工作仍然缺乏對云機器人系統中各種資源的管理和合理調度，無法充分云機器人的各種資源。針對這些問題，本文基于SOA架構設計了一種云機器人分布式服務框架，通過云計算基礎平臺對云機器人典型應用環境中的資源進行統一的管理和調度，其中包括計算資源、存儲資源、機器人資源和設備/傳感器資源等，提高了云機器人集群資源的利用率。同時本文基于Alibaba的Dubbo框架來構建云機器人分布式服務，將機器人服務項進行多副本化覆蓋到服務器節點中，實現了機器人服務的負載均衡和彈性容錯。并且機器人服務的分布式部署可以充分利用異構主機的不同特性，充分發揮異構主機的優勢，提高云機器人系統資源利用率和機器人服務的質量。

針對單一服務無法滿足用戶和機器人復雜應用需求，我們采用服務組合[10]的方式將單一的服務集成組合起來，從而提供更加綜合復雜的服務。統一描述發現和集成(universal description，discovery and integration，UDDI)算法與自適應負載均衡(load capacity based algorithm，LCB)算法是目前常用的服務查找和組合算法，文獻[11]利用了并行蟻群算法對優化了服務組合，文獻[12]提出了一種基于概率模型檢測服務組合方法，通過將Web服務組合過程建立為定量多目標馬爾可夫決策過程的方式，解決了服務組合的不確定性。本文在LCB算法的基礎上對機器人云平臺各個節點提供服務的服務質量進行了詳細的度量，改進了LCB算法，提出了一種新的分布式服務查找和組合的算法。該算法基于分布式哈希表(distributed hash table，DHT)路由算法注冊和發布服務項，建立每個節點的服務路由表，隨后測度供選擇節點的負載均衡變化狀況以及該節點的服務質量信息，并根據這些信息選擇下一跳的服務節點，動態地構建出路徑代價最小的服務組合路徑。

1 云機器人分布式服務框架整體結構

服務型機器人正逐漸進入人們的日常生活中，相比工業機器人，服務機器人常被安置于各式各樣的復雜環境中，需要經常與人和復雜環境交互，因此需要更高的智能性和自主性，能夠對根據收集的信息和人們的指令及時做出反應，并能夠順應環境的變化做出相應調整。服務型機器人的典型應用場景中主要有5種角色：用戶、終端設備、機器人集群、服務器集群和固定設備/傳感器。在該應用場景中機器人既是服務的提供者又是服務的消費者，從而實現機器人集群多機協作完成各種復雜的任務，同時又可以通過云端獲取環境中固定硬件設備的傳感器信息，拓展機器人的信息來源。服務器集群則是整個系統的核心，是服務的提供者，同時又是整個系統的服務的注冊中心和管理中心，所有服務包括機器人集群提供的服務最后也要向服務器集群的服務注冊中心進行注冊，并由服務的管理中心進行統一的調度。用戶作為服務的消費者可以通過指令或終端設備來獲取由機器人集群、服務器集群和固定設備集群構成的云機器人系統所提供的服務。

本文設計的云機器人分布式服務框架如圖1所示，框架共分為5層，分別為：物理層、資源層、分布式計算和服務運行層、服務實現和服務組合層、SOA接口層。該框架旨在解決傳統機器人本地計算和存儲資源的匱乏，充分利用云端大數據處理能力來提升機器人的計算和存儲能力，并且結合環境中的固定設備和傳感器來拓展機器人的信息來源，而且機器人能夠通過云端共享數據，方便進行協作，從而提升機器人的服務能力。框架中的SOA接口層，使得框架中的硬件設備都采用統一的接口，屏蔽了異構機器人底層之間差異，從而更方便地為異構機器人提供通用的服務，使得系統的服務功能拓展和管理更為靈活。

圖1 云機器人分布式服務框架的整體架構

在框架下，物理層的機器人集群、服務器集群和設備/傳感器集群將作為整個系統中資源的提供者，其為機器人云平臺中的服務執行提供計算、存儲、機器人硬件和設備/傳感器等資源。而資源層是這些資源的注冊中心和管理中心，為云平臺提供資源發現和資源管理的功能。分布式計算和服務運行層、資源層共同構成了云平臺，云平臺從物理層獲取資源，對資源進行注冊、管理和調度，并向服務實現層提供統一接口，為服務的運行提供基礎環境。

下面詳細介紹一下框架結構中的各層功能：

(1)物理層和資源層

物理層是整個框架的基礎，通過網絡將系統中的服務器、機器人和固定設備進行互聯，為云平臺提供計算資源、存儲資源、機器人資源和設備資源。資源層是資源的注冊和管理中心，為云平臺提供資源發現的功能，并對資源進行統一的管理和調度。在資源層，我們采用云計算平臺Cloudstack[13]對服務器集群進行管理和配置，對從服務器集群抽象出的計算資源和存儲資源以及機器人和設備/傳感器進行注冊和管理。同時資源層將提供資源狀態監控服務，隨時掌握資源的使用狀況，從而更加合理調度資源，提供資源的利用率。

(2)服務實現層和服務組合層

服務實現和服務組合層由服務開發者進行管理和維護，服務開發者根據云平臺提供的統一接口來開發機器人服務，然后對服務進行封裝發布。同時，服務開發者可以集成和組合已有服務形成新的服務，新服務的組成成員之間通過通信按照一定的邏輯來處理用戶或者機器人的復雜請求，從而靈活地實現上層的服務模型。同時通過分布式服務組合可以將云機器人分布式集群中已有的細粒度服務集成起來，共同為用戶或機器人提供更加復雜的服務任務，提高云機器人服務的可拓展性和健壯性。

(3)SOA接口層

SOA接口層是用戶或者機器人與云平臺進行交互的中間件，提供用戶交互、服務調用、服務管理和調度、服務監測等功能。SOA接口層可以屏蔽異構機器人底層差異，使服務以統一的方式進行交互，為異構機器人提供通用服務。如圖2所示，SOA接口層主要包含3個重要的模塊：服務調用代理，用戶交互代理和服務管理及監控中心。其中用戶交互代理和服務調用代理通過RPC(遠程過程調用)實現遠程服務的調用，用戶交互代理為用戶或機器人提供了統一的調用接口，從而實現用戶客戶端和機器人客戶端對云機器人集群中的各種分布式服務的查詢與調用。服務調用代理負責收集用戶交互代理接收到的各種服務調用請求，并負責將各種請求按照特定協議序列化，實現對云機器人集群環境中服務的調用和對服務處理響應結果的轉發。

本文基于Alibaba的Dubbo框架設計了云機器人分布式服務框架的SOA接口層，Dubbo框架是典型的SOA架構。在Dubbo框架下服務是圍繞服務提供方和服務消費方的，服務提供方實現服務，而服務消費方遠程調用服務。其中服務提供者運行在服務器端，是暴露服務的服務提供方，在云機器人分布式集群中，服務提供者可以以多副本的形式運行在多臺集群主機上，通過服務調度和負載均衡為服務消費者提供更健壯和魯棒的服務。服務注冊端是服務注冊和發現的注冊中心。服務運行容器是服務實例的實際運行位置，服務監控端負責監控服務的運行，統計服務的調用次數和調用時間。

2 云機器人服務組合負載均衡算法

2.1 分布式服務組合的模型定義

在云機器人分布式服務框架下定義了云機器人集群服務覆蓋網絡，如圖2所示，在服務覆蓋網絡中的節點可以是服務器，也可以是機器人或智能設備；而邊表示節點與節點之間的通訊情況，其值的大小代表節點之間的通信代價。在集群服務覆蓋網絡中的節點上可以將服務以多副本的形式部署上去，對于只能由機器人節點處理的服務，應該將該類服務部署到機器人的節點主機上，其它類別的服務要按照服務的服務質量選擇部署到響應的節點上，從而充分發揮異構節點主機的各自優勢，實現機器人云平臺的負載均衡和彈性容錯。圖2是云機器人分布式服務組合的示意圖，云機器人服務組合請求時，利用本文的分布式服務查找和組合算法在機器人集群服務覆蓋網絡中選擇相應的服務，并且建立從服務調用客戶端到出口節點的服務路徑，并優化其路徑代價，從而提高服務的QPS和高可用性，通過服務組合可以集成細粒度的服務從而構成復雜的新應用，提高服務機器人的服務能力。

圖2 云機器人分布式服務組合

圖2中顯示了4種服務及其副本的部署情況，用戶請求組合服務3和服務4時，算法將搜尋服務覆蓋網絡中的節點并建立一條從服務調用節點到服務出口節點的路徑代價較小的服務路徑，該路徑連接了服務4和服務3兩個服務實例，為用戶提供一個由服務3和服務4組合成的復雜應用服務。服務路徑中允許存在請求/響應數據轉發服務，用來對服務請求和響應的數據進行轉發。服務數據沿著服務路徑傳輸，最后傳遞給用戶。

基于SOA架構的云機器人集群服務覆蓋網絡如圖2所示，將云機器人系統集群服務覆蓋網絡抽象成一個無向圖G=(V,E)，其中V是集群服務覆蓋網絡中節點的集合，其個數為N；E是節點之間邊的集合。設任意兩個服務副本如果位于同一個節點上，則其之間的通信延遲為0；若任意兩個服務副本位于兩個不同的節點上時，則其之間的通信延遲為τ。將節點集合V中的每個節點vi抽象為一個五元組vi=[ci,mi,qi,si,Di]。其中ci為第i個節點主機的CPU性能；mi表示第i個節點主機的內存綜合性能；qi記錄了當前節點vi上部署的云機器人服務列表；si表示當前節點vi上的服務請求隊列；Di是當前節點vi上的服務轉發列表。一個服務組合請求可以標識為Sp(S0,S1,S2,…,SL-1)，其中Sp為服務組合請求，L為服務請求數量，服務組合路徑上的服務標識依次為S0,S1,S2,…。

2.2 分布式服務路由的建立

傳統集群服務注冊和發現方法大部分采用中心化結構，即采用一個服務注冊和管理中心總責所有節點上的服務注冊和查找，這樣使得服務注冊和管理中心面臨著較高的運算壓力，容易造成注冊和管理中心節點過載導致機器人云平臺集群的癱瘓。為了解決該問題，本文運用基于DHT的路由算法對服務進行注冊和查找，該算法將機器人云平臺中的每一個細粒度的服務利用哈希方法映射為一個數據元標識符，且同一服務的不同副本具有相同的哈希值，這樣可以滿足服務及其響應副本的功能特征的存儲需求。服務轉發列表Di的表中元素項可以表示為一個四元組R=[Ni,RSi,Ti,Li]。其中Ni為服務組合請求調用客戶端所在的節點，RSi表示當前節點中所需要調用的服務實例，Ti表示調用服務的下一跳節點，Li是從節點Ni到服務調用出口節點的最短路徑長度。該路由算法分兩步建立分布式服務路由表：①對每一個節點vi，將該節點上部署的所有服務實例存儲到其服務提供列表qi中，從而實現服務的注冊與發布。②根據云平臺服務覆蓋網絡的通訊狀況對每個節點vi中的服務路由列表Di進行構建和更新。

2.3 分布式服務組合的負載均衡策略

(1)

在實際云平臺應用情形下，云平臺各個節點的實時負載狀況是難以觀測的，因此，我們將節點當前時刻的負載測度近似為當前時刻前后一段時間內的服務請求隊列的變化。節點的綜合性能由CPU綜合性能狀態參數ci、內存綜合性能參數mi、服務請求等待隊列si的長度Lsi等狀態參數共同決定。設云機器人集群服務覆蓋網中節點vi在T1時刻的系統資源的狀態參數為ciT1，miT1，LsiT1；在T2時刻的系統參數測度為ciT2，miT2，LsiT2，定義節點vi的負載變化測度ρ′i

(2)

式(2)計算了某一時間段內節點的負載變化情況，如果ρ′i≤0時，表示節點vi在T1到T2期間有服務已經處理完成，節點的資源得到了釋放，負載的測度也隨之降低；反之，當ρ′i>0時，表示節點vi在T1到T2期間存在服務請求積壓現象，服務請求處理能力小于接受的服務請求數，節點負載測度隨之增加。

利用云機器人集群節點的負載測度對機器人服務組合路徑進行計算的算法流程如圖3所示，當有客戶端向云機器人集群中某一節點vi發起服務組合請求Sp(S0,S1,S2,…,SL-1)時，會依次對服務組合請求Sp中的每一個服務調用請求Sj，查詢當前節點的服務路由列表Di，如果服務路由列表中只有一條與服務Sj相關的信息，則根據路由列表Di中的信息將服務Sj的請求轉發至響應的節點vi，并在節點vj上執行當前服務，并將服務響應結果原路返回至客戶端；如果服務路由列表Di中有多條與服務Sj相關的信息，那么根據式(2)去計算路由表中每一個下一跳節點的負載測度，并選擇一個負載測度最小的節點Sj，將服務請求轉發至節點vj上去執行，同樣也將服務響應原路轉發返回至客戶端。如此循環直至將服務組合請求中的每一個服務請求全部執行完畢后，則云機器人分布式服務組合成功結束。

3 實驗設計與分析

3.1 云機器人分布式服務組合和服務調用實驗

實驗利用Alibaba的Dubbo框架搭建云機器人分布式服務框架，利用實驗室的3臺電腦來搭建云機器人分布式集群環境，3臺主機配置都是CPU：Intel Core i5-6500，內存8 G，硬盤1 T，操作系統Ubuntu16.04 64位。首先利用Dubbo框架封裝了基于opencv的人臉檢測程序和人臉識別程序并將其分別發布為人臉檢測服務和人臉識別服務。然后通過分布式服務組合算法組合發布的人臉檢測服務和人臉識別服務，實現對機器人場景中人臉的檢測和識別。實驗具體的處理過程及實驗效果如圖4所示，首先調用人臉檢測服務將圖片中的人臉提取出來，然后調用人臉識別服務對上一步提取出的人臉進行識別。

實驗中云機器人集群的節點分布情況和兩類服務及其副本的部署情況如圖5所示，集群中的3臺主機兩兩可以通信，兩類服務各有3個服務副本，其中a1,a2,a3是人臉檢測服務的3個副本，b1,b2,b3是人臉識別服務的3個服務副本，c1,c2,c3是非操作服務，主要負責服務請求和響應數據的轉發。為了說明框架的有效性和魯棒性，我們將發布的人臉檢測服務和人臉識別服務按照圖5的方式部署到云機器人分布式服務框架中，并利用wrk工具對云機器人分布式服務框架中的這兩種服務進行壓力測試。表1是壓力測試的統計結果，我們分別進行了3種場景下的3輪壓力測試，3種場景分別是128個連接、256個連接和512個連接，即同一個時刻同時會有128、256或512個服務調用請求，并且每種場景進行3輪每輪持續20 s的服務調用壓力測試，分別統計了這20 s的服務成功調用的次數、服務調用失敗(或者超時)的次數、QPS(每秒服務成功調用并返回正確響應結果的次數)。如表1的統計結果所示，本文的云機器人服務框架在面臨著人臉檢測和人臉識別這類的計算密集型的服務時，仍能保持1000以上的QPS，并且隨著連接數的升高，QPS也能隨著上升。因為服務調用采用的是異步調用方式，前一個沒有完成服務不會阻塞下一個服務的調用，因此能夠獲得較高的QPS。

圖3 云機器人分布式服務組合算法流程

圖4 實驗過程及實驗效果

圖5 節點的分布情況和兩類服務及其副本的部署情況

表2是服務組合路徑的統計結果，我們分了3輪實驗，分別將服務調用客戶端入口置于圖5所示的3個不同的節點主機上，然后分別進行服務組合調用，統計每輪實驗的服務組合服務路徑，實驗結果見表2，通過表2可以看出，每次實驗結果得到的服務組合路徑基本是最短的，從而驗證了本文提出的云機器人分布式服務框架的可行性和有效性。

表1 云機器人框架中人臉檢測和識別服務壓力測試的統計結果

3.2 云機器人分布式服務查找和組合的仿真實驗

我們借助Gridsim網絡仿真工具進行仿真實驗來驗證本文設計的分布式服務框架的負載均衡效果以及服務組合調用的QPS。首先利用Gridsim工具建立起實驗的云機器人集群服務覆蓋網絡，其中含有10個節點，然后從該10個節點中隨機選出5個作為服務實例的部署節點。最后在節點上部署S0～S9共10種不同的服務，每個服務會話持續60 s，且每種服務含有3個服務副本，則在集群服務覆蓋網絡中共含有30個服務實例。我們將這30個服務實例均勻部署到50個部署節點上去，那么每個部署節點含有6個服務實例，同時設置資源的權重集合λ=[0.2,0.2,0.5]。

表2 服務組合路徑的統計結果

我們在仿真環境下進行服務組合調用，每個服務請求隨機選擇S0～S9這10種服務中的6種進行組合，設置30 次/s的請求頻率，持續請求60 s的時間。表1是該模擬實驗統計的每種服務副本上處理請求的個數，由表1可以看出S0～S9這10種服務的3個副本分別處理的請求個數基本上一致，因此可以得出結論，本文的分布式服務框架具有較好的負載均衡效果。

同時，我們在仿真環境中對UDDI算法、LCB算法和本文提出的分布式服務查找和組合算法進行了壓力測試。設置每個服務會話的持續時間為10 ms，設置服務覆蓋網絡是密集的且相鄰節點的網絡延遲為8 ms。我們將10種不同壓力環境(單位時間內進行的服務請求次數)下的單個服務組合的平均完成時間作為服務組合性能的測度。圖6是這3種算法的性能對比曲線。

圖6 分布式服務組合算法的性能對比

如圖6的3種算法的服務組合性能對比效果所示，UDDI算法在服務調用壓力較小時(單位時間內的服務請求次數較少)，其單個服務組合的平均完成時間最少，即服務組合的性能最好，這是因為UDDI采用的是中心化的結構，不需要考慮網絡的拓撲結構，所以其在壓力小時具有較好的性能。而當服務調用壓力上升，即單位時間內服務請求的次數上升至600 次/s時，UDDI算法的性能下降，這是由于壓力過大時造成服務注冊和管理中心過載，服務調用周期變長。而由于本文算法和LCB算法采用的是分布式的去中心化的結構，在服務調用壓力上升時不會出現類似UDDI算法性能下降的情況，其單個服務組合的平均完成時間變化較為平穩。在整體看來，本文算法在各種不同調用壓力情況下其單個服務組合的平均完成時間都要低于LCB算法，這是因為本文算法在節點負載度量和服務路徑規劃方面做了改進，從圖6可以看出本文的云平臺分布式服務查找和組合算法在性能上要優于LCB算法。

4 結束語

本文設計的云機器人分布式服務框架，通過云機器人服務的分布式部署，充分發揮了機器人云平臺中異構主機的各自優勢，提高了資源的利用率和服務的質量，并通過設計服務框架的SOA接口層實現了云機器人服務的跨平臺調用，提升了機器人云平臺的可拓展性和對異構機器人的兼容性。同時，本文提出的多服務副本下服務查找和組合算法，通過節點一段時間內的負載變化估計節點的負載情況，并在服務組合時根據節點的負載情況動態構建服務路徑路徑，從而實現了機器人云平臺下的負載均衡和彈性容錯，提高了云機器人集群的穩定性和服務的吞吐量。接下來可以對服務組合的復雜度進行更深入的研究，進一步提高機器人的服務能力和負載均衡能力。