開源 | Service Mesh 數據平面 SOFAMosn 深層揭祕

本文做者：朵曉東，花名奕杉，螞蟻金服高級技術專家，專一雲計算技術及產品。Apache Kylin 創始團隊核心成員，螞蟻金融雲 PaaS 創始團隊核心成員，Antstack 網絡產品負責人，SOFAMesh 創始團隊核心成員。

項目在這裏：https://github.com/alipay/sofa-mosn

本文是基於做者在 Service Mesh Meetup #2 北京的主題分享《螞蟻金服 Service Mesh 數據平面 SOFAMosn 深層解密》部份內容所整理，完整內容見文末的直播回放

前言

今天給你們帶來的分享內容是螞蟻金服 Service Mesh 數據平面 SOFAMosn 深層揭祕。

承接小劍老師在Service Mesh Meetup #1杭州的主題《大規模微服務架構下的 Service Mesh 探索之路》對 SOFAMosn 的分享，本次聚焦在數據平面在螞蟻落地的思考和探索。

背景

上一次分享小劍老師已經介紹了 SOFAMesh 的技術選型，以及咱們在開源和自研方面的一些權衡。

呼應這個話題咱們首先來看一下爲何螞蟻會選擇 Service Mesh

重點概括爲 4 個方面：

螞蟻正在全面擁抱微服務，雲原生，不論是 SOFA5，仍是兼容 K8S 的容器平臺 Sigma 落地，Service Mesh 都是不可獲取的重要組件。

其次，螞蟻的運維體系在服務層面基於流量調度工做，好比說 LDC 架構在邏輯 zone 間的調度流量，再好比彈性伸縮，本質上也是在異構機房間調度流量，此外還有像邏輯 zone 藍綠髮布，機房容災等都須要在流量調度能力上更健壯，更靈活，更具擴展性。

此外，因爲螞蟻的金融屬性，咱們在服務鑑權等方面有更嚴格的要求，好比說國密的落地，加密卡內的證書管理，加解密等方面，不止要求更高的安全級別，還要有承載大流量的能力。同時咱們看到，zero trust網絡架構也在加速發展，這與咱們的訴求不謀而合。

最後，螞蟻內部技術棧多樣，但多種語言體系融合仍然成本很高。

舉個例子，非 SOFA 語言與 SOFA 互通要理解配置中心，SOFARPC 的序列化等邏輯，若是在生產環境部署還要理解 LDC 路由規則，而這些共性需求均可以經過下沉到 Mesh 體系來解決。

瞭解 SOFAMesh 的同窗應該知道，螞蟻選擇了使用 Golang 自研數據平面，作這個決定咱們重點考慮了將來的技術選型，跨團隊研發效率，螞蟻現有技術體系，運維體系等因素；同時經過調研和驗證，Golang 版本的性能也是咱們能夠接受的。

接下來，我會向你們介紹由螞蟻和 UC 聯合研發的 Mesh 數據平面，咱們爲他取名 SOFAMosn

SOFAMesh 的總體架構

你們看到的圖示是基於 Istio 的架構，在數據平面咱們使用 SOFAMosn 替代了 Envoy，同時加入了一些螞蟻實踐中摸索的改進。

0.1.0 版本的 SOFAMosn 支持了 xDS V0.4 api 核心能力，重點支持了 SOFARPC 協議，並在螞蟻內部在生產環境使用；同時支持了HTTP/1.1，HTTP/2.0的基本功能，但目前暫未在生產環境使用。

SOFAMosn 的核心設計思路

首先，將 SOFAMosn 做爲代理處理的數據流劃分爲4層，在入方向數據依次通過網絡 IO 層，二進制協議處理層，協議流程處理層，轉發路由處理層；出向與入向過程基本相反。

瞭解了分層的基本思路，具體介紹一下各層的具體職能：

• IO 層提供了 IO 讀寫的封裝以及可擴展的 IO 事件訂閱機制

• PROTOCOL 層提供了根據不一樣協議對數據進行序列化/反序列化的處理能力

• STREAMING 層提供向上的協議一致性，負責 STREAM 生命週期，管理 Client / Server 模式的請求流行爲，對 Client 端stream 提供池化機制等

• Proxy 層提供路由選擇，負載均衡等的能力，讓先後端 stream 流轉起來。你們能夠從這張圖清晰的看到單向請求流轉的過程。

瞭解了分層設計和轉發流程，咱們再看下線程模型。從 0.1.0 版本的線程模型，能夠看到每一個連接的 IO 協程是成對出現的，讀協程負責讀取，事件機制及 Codec 邏輯，數據上升到 steam 層，具體的 stream 事件由獨立的常駐 worker 協程池負責處理。

