針對(duì)ROS服務(wù)通信機(jī)制的軟件定義改進(jìn)

李冰鑒，邊 境

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

0 引 言

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

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

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

1 背 景

1.1 軟件定義

軟件定義網(wǎng)絡(luò)起源于2006年斯坦福大學(xué)的Clean Slate研究課題[9]，其項(xiàng)目負(fù)責(zé)人Nick McKeown于2008年發(fā)表文章正式提出軟件定義網(wǎng)絡(luò)的第一個(gè)實(shí)驗(yàn)性協(xié)議OpenFlow[10]。在現(xiàn)存的傳統(tǒng)網(wǎng)絡(luò)中，負(fù)責(zé)轉(zhuǎn)發(fā)數(shù)據(jù)包的交換機(jī)和路由器不僅要負(fù)責(zé)數(shù)據(jù)包的轉(zhuǎn)發(fā)行為，并且還要進(jìn)行制定數(shù)據(jù)包向何處轉(zhuǎn)發(fā)的轉(zhuǎn)發(fā)決策。隨著網(wǎng)絡(luò)規(guī)模不斷擴(kuò)大，交換機(jī)和路由器承擔(dān)的計(jì)算開銷也在不斷加大。為了解決網(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)項(xiàng)目[11]，其成員發(fā)現(xiàn)在開發(fā)機(jī)器人軟硬件系統(tǒng)集成過程中，將各種功能集成在一個(gè)機(jī)器人上非常困難，于是就開始嘗試采用分布式的架構(gòu)來連接不同的功能模塊，而這也是ROS最終采用分布式結(jié)構(gòu)的動(dòng)機(jī)。2007年Morgan Quigley及其導(dǎo)師Andrew Y. Ng在AAAI上發(fā)布了STAIR項(xiàng)目的研究成果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的運(yùn)營下，ROS在近十年先后發(fā)布了若干個(gè)發(fā)行版本，截至目前最新的ROS版本是發(fā)行于2020年的ROS Noetic Ninjemys[15]。

2 架 構(gòu)

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

2.1 整體架構(gòu)

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

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

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

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

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

2.2.1 服務(wù)端虛擬化

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

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

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

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

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

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

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

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

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

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

3 實(shí) 驗(yàn)

3.1 方 案

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

3.2 結(jié)果與分析

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

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

圖6 Rosie服務(wù)通信機(jī)制克服單點(diǎn)失效

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

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

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

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

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

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

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

(1)

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

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

(2)

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

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

(3)

4 未來工作

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

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

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

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

5 結(jié)束語

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