[[406368]]

想了解更多內(nèi)容，請?jiān)L問：

51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)

https://harmonyos.51cto.com

5. 面向服務(wù)架構(gòu)的實(shí)現(xiàn)

SOA(service-oriented architectur，面向服務(wù)的架構(gòu)是一種軟件架構(gòu)或者軟件模型，這種架構(gòu)下，系統(tǒng)提供的各種功能都會以服務(wù)的形式，提供給用戶或者系統(tǒng)內(nèi)外的其它服務(wù)來使用，服務(wù)與服務(wù)之間是松耦合的關(guān)系，互相之間使用中立的接口和標(biāo)準(zhǔn)的方式進(jìn)行通信和交互，與硬件平臺、操作系統(tǒng)、編程語言沒有相關(guān)性。這種架構(gòu)特別適合在分布式的環(huán)境中使用，鴻蒙系統(tǒng)就是一個分布式的操作系統(tǒng)，自然采用了這種架構(gòu)。【更多的SOA相關(guān)信息，請自行網(wǎng)上搜索學(xué)習(xí)?！?/p>

面向服務(wù)的架構(gòu)，包括下面三種角色：

• Provider：服務(wù)的提供者，為系統(tǒng)提供能力(即對外接口)，它接受和執(zhí)行來自消費(fèi)者的請求。

它將自己的服務(wù)和接口發(fā)布到服務(wù)管理中心，以便服務(wù)的消費(fèi)者可以發(fā)現(xiàn)和訪問該服務(wù)。

• Consumer：服務(wù)的消費(fèi)者，調(diào)用服務(wù)提供的功能(即對外接口)來實(shí)現(xiàn)某種結(jié)果。

它可以是一個應(yīng)用程序、一個軟件模塊或者另一個服務(wù)，它發(fā)起對服務(wù)管理中心的服務(wù)查詢、綁定服務(wù)， 然后執(zhí)行服務(wù)提供的能力。

• Samgr：服務(wù)管理中心是一個中介者，它管理著Provider提供的能力，同時幫助Consumer發(fā)現(xiàn)Provider的能力。

它們的關(guān)系如下圖所示：

前文《系統(tǒng)服務(wù)框架子系統(tǒng)-2》4.6 小節(jié)對PubSubFeature 和PubSubImplement結(jié)構(gòu)體的分析，提到了它們是SOA(面向服務(wù)的架構(gòu))的實(shí)現(xiàn)，本節(jié)我們就來具體分析一下。

代碼結(jié)構(gòu)為 Hi3861/distributedschedule/samgr_lite/communication/

我們還是先對PubSubFeature 和PubSubImplement結(jié)構(gòu)體做比較完整的展開，如下圖：

兩個全局變量g_pubSubImplement和g_broadcastFeature也分別展開：

• g_pubSubImplement 的展開

如前文《系統(tǒng)服務(wù)框架子系統(tǒng)-2》“4.7 IUnknown 接口類及其相關(guān)定義” 所分析的，任何應(yīng)用或者其他模塊通過：

IUnknown *iUnknown = SAMGR_GetInstance()->GetFeatureApi(BROADCAST_SERVICE, PUB_SUB_FEATURE); 

就可以拿到上面的iUnknown的指針了，拿到這個指針后，就可以再通過：

PubSubInterface *fapi = NULL; 
iUnknown->QueryInterface(iUnknown, DEFAULT_VERSION, (void **)&fapi); 

 來恢復(fù)出PubSubInterface 對象的指針fapi，也就可以訪問 subscriber和provider的API了。

• g_broadcastFeature的展開

這里的重點(diǎn)是relations這個雙重的雙向鏈表及其node上所掛載的東西，注意，上圖的head node和tail node的指針會互相指向?qū)Ψ剑纬砷]環(huán)，這里沒有畫出來。

g_pubSubImplement 主要是提供一組統(tǒng)一的標(biāo)準(zhǔn)的對外的接口，外部程序可以通過這組接口來:

• 為Consumer訂閱(Subscribe) Topic
• 為Provider 發(fā)布(Publish) Topic

當(dāng)某個Consumer[i]要訂閱某個Topic[x]的時候，首先需要通過AddTopic(Topic[x])將Topic[x]添加到relations鏈表中去，添加的時候會做檢查和判斷，確保Topic[x]不會在relations鏈表上重復(fù)添加。然后再通過Subscribe(Topic[x]， Consumer[i])來訂閱Topic[x]，實(shí)際上就是把Consumer[i]添加到Topic[x]的雙線鏈表中去，以獲得對Topic[x]的訂閱權(quán)限。

當(dāng)某個Provider Publish一個Topic[x]的時候，Broadcast 的這個PubSubFeature會從relations鏈表中找到對應(yīng)的Topic[x]，對其所有訂閱者發(fā)起廣播(也就是遍歷Topic[x]的ConsumerNode鏈表，對鏈表上所有的consumer節(jié)點(diǎn)發(fā)送消息，讓它們對消息進(jìn)行處理)。

簡單來說，g_pubSubImplement和g_broadcastFeature這兩個全局變量，g_broadcastFeatur提供了feature的生命周期和數(shù)據(jù)結(jié)構(gòu)，g_pubSubImplemen則提供了對外接口和對數(shù)據(jù)結(jié)構(gòu)的操作。具體他們是如何配合工作的，請自行閱讀broadcast目錄下的代碼。

附件包含兩個測試程序，分別是broadcast_example和user_button_test，以及它們跑起來的log，感興趣的朋友請自行編譯和做驗(yàn)證。

• broadcast_example

以官方的samgr例程為樣本，框架是一樣的，跑的內(nèi)容做了一些修改，按照我的習(xí)慣對log做了整理，基 本上相當(dāng)于重寫了這個測試用例。

以CASE_AddAndUnsubscribeTopic()為例，我添加了4個Topic，三個Consumer對Topic的訂閱情況如下表:

當(dāng)某個Topic[x] 發(fā)布的時候，只有訂閱了它的Consumer會做出反應(yīng)，Consumer會調(diào)用callback函數(shù)對Topic[x]的request做出針對性的處理。

• user_button_test

我自己寫的Provider測試程序，Hi3861開發(fā)板響應(yīng)user按鍵消息，每次按鍵事件觸發(fā)一次 Publish 一個隨機(jī)的 topic，以此檢驗(yàn)上表中的Consumer對各自訂閱的Topic的處理情況。

按鍵線程 UserButtonTask 每1s循環(huán)一次，計(jì)數(shù)器++，檢測到按鍵按下時，當(dāng)前計(jì)數(shù)器%5, 得到 0~4 的一個隨機(jī)數(shù)字，這個數(shù)字就是 topic，上表中只添加了topic[0~3]，當(dāng)UserButtonTask publish topic[4]時，就會出現(xiàn)異常，請查閱附件的log就知道是怎樣的了。

文章相關(guān)附件可以點(diǎn)擊下面的原文鏈接前往下載

原文鏈接：https://harmonyos.51cto.com/posts/4776

想了解更多內(nèi)容，請?jiān)L問：

51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)

https://harmonyos.51cto.com