在Linux 系統(tǒng)中， 客觀來說，缺乏相對開發(fā)者比較友好的進程間通信框架。談到Linux上進程間通信，一般都會想起管道（匿名、有名）、信號/信號燈、共享內(nèi)存、消息隊列和socket。這些都是偏低層的技術(shù)，有沒有方便開發(fā)者使用的技術(shù)或者框架呢？軟件總線以及分布式軟總線或許是一種不錯的候選。

Linux 中的進程間通信一瞥

Linux環(huán)境下通信機制眾多，各種通信方式都有其適用的場合。

管道是Linux支持的最初Unix IPC機制之一，是實現(xiàn)方法最簡單的一種通信機制。但是，只能以半雙工的形式在進程間進行通信。

信號是多種通信機制中唯一一種異步方式進行通信的機制。信號方式通信傳輸?shù)臄?shù)據(jù)量較少，側(cè)重于控制進程根據(jù)不同的信號觸發(fā)不同的行為。

消息隊列是在內(nèi)核中開辟的一組鏈表，以隊列的形式接收和發(fā)送信息，適用于傳輸數(shù)據(jù)量較少的場合。消息隊列與管道通信相比，其優(yōu)勢是對每一個消息可以指定特定消息類型，接收的時候不需要按隊列次序，而是可以根據(jù)自定義條件接收特定類型的消息。但在消息信息的發(fā)送進程—操作系統(tǒng)內(nèi)核和內(nèi)核—接收進程間復(fù)制時需要額外占用CPU的時間。

共享內(nèi)存通信機制在進程間可以傳送大量的數(shù)據(jù)，并且由于讀寫進程均將共享內(nèi)存塊視為本進程所有，可直接讀寫，因此傳輸速度最快。但由于多個進程對共享內(nèi)存塊的訪問必須以互斥形式進行，因此還需要信號量機制予以配合。

信號量機制通過信號量值的變化來控制多進程互斥的訪問共享資源，或者協(xié)調(diào)多個進程并發(fā)執(zhí)行的節(jié)奏，并未在進程之間實際的傳輸數(shù)據(jù)。

基于 Socket 的進程間通信機制是現(xiàn)在所有網(wǎng)絡(luò)操作系統(tǒng)必不可少的基礎(chǔ)功能，大多數(shù)現(xiàn)代進程間通信框架都是基于Socket 完成的。

久遠(yuǎn)一點的DCOP

大約從KDE2.0 開始，都包含了非常強大的部件，叫做“Desktop COmmunication Protocol”，簡稱為 DCOP，從開發(fā)者的角度來看，利用 DCOP 可以很方便地將強大的腳本功能添加到應(yīng)用程序中。從用戶的角度來看，利用 DCOP 可以容易地控制 KDE 應(yīng)用程序，并可以將它們以強大而有趣方式組合起來。

就其本質(zhì)而言，DCOP 是一個操作于socket之上的輕量級進程間通信機制，由一個服務(wù)器（即 dcopserver，它在 KDE 啟動時會自動啟動）和任意多個客戶端（支持 DCOP 的應(yīng)用程序）構(gòu)成。DCOP客戶段之間可以通過服務(wù)器互相發(fā)送消息，要求執(zhí)行函數(shù)，等等。

kdebindings 軟件包中含對 Java 的 Qt/KDE 綁定，可以在 Java 中使用 Qt/KDE 類，還包括對 C、Perl、Python 的綁定，也可以在這些語言中使用 DCOP，還包括了 XParts，將非 KDE 應(yīng)用程序作為一個 KPart 嵌入使用。

DCOP 一般用于動態(tài)管理Linux運行時軟件配置框架，一般的Linux軟件在運行時讀取配置文件后，所有的參數(shù)不可再次調(diào)整，而Dcop能夠在啟動軟件后，再次根據(jù)需求去配置軟件各項參數(shù)。

普遍使用的D-Bus

現(xiàn)如今，在Linux 中使用廣泛的D-Bus 又是什么呢？ 

D-Bus是一個有面向?qū)ο蠼涌诘膮f(xié)議框架,以及應(yīng)用程序用戶互相發(fā)現(xiàn)和監(jiān)視的守護進程。也就是說，這是一個進程間的通訊系統(tǒng)，是由兩個守護進程，一個是系統(tǒng)范圍，一個是用戶會話范圍，提供了生命周期內(nèi)的跟蹤、服務(wù)激活、安全檢查等高級功能。這樣的守護進程可以啟動服務(wù)以便給其它程序提供某些功能。D-Bus 可以看作DCOP的升級版，比DCOP要復(fù)雜一些，而且DCOP主要用作桌面應(yīng)用之間的通信。