在 0.2.0 版本中咱們將會進行多核優化，讀協程將再也不負責 codec 邏輯，將轉發由 codec worker pool 來進行。從發展方向上看，咱們會借鑑 SEDA 的思路，將轉發流程中每一階段的處理抽象爲一個 stage，經過 task queue，worker 協程池，controller 的機制來對每個階段進行處理。從技術實現上看，Golang 實現 SEDA 機制的組件也更簡單。

SOFAMosn 的模塊劃分

除了剛纔介紹了 4 個核心模塊，還有如路由模塊負責請求的路由尋址，後端管理模塊負責管理後端的生命週期，健康度等。其中藍色的框是 SOFAMosn 0.1.0 會涉及到的功能模塊，紅色的虛線框是咱們規劃去實現，或實驗的一些topic。這方面也歡迎你們加入咱們一塊兒來建設。

最後總結一下，模塊化，分層解耦是 SOFAMosn 設計的初衷，此外可編程性，事件機制，擴展性，高吞吐量，都是設計中的重要考量因素。

SOFAMosn 核心能力

介紹完結構設計方面的一些思路，咱們來看看 SOFAMosn 0.1.0 的核心能力。

在網絡核心能力方面，咱們將 IO 處理相關能力封裝抽象成可編程接口，這部分咱們已經作過性能優化，能夠單獨使用；SOFAMosn 提供了內置的 TCP 代理功能，也作過性能優化，可單獨使用；此外 SOFAMosn 支持 TLS 鏈路加密，目前複用了 Golang 的實現，後面的章節會介紹 Golang TLS 性能實驗。SOFAMosn 能夠配合 iptables 透明轉發支持TProxy 模式。同時，MOSN 支持平滑 reload，平滑升級。

在多協議方面，0.1.0 版本中 SOFAMosn 重點支持 SOFARPC，並已運用在螞蟻生產環境中。同時 SOFAMosn 支持HTTP/1.1，HTTP/2.0 的基本功能，實現方式是使用開源的 HTTP/1.1實現 FastHTTP 和 Golang 自帶的 HTTP2 實現。因爲 FastHTTP 和 HTTP2 都自帶了 IO，連接池等功能，因此這兩個協議的支持暫時是脫離 SOFAMosn 總體設計的，性能等方面也尚未作優化，咱們會在後續版本迭代考慮將其歸入到 SOFAMosn 的框架體系，並進行性能優化。此外，咱們正在研發 Dubbo，HSF 的支持，會在後續版本中推出。同時，目前已支持的 SOFARPC，HTTP/1.1，HTTP/2.0 都支持 Mes h間的 TLS 鏈路加密。

此處，在覈心路由方面，0.1.0 版本 SOFAMosn 在覈心功能上對齊 Envoy，支持 virtual host 匹配，支持 route match匹配，支持 subset 路由匹配/負載均衡。

在後端管理功能方面，支持基礎負載均衡算法，支持主動健康檢查等必須功能。

除核心功能外，SOFAMosn 根據咱們落地的一些經驗提供了一些亮點功能。

首先，SOFAMosn 支持 X-PROTOCOL，一種更輕量級的方式支持自定義 RPC 協議，對於無需解包的相對簡單的場景，將 RPC 數據做爲 TCP 或者 HTTP/2.0 的payload 進行轉發，同時支持全部無需解包的路由負載策略。

同時咱們計劃在 X-PROTOCOL 中加入編解碼擴展點，支持須要解包的場景。在平滑升級的支持上，除了經典的傳遞 listener fd+ 協議層等待方式，SOFAMosn 支持對存量連接進行協議無關的遷移。同時爲了部署升級，SOFAMosn 支持指定 / 更新先後端通訊協議。

在 Istio 集成方案上，SOFAMosn 0.1.0 支持 Istio 0.8 版本 Pilot V0.4API 全動態配置運行，支持 xDS on ADS 核心功能，後續版本會不斷補齊功能。SOFAMosn 同時支持靜態配置模型運行。

除了能力支持，SOFAMosn 在網絡層，協議處理層，基於 TCP 的私有協議層都提供了可擴展的能力，使得自定義業務能夠優雅集成。在螞蟻落地的過程當中咱們內部的 SOFAMosn 依賴於開源版本，經過可擴展的方式來實現螞蟻內部的自有業務，在工程落地上提供了可行的方案。

性能

在介紹了核心功能之後，咱們再看另外一個你們很是關注的問題，性能，這也是目前關注度較高的問題之一。

在 SOFAMosn 0.1.0 版本，咱們重點優化了基於 SOFAMosn 總體框架的協議在 Sidecar 模式下單核轉發的性能，即 TCP，SOFARPC 的單核轉發性能。

首先咱們分享一下咱們在單核場景下優化的一些手段和經驗。咱們使用的方式主要是獨佔綁核，內存，IO，調度等方面進行優化。

