李冰鑒，邊 境

(浙江理工大學(xué) 信息學(xué)院，浙江 杭州 310018)

0 引 言

軟件定義作為近十年來提出的新興概念，已經(jīng)出現(xiàn)了各種應(yīng)用實現(xiàn)。而作為這個概念最成熟的應(yīng)用之一的軟件定義網(wǎng)絡(luò)(SDN)[1-2]，核心思想是將網(wǎng)絡(luò)分為基礎(chǔ)設(shè)施層、控制層和應(yīng)用層。其中控制層通過南向接口與基礎(chǔ)設(shè)施層通信，向交換機及路由器等基礎(chǔ)設(shè)施下發(fā)數(shù)據(jù)包的轉(zhuǎn)發(fā)規(guī)則；再通過北向接口向網(wǎng)絡(luò)管理者提供網(wǎng)絡(luò)相關(guān)的可編程接口，網(wǎng)絡(luò)管理者通過使用提供的接口來編寫管理程序來設(shè)定控制層，從而控制整個網(wǎng)絡(luò)中數(shù)據(jù)包的轉(zhuǎn)發(fā)行為。另一個軟件定義的應(yīng)用實例─軟件定義存儲[3-4]，核心思想是將管理和存儲數(shù)據(jù)的邏輯同實際存儲數(shù)據(jù)的硬件相分離，從而達到使用管理一個單獨存儲設(shè)備的邏輯來維護由多個不同存儲硬件所組成的存儲集群的目的。故軟件定義的本質(zhì)就是將提供相同功能的不同基礎(chǔ)設(shè)施抽象為標(biāo)準(zhǔn)的接口，然后通過使用標(biāo)準(zhǔn)接口來使用基礎(chǔ)設(shè)施的功能而忽略其在具體實現(xiàn)上的差異[5]。

ROS[1](Robot Operating System，機器人操作系統(tǒng))是一款以UNIX操作系統(tǒng)為平臺，針對機器人開發(fā)時各種功能模塊不能復(fù)用的痛點所創(chuàng)造的分布式通信框架。經(jīng)過十多年的發(fā)展和版本迭代，其幾乎已經(jīng)成為機器人開發(fā)領(lǐng)域的主流標(biāo)準(zhǔn)。ROS主要分為四個組成部分：通信機制、開發(fā)工具、應(yīng)用功能以及生態(tài)系統(tǒng)[6]。而其中的通信機制是建立松耦合，點對點的分布式架構(gòu)的基礎(chǔ)所在。而這其中又包括異步的話題通信，同步的服務(wù)通信以及用于公共靜態(tài)數(shù)據(jù)存儲和共享的參數(shù)服務(wù)器。依托于這種通信方式所支持的分布式架構(gòu)，基本功能會以文件或者進程的形式存在并且共享，從而成功提高了代碼復(fù)用率。但是，在服務(wù)通信機制當(dāng)中卻存在服務(wù)端單點失效問題：一個服務(wù)只能由一個進程注冊提供，當(dāng)任何提供指定服務(wù)的進程停止工作，則服務(wù)不可用。并且因為服務(wù)通信的同步特性，失效的服務(wù)可能會造成無法預(yù)測的阻塞從而導(dǎo)致系統(tǒng)整體的可用性下降。

針對以上ROS服務(wù)通信機制中存在的單點失效問題，該文借鑒軟件定義網(wǎng)絡(luò)的主流標(biāo)準(zhǔn)OpenFlow[7]通過操作流表來定義，存儲和管理數(shù)據(jù)包轉(zhuǎn)發(fā)規(guī)則，從而控制網(wǎng)絡(luò)中數(shù)據(jù)包轉(zhuǎn)發(fā)行為的思想。設(shè)計了一種通過“服務(wù)表”來存儲服務(wù)端描述信息，然后使用手動或者自動管理機制將可用服務(wù)端通信地址提供給客戶端以完成服務(wù)通信的模型Rosie。該模型保證了在原有服務(wù)通信的邏輯上，對客戶端完全透明的條件下，實現(xiàn)了服務(wù)通信的高可用。并且又進一步參考了版本控制系統(tǒng)[8]的設(shè)計思路，提供了一種針對服務(wù)表的服務(wù)端可編程管理方案。從而滿足了軟件定義概念中“基礎(chǔ)設(shè)施虛擬化，管理任務(wù)可編程”[5]的基本要求。

1 背 景

1.1 軟件定義

