簡介

CloudWeGo - Shmipc 是字節(jié)跳動服務(wù)框架團隊研發(fā)的高性能進(jìn)程間通訊庫，它基于共享內(nèi)存構(gòu)建，具有零拷貝的特點，同時它引入的同步機制具有批量收割 IO 的能力，相對于其他進(jìn)程間通訊方式能明顯提升性能。在字節(jié)內(nèi)部，Shmipc 應(yīng)用于 Service Mesh 場景下，mesh proxy 進(jìn)程與業(yè)務(wù)邏輯進(jìn)程、與通用 sidecar 進(jìn)程的通訊， 在大包場景和 IO 密集型場景能夠取得顯著的性能收益。

開源社區(qū)關(guān)于這方面的資料不多，Shmipc 的開源希望能為社區(qū)貢獻(xiàn)一份力量，提供一份參考。本文主要介紹 Shmipc 的一些主要的設(shè)計思路以及后續(xù)的演進(jìn)規(guī)劃。?

go 版本實現(xiàn)：

??https://github.com/cloudwego/shmipc-go??

設(shè)計細(xì)節(jié)：

??https://github.com/cloudwego/shmipc-spec???

項目背景

在字節(jié)，Service Mesh 在落地的過程中進(jìn)行了大量的性能優(yōu)化工作，其中 Service Mesh 的流量劫持是通過，mesh proxy 與微服務(wù)框架約定的地址進(jìn)行進(jìn)程間通訊來完成，性能會優(yōu)于開源方案中的 iptables。但常規(guī)的優(yōu)化手段已不能帶來明顯的性能提升。于是我們把目光放到了進(jìn)程間通訊上，Shmipc 由此誕生。

設(shè)計思路

零拷貝

在生產(chǎn)環(huán)境中比較廣泛使用的進(jìn)程間通訊方式是 unix domain socket 與 TCP loopback（localhost:$PORT），兩者從 benchmark 看性能差異不大。從技術(shù)細(xì)節(jié)看，都需要將通訊的數(shù)據(jù)在用戶態(tài)和內(nèi)核態(tài)之間進(jìn)行拷貝。在 RPC場景下，一次 RPC 流程中在進(jìn)程間通訊上會有四次的內(nèi)存拷貝，Request 路徑兩次， Response 路徑兩次。

雖然現(xiàn)代 CPU 上進(jìn)行順序的 copy 非?？欤绻覀兡軌蛳@多達(dá)四次的內(nèi)存拷貝，在大包場景下也能在一定程度上節(jié)省 CPU 使用。而基于共享內(nèi)存通訊零拷貝的特性，我們可以很容易達(dá)成這一點。但為了達(dá)到零拷貝的效果，圍繞共享內(nèi)存本身，還會產(chǎn)生有許多額外的工作，比如：

1. 深入微服務(wù)框架的序列化與反序列化。我們希望當(dāng) Request 或 Response 序列化完成時，對應(yīng)的二進(jìn)制數(shù)據(jù)已經(jīng)存在共享內(nèi)存中。而不是序列化到一塊非共享內(nèi)存的 buffer 中，然后再拷貝到共享內(nèi)存 buffer。
2. 實現(xiàn)一種進(jìn)程同步機制。當(dāng)一個進(jìn)程把數(shù)據(jù)寫入共享內(nèi)存后，另外一個進(jìn)程并不知道，因此需要同步機制進(jìn)行通知。
3. 高效的內(nèi)存分配和回收。保證跨進(jìn)程的共享內(nèi)存的分配和回收機制的開銷足夠低，避免其掩蓋零拷貝的特性帶來的收益。

同步機制

分場景考慮：