首先看綁核，在指定 P=1 的狀況下，獨佔綁核不論在系統調用執行效率，cache locality affinity 兩個方面都比更表現更好，總體吞吐量提高大約 30%。其次是內存優化，咱們採樣了 SLAB-style 的回收機制來提升複用，減小內存 copy；

同時在內存分配上須要考慮 Golang 內存模型的親和性，儘可能減小 arena 區內存申請；最後，你們都知道 Golang的 GC 須要是你要去熟悉並適應他的，不少細節須要關注，儘可能減小GC scanobject的壓力。

在 IO 方案，Golang 的 IO 模型是同步化的，在讀方面既要儘量多讀，又要避免頻繁調用 SetReadDeadline 形成的的影響，在咱們壓測下面頻繁調用 SetReadDeadline 會對吞吐量有必定影響。在寫方面須要適度 buffer，例如由多 worker 協程驅動形成某個 IO 協程頻繁寫系統 IO 也會形成吞吐量降低。另外一個須要注意的方面是，在多協程場景下須要避免讀寫頻率不均衡，這也是形成總體吞吐量降低的一個潛在緣由。

另外，若是讀或寫大量觸發，會形成大量系統調用，這會引發 Golang runtime 調度成本升高。在 Golang runtime 調度方面，首先會觸發協程調度形成時間消耗，同時 runtime 調度自己沒有 OS 線程調度靈敏，也會有必定的時間損耗。同時 OS 系統調用自己也有會耗時，會形成性能降低。

這裏我分享一些咱們在性能優化過程當中遇到的真實的 case，除了 IO 方面的思考，還要關注一下調度均衡方面的問題。

首先咱們利用協程池化來避免 runtime.morestack 的問題，其次在單核場景下須要重點關注 G 是否在飢餓狀態，形成資源浪費。

介紹完性能優化的一些過程，咱們來看一下目前咱們在性能優化上的一些結果，即單核 TCP 轉發的性能，和單核SOFARPC 轉發的性能。能夠看到，在單核 TCP 轉發場景，SOFAMosn 0.1.0 版本和 Envoy 1.7版本轉發性能差距可控，後續版本咱們會繼續優化。

此外，前面提到過 TLS 的實現，咱們再來看一下性能方面的一些探索。首先介紹了一下測試的場景。在這個場景下，咱們發現對於 ECDHE 算法，Golang 原生的實現性能雖然低於Ningx（使用 OpenSSL），可是高於 Golang with boring SSL。經過對具體算法和協議的性能壓測，代碼調研咱們得出以下結論。能夠看出對於 ECDHE-P256加密套件，Golang 原生實現的性能是很不錯的，能夠放心使用。

除了這些優化點之後，咱們會在後續版本持續進行性能優化，多核優化，內存優化，同時利用用戶態，內核態的加速技術來提高 SOFAMosn 的轉發性能。在TLS加解密方面，咱們將會嘗試基於本地加速卡和 Keyless 架構的 Offload 加速，這也是咱們在螞蟻網絡從中已經落地的一些技術手段。

RoadMap

最後我介紹一下SOFAMesh 的 RoadMap（時間爲大致範圍，具體發佈請關注本公衆號）：

8月第一週咱們將發佈 SOFAMesh 0.1.0 版本，這個版本重點支持 Proxy 核心能力，支持 xDS V0.4 API 核心功能，支持 SOFARPC 等通訊協議。

8月底咱們將發佈 0.2.0 版本，在不斷完善提高核心能力的基礎上，咱們會完善 X-Protocol 的功能和擴展性，以支持私有 RPC 協議擴展；同時咱們將支持 Dubbo/HSF 通信協議，並接入基於 ZK 的服務註冊中心。同時咱們將重點增強 HTTP/2.0 的功能，性能優化。咱們還將支持 K8S operator，使得 SOFA Mesh 能夠接入 K8S 資源。

除功能性補強之外，咱們會持續優進行性能優化，重點在多核性能，總體內存優化。此外，咱們會持續推動代碼優化，完善測試等基礎性工做。

9月底咱們將發佈 0.3.0，重點提供 Mixer 集成，提供 precondition，quota，report 功能。同時在9月提供熔斷和限流的能力。

目前SOFAMosn仍然是一個初級版本，咱們將持續投入補充，改進，優化，也歡迎開源社區感興趣的朋友一塊兒加入SOFAMesh開源版的建設。

補充

本文基於做者在 Service Mesh Meetup #2 分享的部份內容所整理，現場分享的 PPT 以及視頻，能夠從 https://www.itdks.com/eventlist/detail/2455 觀看

長按關注，獲取最新分佈式架構乾貨

歡迎你們共同打造 SOFAStack https://github.com/alipay