但是，D-bus 也不是一個普遍適用的通訊系統(tǒng)，這一點和Corba等明顯不同。在設(shè)計之初，D-Bus 設(shè)計被用來作為用戶交互接口與系統(tǒng)服務(wù)之間的解耦和通信，以及系統(tǒng)服務(wù)之間的通信。對于 D-Bus而言，由于不信任對端發(fā)來的數(shù)據(jù)，一定要做復(fù)雜的校驗，導(dǎo)致比直接使用socket讀寫數(shù)據(jù)慢2.5倍，甚至比DCOP乃至Corba等通訊機制都要慢一些。

Corba，又是一個久遠(yuǎn)的存在，20多年前的Corba 實現(xiàn)Orbit都要比D-Bus快，Corba和D-Bus都使用了二機制的通訊協(xié)議，但Corba 更通用和開放。然而，D-Bus很多地方都是硬編碼，所以D-Bus要比Corba簡單得多。

DCOM 是Windows 下的IPC系統(tǒng)，類似于Corba，由于老碼農(nóng)已經(jīng)多年不涉及Windows 平臺的軟件開發(fā)了，也不知道現(xiàn)在發(fā)展到怎樣的程度了。

面向嵌入式的ubus

OpenWrt 提供的ubus，類似于Linux桌面系統(tǒng)的D-Bus，目標(biāo)也是提供系統(tǒng)級的進程間通信功能。在設(shè)計理念上基本一致，但與D-Bus相比減少了內(nèi)存空間的占用，可以更適合嵌入式Linux低內(nèi)存和低CPU性能的特殊環(huán)境。

ubus是OpenWrt的RPC工具大約是在2011年加入OpenWrt中的。為了提供各種后臺進程和應(yīng)用程序之間的通信機制，ubus模塊由3部分組成：

• ubusd精靈進程。
• ubus接口庫
• ubus命令行工具

ubus模塊的核心是ubusd精靈進程，在系統(tǒng)啟動時運行，負(fù)責(zé)進程間的消息路由和傳遞。其他進程注冊到 ubusd進程進行消息的發(fā)送和接收，這個接口是用L文件socket和TLV收發(fā)消息來實現(xiàn)的。每一個進程在指定命名空間下注冊自己的路徑。每一個路徑都可以提供帶有各種參數(shù)的多個函數(shù)處理過程，函數(shù)處理程序可以在完成處理后返回消息。

ubus提供的功能主要有以下4個方面：

• 提供注冊對象和方法供其他實體調(diào)用。
• 調(diào)用其他應(yīng)用程序提供的注冊對象的控制接口。
• 在特定對象上注冊監(jiān)聽事件。
• 向特定對象發(fā)送事件消息。

ubus主要用于兩個進程之間的通信，能夠以JSON格式和用戶進行數(shù)據(jù)交換，不用關(guān)心消息的實際傳輸格式。ubus代碼基于LGPL2.1發(fā)布，在OpenWrt 12.09版開始正式使用。

面向內(nèi)核環(huán)境的KDBUS

kdbus是在內(nèi)核里實現(xiàn)的D-Bus，可傳輸大數(shù)據(jù)塊乃至GB級的消息流，可做到消息傳遞的零拷貝，在最壞情況下，一條消息及其回復(fù)過程不超過2次拷貝，2次驗證和2次上下文切換。全部的憑據(jù)信息（用戶ID，進程ID，cgroup信息，權(quán)限等）隨每個消息傳遞，而且所有消息都有時間戳。

kdbus在內(nèi)核中作為一個字符設(shè)備，先要open設(shè)備，再調(diào)用mmap()將一個消息傳遞區(qū)域映射到自己的地址空間。消息在這個區(qū)域組裝后交給內(nèi)核傳輸，內(nèi)核簡單地將消息從一個進程映射的區(qū)域拷貝到另一個進程的區(qū)域。一般地，kdbus通過memfd機制實現(xiàn)消息傳遞的零拷貝。memfd是一塊帶有文件描述符的內(nèi)存區(qū)域，可以被“密封”，即擁有它的進程不能再改變其內(nèi)容。要傳遞一條消息，進程先在memfd區(qū)域構(gòu)造消息，密封，然后交給kdbus傳輸。內(nèi)核可以把相應(yīng)的內(nèi)存頁面映射到接收進程的地址空間，從而避免拷貝數(shù)據(jù)，這取決于消息的大小。消息比較小時內(nèi)存映射的開銷比較大，這時是直接拷貝數(shù)據(jù)。消息還可以攜帶對收到回復(fù)的時間限制（“方法調(diào)用窗口”）。