軟件定義網(wǎng)絡(luò)起源于2006年斯坦福大學(xué)的Clean Slate研究課題[9]，其項目負(fù)責(zé)人Nick McKeown于2008年發(fā)表文章正式提出軟件定義網(wǎng)絡(luò)的第一個實驗性協(xié)議OpenFlow[10]。在現(xiàn)存的傳統(tǒng)網(wǎng)絡(luò)中，負(fù)責(zé)轉(zhuǎn)發(fā)數(shù)據(jù)包的交換機和路由器不僅要負(fù)責(zé)數(shù)據(jù)包的轉(zhuǎn)發(fā)行為，并且還要進行制定數(shù)據(jù)包向何處轉(zhuǎn)發(fā)的轉(zhuǎn)發(fā)決策。隨著網(wǎng)絡(luò)規(guī)模不斷擴大，交換機和路由器承擔(dān)的計算開銷也在不斷加大。為了解決網(wǎng)絡(luò)設(shè)備日趨嚴(yán)重的算力緊張問題，軟件定義網(wǎng)絡(luò)利用分層的思想，將數(shù)據(jù)包的轉(zhuǎn)發(fā)行為和轉(zhuǎn)發(fā)決策相分離，有效降低了路由器的工作負(fù)荷。

1.2 ROS

ROS誕生于2007年的斯坦福大學(xué)的STAIR(Stanford AI Robot)項目[11]，其成員發(fā)現(xiàn)在開發(fā)機器人軟硬件系統(tǒng)集成過程中，將各種功能集成在一個機器人上非常困難，于是就開始嘗試采用分布式的架構(gòu)來連接不同的功能模塊，而這也是ROS最終采用分布式結(jié)構(gòu)的動機。2007年Morgan Quigley及其導(dǎo)師Andrew Y. Ng在AAAI上發(fā)布了STAIR項目的研究成果Switchyard[12]，即ROS的前身。2009年，Morgan Quigley及其導(dǎo)師同一家名為Willow Garage的公司合作，又在ICRA上發(fā)表了文章[13]并向外界正式介紹了ROS。2010年，Willow Garage發(fā)布了開源的ROS 1.0并且建立了ROS社區(qū)。2012年Willow Garage公司又宣布成立Open Source Robotics Foundation[14]。在OSRF的運營下，ROS在近十年先后發(fā)布了若干個發(fā)行版本，截至目前最新的ROS版本是發(fā)行于2020年的ROS Noetic Ninjemys[15]。

2 架 構(gòu)

本節(jié)在以描述ROS系統(tǒng)架構(gòu)以及其服務(wù)通信機制的基礎(chǔ)上，介紹以軟件定義為范式，為了解決其單點失效等問題從而重新設(shè)計的服務(wù)通信模型Rosie。通過同現(xiàn)有的ROS框架進行對比的方式來表現(xiàn)Rosie模型所解決的問題的方式及其設(shè)計的優(yōu)勢所在。

2.1 整體架構(gòu)

ROS作為一種松耦合、分布式的通信框架，其中的通信單元是節(jié)點(ROS Node)。邏輯上的節(jié)點是一項功能。而實際中的節(jié)點是一個用來完成特定任務(wù)的進程或者線程。并且，只要遵循ROS通信機制的標(biāo)準(zhǔn)協(xié)議，每個節(jié)點可以選擇不同的，受ROS支持的語言進行編寫，并運行在不同的主機上。為了能讓節(jié)點之間互相通信，ROS提供了一個特殊的管理進程即ROS Master，該進程是所有節(jié)點的管理者。負(fù)責(zé)提供節(jié)點信息的注冊，以及服務(wù)通信中服務(wù)端的套接字地址，以供客戶端查找并通信。最后還提供參數(shù)服務(wù)器的功能，用于存儲和提供在所有節(jié)點之間靜態(tài)的，共享的數(shù)據(jù)。ROS Master進程在一個基于ROS的分布式系統(tǒng)中是唯一的，故必然也存在同樣的單點失效問題。如果因為系統(tǒng)的復(fù)雜化導(dǎo)致管理節(jié)點的數(shù)量持續(xù)上升，那么承載節(jié)點管理服務(wù)的硬件設(shè)備也可能面臨超負(fù)荷運行的風(fēng)險。如圖1所示，ROS節(jié)點管理進程，圖像獲取和圖像處理節(jié)點運行在主機ROBOT上，而圖像顯示節(jié)點運行在主機LAPTOP上。功能節(jié)點向節(jié)點管理器注冊并且互相查找進行通信，從而完成特定的任務(wù)。

圖1 ROS整體架構(gòu)

