3 月，openEuler 社群推出了一個創新項目，高性能服務治理架構 Kmesh，通過架構創新為服務網格帶來全新的資料面體驗。本文從服務網格講起，帶您一起了解 Kmesh 的前世今生。
目前 Kmesh 項目已經在 openEuler 23.03 版本中釋出，歡迎感興趣的小夥伴下載下傳使用。
「倉庫位址」https://gitee.com/openeuler/Kmesh
什麼是服務網格
服務網格是 2016 年由開發 Linkerd 軟體的 buoyant 公司提出。Willian Morgan（Linkerd 的 CEO）給出了Service Mesh的最初定義：
❝
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
❞
大緻意思為：服務網格（service mesh）是處理服務間通信的基礎設施層。通過網絡代理陣列的形式，為現代雲原生應用提供透明、可靠的網絡通信。
服務網格本質是解決微服務間如何更好通信的問題，通過負載均衡、灰階路由、熔斷限流等治理規則，合理編排流量，實作最大化的叢集服務能力，是服務治理演進的産物；
我們将服務治理的演進過程分為三代，并将其簡單對比；從演進過程可以看出：服務治理能力逐漸從業務中解耦，下沉到基礎設施；
服務網格作為處理服務間通信的基礎設施層，有效彌補了 K8s 在微服務治理方面的短闆，作為雲原生下一代技術，已成為雲上基礎設施的關鍵部件。
作為近年來的風口技術方向，業界誕生了很多服務網格軟體，如：Linkerd、Istio、Consul Connect、Kuma 等；他們在軟體架構上大同小異，以 Istio 為例，展示服務網格的基本架構：
以 k8s 叢集為例，Pod 執行個體建立時，服務網格軟體在 Pod 中透明的建立一個 Proxy 容器（也稱 sidecar，Istio 中預設的 sidecar 軟體是 Envoy）；Pod 通信的基本流程如下：
- 流量通過 iptables 規則透明劫持到 Pod 内的代理元件；
- 代理元件根據請求完成流量治理邏輯（如：熔斷、路由、負載均衡等），找到要通信的對端服務執行個體，并轉發消息；
- 對端 Pod 内的代理元件劫持外部流量，并做基本的流量治理邏輯（如：限流等），再将流量轉發給 Pod；
- Pod 處理完成後，響應封包按原路徑傳回到請求 Pod；
服務網格資料面的問題挑戰
由上文可知，服務網格通過在資料面引入代理層，實作對應用透明的服務治理。然而，這麼做不是毫無代價的，引入的代理層勢必會造成服務通信的時延上升，性能下降。
以 Isito 官網提供的資料為例，叢集規模下，微服務間資料面單跳通信時延增加 2.65ms；要知道微服務叢集下，一次外部通路，在叢集内部往往會經過多次微服務間的調用，網格帶來的時延開銷是很大的；随着服務網格被越來越多應用，代理架構引入的額外時延開銷已成為服務網格面臨的關鍵問題。、
為此，我們測試了 http 服務 L7 負載均衡的場景，對網格資料面的通信做了性能打點，耗時占比如下：
從網格流量的細化分析看，微服務互通，從原來 1 次建鍊變成 3 次建鍊，從原來 2 次進出協定棧，變成 6 次進出協定棧；耗時主要集中在多次的資料拷貝、建鍊通信、上下文排程切換等，真正做流量治理的開銷占比卻不大。
那麼問題來了，能否在保持網格對應用透明治理的前提下，降低網格的時延開銷。
高性能服務網格治理架構 Kmesh
基于以上性能分析，我們針對網格資料面性能做了兩階段的優化。
Kmesh1.0：基于 sockmap 加速網格資料面
sockmap 是 Linux 在 4.14 引入的一個 ebpf 特性，可實作 node 内 socket 間資料流的重定向，而無需經過複雜的核心協定棧，優化鍊路上 socket 間的資料轉發性能；
針對服務網格的場景，Pod 内業務容器與本地代理元件之間預設走了完整的核心協定棧，這段開銷完全可以通過 sockmap 來優化；如下圖所示：
sockmap 加速的基本步驟：
- 建鍊流程中挂載 ebpf 程式（ebpf prog type：BPF_PROG_TYPE_SOCK_OPS），攔截所有的 TCP 建鍊動作；将通信雙方正反兩端的 socket 資訊存儲到 sockmap 表中；
- BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB 狀态添加 client 側 sockmap 記錄；
- BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB 狀态添加 server 側 sockmap 記錄；
- sendmsg 流程中挂載 ebpf 程式（ebpf prog type：BPF_PROG_TYPE_SK_MSG），攔截發送消息的動作；
- 根據目前 socket 資訊查找 sockmap 表，關聯找到對端的 socket 資訊，将流量直接重定向到對端 socket 的接收隊列；
基于 sockmap 加速服務網格資料面，實測 60 長連結場景下，服務通路的平均時延相比原生網格降低了 10%~15%。
sockmap 是目前比較常見的優化服務網格資料面的方案，但從效果看降低 15%的通信延時并沒有真正解決網格時延性能差的問題；
Kmesh2.0：基于可程式設計核心，将流量治理下沉 OS
根據上文的性能打點可知，網格引入的額外開銷中，真正完成流量治理工作的開銷占比并不高，大部分耗時都浪費在了把流量引到代理元件上；那麼，流量治理能不能不要經過這個代理元件，随着流量收發的路徑随路完成呢？網絡通信天然要經過核心協定棧，如果協定棧具備流量治理的能力，是不是就可以解決這個問題了。
Kmesh 就是我們提出的高性能服務治理架構，基于可程式設計核心，将流量治理下沉到 OS，網格資料面不再經過代理元件，服務互通從 3 跳變成 1 跳，真正随路完成治理工作；微服務互通的流量路徑如下所示：
Kmesh 的軟體架構：
Kmesh 的主要部件包括：
- kmesh-controller：kmesh 管理程式，負責 Kmesh 生命周期管理、XDS 協定對接、觀測運維等功能；
- kmesh-api：kmesh 對外提供的 api 接口層，主要包括：xds 轉換後的編排 API、觀測運維通道等；
- kmesh-runtime：kernel 中實作的支援 L3~L7 流量編排的運作時；
- kmesh-orchestration：基于 ebpf 實作 L3~L7 流量編排，如路由、灰階、負載均衡等；
- kmesh-probe：觀測運維探針，提供端到端觀測能力；
我們部署了 Istio 網格環境，通過使用不同的網格資料面軟體（Envoy/Kmesh），針對 http 服務 L7 負載均衡的場景，對網格資料面性能做了對比測試（測試工具：fortio）：
可以看到，基于 Kmesh，網格内服務互通性能相比 Istio 原生資料面（Envoy）有 5 倍提升，同時我們也測試了非網格下，基于 k8s 的服務互通性能，與 Kmesh 的性能資料幾乎相當，進一步佐證了 Kmesh 資料面時延性能。（測試場景為實驗室環境下的 L7 負載均衡，真實治理場景下的性能效果不會這麼理想，初步評估會比 Istio 提升 2~3 倍）
總結
服務網格作為雲原生的下一代技術，為應用提供透明服務治理的同時，因其代理架構引入額外時延開銷，已成為網格應用推廣的關鍵；Kmesh 從 OS 視角，提出了一種基于可程式設計核心的服務治理架構，通過将流量治理能力下沉 OS，大幅提升網格資料面性能，為網格資料面的發展提供了一種全新思路。
Kmesh 作為社群新興項目，目前仍處于起步階段，後續會繼續完善 L4/L7 的流量治理能力；更多内容，請檢視項目首頁：https://gitee.com/openeuler/Kmesh