由于處于內(nèi)核中，kdbus隨時可用，不需要類似D-Bus那樣的守護進程啟動，Linux安全模塊可以直接與其掛鉤，可避免競態(tài)條件，API也得到了簡化。另外，kdbus信號廣播機制采用布隆過濾器來選擇接受者，也提高了廣播的效率。

遺憾的是， kdbus 曾經(jīng)試圖合入到主流發(fā)行版的內(nèi)核中，但好像沒有成功，前景又讓人有點捉摸不透了。

面向分布式系統(tǒng)的FDBUS

FDBus提供了分布式的進程間通信機制，支持跨主機的C/S通信，使用服務(wù)名而非物理地址作為尋址方式，通過各種服務(wù)和心跳重連機制確保連接的動態(tài)性和可靠性，進而保證系統(tǒng)內(nèi)的節(jié)點可以動態(tài)增刪與部署，可以任意重啟，無需管理啟動順序和依賴，通信各方都能保持連接，從而把各個分立的模塊組成一個牢固的整體。

從進程間通信視角來看，F(xiàn)DBus和的D-Bus類似，但功能更齊全，性能更高，使用更便利，除了支持主機內(nèi)的IPC，還能在多個主機之間組網(wǎng)。FDBus構(gòu)建于socket(Unix和TCP)之上，采用protocol buffer來支持各種復(fù)雜的數(shù)據(jù)類型，也支持raw data格式，便于大量數(shù)據(jù)傳輸。FDBus 采用IDL來定義接口并支持自動代碼生成，大大降低序列化和反序列化工作，而且支持安全策略，對訪問區(qū)劃分了安全等級，確保整個系統(tǒng)的安全性。

FDBus支持字符串形式的名字作為server地址，通過類似DNS作用的name server自動為server分配Unix domain地址和TCP端口號，實現(xiàn)client和server之間以服務(wù)名稱進行尋址。其高性能主要體現(xiàn)在點對點直接通信，不通過中央Hub或Broker進行轉(zhuǎn)發(fā)，目前已經(jīng)在Windows，Linux和QNX上得到了驗證。作為C/S模式，支持如下通信模式：

• 帶超時的同步請求/應(yīng)答
• 帶超時的異步請求/應(yīng)答
• 無應(yīng)答的命令請求
• 訂閱模式，實現(xiàn)多點廣播

FDBus不僅僅是IPC機制，也是一個中間件開發(fā)框架，包含開發(fā)中間件過程中經(jīng)常用到的公共組件和基礎(chǔ)模型，提供了跨平臺且功能強大的支持。源碼開放之后，F(xiàn)DBus經(jīng)過更多開發(fā)者的使用、測試和改進，逐漸成為眾多中間件開發(fā)框架的候選之一。

xBus 與軟件總線

除了早期的DCOP，上面的幾種進程間通信機制都命名為xBus，為啥呢？在計算機領(lǐng)域，Bus 一詞最早出現(xiàn)在硬件架構(gòu)中， 代表總線，是一組能為多個部件分時共享的公共信息傳送線路。

從總線所處的位置來看，分為片內(nèi)總線和片外總線。片內(nèi)總線是CPU內(nèi)部的寄存器、算術(shù)邏輯部件、控制部件以及總線接口部件之間的公共信息通道，片外總線則泛指CPU與外部器件之間的公共信息通道，我們談到的總線一般指的是片外總線。

從總線傳輸方式的設(shè)計視角來看，計算機總線有串行總線和并行總線，可以由一個或多個通道組成，每個通道是單線連接，數(shù)據(jù)的傳輸方式將根據(jù)通道的數(shù)量而有所不同。

從通信用途的視角來看，總線又可以分為3種：地址總線、數(shù)據(jù)總線、控制總線。地址總線用于指定CPU將要操作的內(nèi)存地址；數(shù)據(jù)總線用于讀寫內(nèi)存的數(shù)據(jù)，控制總線用于發(fā)送和接受信號，比如中斷、設(shè)備復(fù)位等信號，CPU收到信號后進行響應(yīng)，這時則需要控制總線。

在CPU、內(nèi)存與外設(shè)確定的情況下，計算機的總線速度是制約計算機整體性能的關(guān)鍵。