而在重新設(shè)計的軟件定義模型Rosie中，包括節(jié)點管理器(Rosie Master)在內(nèi)的所有功能都由節(jié)點(Rosie Node)來進行創(chuàng)建。這樣設(shè)計對比ROS的優(yōu)勢在于：節(jié)點管理器可以出現(xiàn)在系統(tǒng)中的任意節(jié)點上，不同系統(tǒng)的設(shè)計者可以根據(jù)不同情況來決定節(jié)點管理器的運行環(huán)境。除此之外該設(shè)計還為節(jié)點管理器的去中心化創(chuàng)造了條件。如圖2所示，在軟件定義模型Rosie中，圖像處理節(jié)點和圖像獲取節(jié)點位于主機ROBOT上。和ROS不同的是，圖像處理節(jié)點還同時承擔(dān)了節(jié)點管理器的功能。并且，用戶還可以將這個功能創(chuàng)建在圖像獲取或者圖像展示等任何其他節(jié)點上。

圖2 Rosie整體架構(gòu)

2.2 軟件定義服務(wù)通信架構(gòu)

2.2.1 服務(wù)端虛擬化

在ROS服務(wù)通信機制中，一個服務(wù)名稱只能由一個特定的服務(wù)對象注冊并提供服務(wù)功能，服務(wù)對象的相關(guān)信息通過服務(wù)名稱這個服務(wù)的唯一特征注冊在ROS Master中。需要使用該服務(wù)的客戶端需要通過服務(wù)名稱向ROS Master查詢服務(wù)是否存在。若服務(wù)存在，那么ROS Master會將服務(wù)通信套接字地址傳遞給客戶端，客戶端通過接收到的服務(wù)地址來使用服務(wù)；若服務(wù)不存在，則需要一直等待，直到有相應(yīng)服務(wù)注冊。這種機制的缺點在于，一旦提供特定服務(wù)的進程失效，雖然在節(jié)點管理器中能夠查找到服務(wù)端的套接字地址，卻無法建立有效的連接，可能會導(dǎo)致系統(tǒng)拋出異常從而使整個系統(tǒng)的穩(wěn)定性下降。如圖3所示，若服務(wù)節(jié)點ROS SERVER停止工作，那么即使ROS CLIENT可以從ROS MASTER處查詢到ROS SERVER的套接字地址，也無法建立連接并完成服務(wù)。

圖3 ROS服務(wù)通信機制

而在Rosie服務(wù)通信機制中，服務(wù)特征被擴充至3個：服務(wù)名稱、輸入數(shù)據(jù)類型和輸出數(shù)據(jù)類型。其中服務(wù)名稱決定服務(wù)邏輯，輸入和輸出數(shù)據(jù)類型決定該邏輯所作用的數(shù)據(jù)類型。該設(shè)計的優(yōu)勢在于：對于抽象的服務(wù)邏輯，可以提供多個不同的實現(xiàn)；而任意一種服務(wù)邏輯的實現(xiàn)，可以作用于不同的數(shù)據(jù)類型。相比于ROS中區(qū)分服務(wù)只能通過不同的服務(wù)名稱，Rosie中服務(wù)的定位方式更加有利于服務(wù)進行分類管理。

如圖4所示，Rosie借鑒了OpenFlow中使用流表來管理數(shù)據(jù)包轉(zhuǎn)發(fā)規(guī)則的思想，使用服務(wù)表來管理服務(wù)端信息的注冊和查詢。如圖5所示，當(dāng)客戶端發(fā)出服務(wù)查詢請求之后，Rosie Master通過客戶端提供的服務(wù)特征在服務(wù)表中查詢，若服務(wù)存在，則在檢查完服務(wù)有效性之后將服務(wù)信息返回給客戶端；若服務(wù)不存在，則返回一個空的套接字地址對象來通知客戶端其指定的服務(wù)不存在。而客戶端會通過輪詢的方式不斷向Rosie Master查詢該服務(wù)，直到存在為止。當(dāng)客戶端拿到服務(wù)端套接字地址信息之后，若成功請求服務(wù)，則完成服務(wù)流程；若套接字地址所指向的服務(wù)端失效，則重新請求Rosie Master查詢指定的可用服務(wù)端。

圖4 Rosie服務(wù)通信機制

最后，Rosie并沒有將服務(wù)表預(yù)設(shè)為具有特定數(shù)據(jù)結(jié)構(gòu)的容器，而是將服務(wù)表設(shè)定為抽象的接口，任何實現(xiàn)了服務(wù)表接口的容器類所創(chuàng)建的容器對象都可以用來構(gòu)造Rosie Master并作為其服務(wù)表使用。這樣設(shè)計的優(yōu)勢在于：不僅滿足了用戶和開發(fā)者可能在不同場景下自定義服務(wù)表的需求，同時也不會破壞服務(wù)通信的既定工作流程。以上設(shè)計很好地滿足了軟件定義概念中對于“基礎(chǔ)設(shè)施虛擬化”的核心要求。