1. 按需實時同步。適用于在線場景，對時延極其敏感，每次寫入操作完成后都通知對端進(jìn)程。Linux 下，可做選擇的比較多，TCP loopback、unix domain socket、event fd 等。event fd的 benchmark 性能會略好，但跨進(jìn)程傳遞 fd 會引入過多復(fù)雜性，其帶來的性能提升在 IPC 上不太明顯，復(fù)雜性與性能中間的權(quán)衡需要慎重考慮。在字節(jié)，我們選擇了 unix domain socket 來進(jìn)行進(jìn)程同步。
2. 定時同步。適用于離線場景，對時延不敏感。通過高間隔的 sleep 訪問共享內(nèi)存中自定義的標(biāo)志位來鑒別是否有數(shù)據(jù)寫入。但注意 sleep 本身也需要系統(tǒng)調(diào)用，開銷大于 unix domain socket 的讀寫。
3. 輪詢同步。適用于時延非常敏感，CPU不那么敏感的場景?？梢酝ㄟ^單核輪詢共享內(nèi)存中的自定義標(biāo)志位來完成。

總的來說按需實時同步和定期同步需要系統(tǒng)調(diào)用來完成，輪詢同步不需要系統(tǒng)調(diào)用，但需要常態(tài)跑滿一個 CPU 核心。

批量收割 IO

在線場景中按需實時同步，每次數(shù)據(jù)寫入都需要進(jìn)行一次進(jìn)行進(jìn)程同步（下圖中的4），雖然延遲問題解決了，但在性能上，需要交互的數(shù)據(jù)包需要大于一個比較大的閾值，零拷貝帶來的收益才能突顯。因此在共享內(nèi)存中構(gòu)造了一個 IO 隊列的來完成批量收割 IO，使其在小包 IO 密集場景也能顯現(xiàn)收益。核心思想是：當(dāng)一個進(jìn)程把請求寫入 IO隊列后，會給另外一個進(jìn)程發(fā)通知來處理。那么在下一個請求進(jìn)來時（對應(yīng)下圖中的 IOEvent 2~N，一個 IOEvent 可以獨立描述一個請求在共享內(nèi)存中的位置），如果對端進(jìn)程還在處理 IO 隊列中的請求，那么就不必進(jìn)行通知。因此，IO越密集，批處理效果就越好。

另外就是離線場景中，定時同步本身就是批量處理 IO 的，批處理的效果能夠有效減少進(jìn)程同步帶來的系統(tǒng)調(diào)用，sleep 間隔越高，進(jìn)程同步的開銷就越低。

對于輪詢同步則不需要考慮批量收割 IO，因為這個機制本身是為了減少進(jìn)程同步開銷。而輪詢同步直接占滿一個 CPU 核心，相當(dāng)于默認(rèn)把同步機制的開銷拉滿以獲取極低的同步延遲。

性能收益

Benchmark

其中X 軸為數(shù)據(jù)包大小，Y軸為一次 Ping-Pong 的耗時，單位為微秒，越小越好?？梢钥吹皆谛“鼒鼍跋?，Shmipc 相對于 unix domain socket 也能獲得一些收益，并且隨著包大小越大性能越好。

數(shù)據(jù)源：??git clone https://github.com/cloudwego/shmipc-go && go test -bench=BenchmarkParallelPingPong -run BenchmarkParallelPingPong??

生產(chǎn)環(huán)境

在字節(jié)生產(chǎn)環(huán)境的 Service Mesh 生態(tài)中，我們在 3000+ 服務(wù)、100w+ 實例上應(yīng)用了 Shmipc。不同的業(yè)務(wù)場景顯現(xiàn)出不同的收益，其中收益最高的風(fēng)控 業(yè)務(wù)降低了整體24%的資源使用，當(dāng)然也有無明顯收益的甚至劣化的場景出現(xiàn)。但在大包和 IO 密集型場景均能顯現(xiàn)出顯著收益。

采坑記錄

在字節(jié)實際落地的過程中我們也踩了一些坑，導(dǎo)致一些線上事故，比較具有參考價值。

1. 共享內(nèi)存泄漏。IPC 過程共享內(nèi)存分配和回收涉及到兩個進(jìn)程，稍有不慎就容易發(fā)生共享內(nèi)存的泄漏。問題雖然非常棘手，但只要能夠做到泄漏時主動發(fā)現(xiàn)，以及泄漏之后有觀測手段可以排查即可。