計算機的軟件總線是一種虛擬的存在，它是在計算機硬件總線的功能含義類比的基礎(chǔ)上得到的定義。軟件總線是軟件工程人員為了進一步保證軟件系統(tǒng)建設(shè)的規(guī)范性，以及提高計算機系統(tǒng)的應(yīng)用價值而提出的一種設(shè)計理念。軟件總線可以將各種軟件進行相互連接，組成一個通用的操作平臺，通常表現(xiàn)為一個接口界面。作為一種軟件模塊，軟件總線為各個軟件組成部分進行準(zhǔn)確的數(shù)據(jù)傳輸，同時為各種軟件提供虛擬共享的通道和接口。

軟件總線源于分布式異構(gòu)環(huán)境的搭建所提出的，軟件復(fù)用、構(gòu)件化以及面向?qū)ο蠹夹g(shù)的發(fā)展促進了它的形成。軟件總線只是對軟件的構(gòu)件進行組裝而不是更改，這不僅有效的提高了軟件開發(fā)的工作效率，縮短了軟件開發(fā)的周期。前面提到的各種xBus，都可以看作軟件總線的一種實現(xiàn)。

HarmonyOS的分布式軟總線

鴻蒙的分布式軟總線是為了解決所有1+8+N設(shè)備之間的互聯(lián)互通問題，在華為提出的1+8+N中：1指的是手機，8指的是車機、音箱、耳機、手表/手環(huán)、平板、大屏、PC、AR/VR，N指的是其他IOT設(shè)備。一般情況下，用戶都是通過手動操作的方式進行設(shè)備之間的連接，隨著外圍設(shè)備越來越多，手動操作的方式不方便，甚至?xí)绊懹脩舻捏w驗。HarmonyOS的分布式總線技術(shù)是為了能夠讓所有的設(shè)備之間能夠方便、高效的互聯(lián)。

HarmonyOS分布式軟總線最主要的功能包括：發(fā)現(xiàn)、連接、組網(wǎng)/拓?fù)涔芾?、任?wù)總線、數(shù)據(jù)總線。其中，”發(fā)現(xiàn)”指的是搜索周圍是否有相關(guān)設(shè)備；”連接”指的是與所發(fā)現(xiàn)的設(shè)備建立連接；”組網(wǎng)/拓?fù)涔芾怼敝傅氖菍λ邪l(fā)現(xiàn)的設(shè)備進行網(wǎng)絡(luò)拓?fù)涔芾恚热缃M成星狀網(wǎng)絡(luò)拓?fù)?，或者是組成Mesh網(wǎng)絡(luò)拓?fù)?。”任?wù)總線”指的是在所建立的網(wǎng)絡(luò)拓?fù)浠A(chǔ)上，用于傳輸小數(shù)據(jù)量信息的通路。”數(shù)據(jù)總線”指的是用于傳輸較大數(shù)據(jù)量信息的通路。發(fā)現(xiàn)與組網(wǎng)是分布式軟總線的核心術(shù)，目前沒有開到公開的細(xì)節(jié)信息。

把眾多外圍設(shè)備連接形成網(wǎng)絡(luò)后，需要保證各個設(shè)備在時間上的同步。尤其是IoT設(shè)備，由于成本方面的原因，晶振的質(zhì)量可能比較差，會存在相對較大的頻率漂移。分布式軟總線關(guān)鍵技術(shù)之一是時鐘同步算法，將不同設(shè)備原本不同步的時鐘做到統(tǒng)一同步。在軟時鐘算法的同步下，就可以進行資源的調(diào)度。軟總線技術(shù)中提出了LaneHub的概念，可以理解為調(diào)度管理各通信通路的模塊。通過軟總線的LaneHub可以對這不同連接方式的設(shè)備進行統(tǒng)一調(diào)度，達(dá)到減少干擾、提升速率的目的。

在分布式軟總線的基礎(chǔ)上，華為提出了”超級終端”的概念，就是通過分布式軟總線技術(shù)將手機外圍的其他相關(guān)設(shè)備連接在一起，形成了所謂的”超級終端”，即個體終端變成了群體終端。

一句話小結(jié)

盡管“一切程序都會歸于系統(tǒng)調(diào)用”，但軟件工程的效率提升是業(yè)界不變的追求，從進程間通信到分布式軟總線也是如此，或許，基于FDBUS就可以相對容易地開發(fā)出類似HarmonyOS的分布式軟總線呢。

【參考資料】

• https://gitee.com/Janisa/Dcop/
• http://dbus.freedesktop.org/doc/dbus-faq.html
• https://github.com/skawu/fdbus
• https://git.openwrt.org/project/ubus.git
• https://developer.harmonyos.com/
• https://www.bilibili.com/video/BV16b4y1h75z?spm_id_from=333.999.0.0