圖5 Rosie服務(wù)通信流程

2.2.2 服務(wù)端的可編程管理

Rosie借鑒了版本控制系統(tǒng)的設(shè)計思想，管理端將服務(wù)表中的內(nèi)容以拉取的方式完全傳輸?shù)奖镜?，用戶程序?qū)ζ渲械膬?nèi)容進行修改之后，再推送到Rosie Master中以更新服務(wù)表。這種管理方式的優(yōu)勢在于操作具有較粗的粒度，在管理過程中僅有拉取和推送兩個數(shù)據(jù)傳輸操作，大大降低了網(wǎng)絡(luò)開銷。并且將表項數(shù)據(jù)拉取到本地之后，不僅可以利用本地算力來快速地對表進行修改，還可以檢查服務(wù)表項中通過接口方法無法查看的服務(wù)特征，具有較高的擴展性。但缺點是服務(wù)管理節(jié)點可以獲取服務(wù)表的全部內(nèi)容，對服務(wù)表內(nèi)容的操作具有完全修改權(quán)限，安全性無法得到保證。

總而言之，該管理方案基本滿足了軟件定義概念中對于“管理功能可編程”的核心要求。

3 實 驗

3.1 方 案

在使用“基礎(chǔ)設(shè)施虛擬化”概念來解決服務(wù)通信單點失效問題方面，實驗?zāi)繕?biāo)任務(wù)為客戶端每隔1秒請求一次時間服務(wù)，一共請求10次。提供時間服務(wù)的服務(wù)端會在啟動或同客戶端通信之后的20秒內(nèi)任意時間失效。每次實驗將上述任務(wù)重復(fù)500次。對比分別使用ROS和Rosie通信機制的客戶端時間服務(wù)請求成功的次數(shù)，并且計算任務(wù)完成的成功概率。而在實現(xiàn)“管理功能可編程”方面，實驗?zāi)繕?biāo)任務(wù)為在客戶端請求時間服務(wù)的過程中將所有服務(wù)關(guān)閉5秒從而阻止客戶端獲得時間，然后再啟用所有服務(wù)，使客戶端可以繼續(xù)使用時間服務(wù)。

3.2 結(jié)果與分析

當(dāng)使用ROS服務(wù)通信機制進行時間請求任務(wù)時，若唯一的時間服務(wù)器停止工作，則時間客戶端無法獲得時間并完成服務(wù)。除非時間服務(wù)器重新運行，否則客戶端會一直阻塞并且等待直到有可用的服務(wù)。

而使用Rosie服務(wù)通信機制進行相同的任務(wù)時，如圖6所示，即使當(dāng)前提供時間服務(wù)的服務(wù)器停止工作，只要系統(tǒng)中還有可用的時間服務(wù)器，Rosie Master就會查詢服務(wù)表并且將可用的時間服務(wù)器的通訊地址發(fā)送給客戶端使其完成服務(wù)通信任務(wù)。可以看出Rosie服務(wù)通信機制有效解決了ROS中存在的單點失效問題，在原時間服務(wù)器(ID：3)失效后，可以通過新時間服務(wù)器(ID：1)來完成任務(wù)。

圖6 Rosie服務(wù)通信機制克服單點失效

如表1所示，在ROS通信機制下，重復(fù)實驗中每秒獲取1次時間一共請求10次時間服務(wù)的任務(wù)完成率在訪問觸發(fā)(被訪問之后會隨時失效)的失效機制下只有47.8%，服務(wù)的平均有效時長只有9.942秒。而在Rosie通信機制下，當(dāng)系統(tǒng)中有3個提供相同服務(wù)的服務(wù)端在客戶端需要服務(wù)時同時啟動工作，在訪問觸發(fā)的失效機制下，服務(wù)完成率高達96.4%，服務(wù)的平均有效時長長達30.006秒。即使將失效機制修改為啟動觸發(fā)(啟動之后會隨時失效)，服務(wù)完成率也會高達86.0%，平均有效時長為15.18秒。

表1 不同通信機制的服務(wù)可用性

而在軟件定義的另一個核心特征“管理功能可編程”的實現(xiàn)方面，如圖7所示，自日志 ALL SERVICES SHUTDOWN FOR 5 SECONDS... 之前客戶端最后一次接收到的時間17:40:56到日志ALL SERVICE IS BACK ONLINE. 之后客戶端第一次接收到的時間17:41:04之間相差8秒，排除程序運行和數(shù)據(jù)傳輸?shù)臅r間，可以認(rèn)為該文采用的方案可以滿足軟件定義概念中“管理功能可編程”的核心要求。