1. 主動發(fā)現(xiàn)?？梢酝ㄟ^增加一些統(tǒng)計信息然后匯總到監(jiān)控系統(tǒng)來做到主動發(fā)現(xiàn)，比如總分配和總回收的內(nèi)存大小。
2. 觀測手段。在設(shè)計共享內(nèi)存的布局時增加一些元信息，使得在發(fā)生泄漏之后，我們可以通過內(nèi)置的 debug 工具dump 泄漏時刻的共享內(nèi)存來進(jìn)行分析。能夠知道所泄漏的內(nèi)存有多少，里面的內(nèi)容是什么，以及和這部分內(nèi)容相關(guān)的一些元信息。

2. 串包。串包是最頭疼的問題，出現(xiàn)的原因是千奇百怪的，往往造成嚴(yán)重后果。我們曾在某業(yè)務(wù)上發(fā)生串包事故，出現(xiàn)的原因是因為大包導(dǎo)致共享內(nèi)存耗盡，fallback 到常規(guī)路徑的過程中設(shè)計存在缺陷，小概率出現(xiàn)串包。排查過程和原因并不具備共性，可以提供更多的參考是增加更多場景的集成測試和單元測試將串包扼殺在搖籃中。
3. 共享內(nèi)存踩踏。應(yīng)該盡可能使用 memfd 來共享內(nèi)存，而不是 mmap 文件系統(tǒng)中的某個路徑。早期我們通過 mmap 文件系統(tǒng)的路徑來共享內(nèi)存，Shmipc 的開啟和共享內(nèi)存的路徑由環(huán)境變量指定，啟動過程由引導(dǎo)進(jìn)程注入應(yīng)用進(jìn)程。那么存在一種情況是應(yīng)用進(jìn)程可能會 fork 出一個進(jìn)程，該進(jìn)程繼承了應(yīng)用進(jìn)程的環(huán)境變量并且也集成了 Shmipc，然后 fork 的進(jìn)程和應(yīng)用進(jìn)程 mmap 了同一塊共享內(nèi)存，發(fā)現(xiàn)踩踏。在字節(jié)的事故場景是應(yīng)用進(jìn)程使用了 golang 的 plugin 機制從外部加載 .so 來運行，該 .so 集成了 Shmipc，并且跑在應(yīng)用進(jìn)程里，能看到所有環(huán)境變量，于是就和應(yīng)用進(jìn)程 mmap 了同一片共享內(nèi)存，運行過程發(fā)生未定義行為。
4. Sigbus coredump。早期我們通過 mmap /dev/shm/路徑（tmpfs）下的文件來共享內(nèi)存，應(yīng)用服務(wù)大都運行在 docker 容器實例中。容器實例對 tmpfs 有容量限制（可以通過 df -h 觀測），這會使得 mmap 的共享內(nèi)存如果超過該限制就會出現(xiàn) Sigbus，并且 mmap 本身不會有任何報錯，但在運行期，使用到超過限制的地址空間時才會出現(xiàn) Sigbus 導(dǎo)致應(yīng)用進(jìn)程崩潰。解決方式和第三點一樣，使用 memfd 來共享內(nèi)存。

后續(xù)演進(jìn)

1. 整合至微服務(wù) RPC 框架 CloudWeGo/Kitex。
2. 整合至微服務(wù) HTTP 框架 CloudWeGo/Hertz。
3. 開源 Rust 版本的 Shmipc 并整合至 Rust RPC 框架 CloudWeGo/Volo。
4. 開源 C++ 版本的 Shmipc。
5. 引入定時同步機制適用于離線場景。
6. 引入輪詢同步的同步機制適用于對延遲有極致要求的場景。
7. 賦能其他 IPC 場景， 比如 Log SDK 與 Log Agent， Metrics SDK 與 Metrics Agent 等。

總結(jié)

希望本文能讓大家對于 Shmipc 有一個初步的了解，知曉其設(shè)計原理，更多實現(xiàn)細(xì)節(jié)以及使用方法請參考文章開頭給出的項目地址。歡迎各位感興趣的同學(xué)向 Shmipc 項目提交 Issue 和 PR，共同建設(shè) CloudWeGo 開源社區(qū)，也期望 Shmipc 在 IPC 領(lǐng)域助力越來越多開發(fā)者和企業(yè)構(gòu)建高性能云原生架構(gòu)。