圖7 Rosie服務(wù)通信機制中可操作服務(wù)表來控制服務(wù)的可用性

最后，Rosie中關(guān)于服務(wù)表的操作是通過調(diào)用服務(wù)表實現(xiàn)的接口完成，而非將其預(yù)設(shè)為某種擁有特定數(shù)據(jù)結(jié)構(gòu)的容器，核心原因就是貫徹“基礎(chǔ)設(shè)施虛擬化”的軟件定義思想，使服務(wù)表可以根據(jù)不同的情況采用不同的數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)，從而實現(xiàn)性能上的差異化。假設(shè)系統(tǒng)中有n種不同的服務(wù)，而每種服務(wù)由m個服務(wù)端提供服務(wù)。公式(1)～公式(3)表示使用不同數(shù)據(jù)結(jié)構(gòu)實現(xiàn)的服務(wù)表隨著服務(wù)種類n和每個服務(wù)中包含的服務(wù)端數(shù)量m增長時，查詢指定服務(wù)的有效服務(wù)端地址的操作的時間復(fù)雜度。

若基于鏈表實現(xiàn)的服務(wù)表，其可用服務(wù)對象查詢的時間復(fù)雜度為：

TLinkedList(n,m)=n·m=O(nm)

(1)

若基于使用防沖撞鏈的哈希表實現(xiàn)的服務(wù)表，其可用服務(wù)對象查詢的時間復(fù)雜度為：

THashTable(n,m)=1·m=O(m)

(2)

若基于搜索樹實現(xiàn)的服務(wù)表，其可用服務(wù)對象查詢的時間復(fù)雜度為：

TBinarySearchTree(n,m)=log2(n)·m=O(mlog2(n))

(3)

4 未來工作

雖然該模型解決了ROS的服務(wù)通信中所存在的單點失效問題，但在該模型中依然存在很多缺陷：

(1)雖然對服務(wù)表實現(xiàn)了可編程管理并且盡可能降低了可能存在的管理延遲，但是隨著管理節(jié)點增長到一定數(shù)量，可能還是會因為管理時需要獨占服務(wù)表而對整個系統(tǒng)的正常工作產(chǎn)生很大影響，如何解決管理節(jié)點和功能節(jié)點之間共享服務(wù)表的問題還需要深入研究。

(2)雖然模型解決了ROS中服務(wù)通信中服務(wù)端的單點失效問題。但是對于ROS整體框架來說，節(jié)點管理器ROS Master本身也同樣存在單點失效的問題。如何對ROS本身進行去中心化改造是一個需要繼續(xù)深入研究的問題。

(3)目前解決單點失效的問題在于系統(tǒng)中必須有至少一個可用的服務(wù)，若所有的服務(wù)端失效，則服務(wù)依舊不可用。那么如何使用軟件定義的思想進行重新設(shè)計，將系統(tǒng)中可以使用的服務(wù)組合構(gòu)建為已經(jīng)失效的服務(wù)，使其在對客戶端完全透明的條件下，滿足客戶端的服務(wù)請求。

5 結(jié)束語

ROS作為一種基于UNIX系統(tǒng)的開源，分布式的通信框架，已經(jīng)在機器人領(lǐng)域取得了令人矚目的成就。但是其中的服務(wù)通信機制中也存在服務(wù)會單點失效的問題。針對這個問題，提出了一種以軟件定義概念為范式的改進模型Rosie。該服務(wù)通信模型的設(shè)計參考了軟件定義網(wǎng)絡(luò)協(xié)議OpenFlow中使用流表來管理數(shù)據(jù)包轉(zhuǎn)發(fā)行為的核心思想，通過向節(jié)點管理器中加入實現(xiàn)了服務(wù)表接口的容器來管理系統(tǒng)中的服務(wù)端。并且在此基礎(chǔ)上進一步參考了版本管理器的設(shè)計思想，實現(xiàn)了通過拉取，修改和推送的方式來實現(xiàn)服務(wù)表內(nèi)容的可編程修改，從而管理服務(wù)端可用性的設(shè)計?；緷M足了“基礎(chǔ)設(shè)施虛擬化”和“管理功能可編程”這兩項軟件定義概念的核心要求。在設(shè)計的實驗中，該模型表現(xiàn)良好，基本達到了的預(yù)期目標(biāo)。在文章的最后，還根據(jù)當(dāng)前模型所存在的缺陷，提出了一些未來工作的可能方向。