2018年上半年，螞蟻金服決定基於 Istio 訂製自己的 ServiceMesh 解決方案，並在6月底正式對外公佈了 SOFAMesh，詳情可直接點選之前的文章檢視:大規模微服務架構下的Service Mesh探索之路 。 在 SOFAMesh 的開發過程中，針對遇到的實際問題，我們給出了一套名為 x-protocol 的解決方案，本文將會對這個解決方案進行詳細的講解，後面會有更多內容，歡迎持續關注本系列文章。 上一篇：SOFAMesh中的多協議通用解決方案x-protocol介紹系列(1) ： DNS通用定址方案 前言 在 Istio 和 Envoy 中，對通訊協議的支援，主要體現在 HTTP/1.1和 HTTP/2上，而我們 SOFAMesh，則需要支援以下幾個 RPC 協議： SOFARPC：這是螞蟻金服大量使用的RPC協議（已開源） HSF RPC：這是阿里集團內部大量使用的RPC協議（未開源） Dubbo RPC: 這是社群廣泛使用的RPC協議（已開源） 更適合的平衡點：效能和功能 對於服務間通訊解決方案，效能永遠是一個值得關注的點。而 SOFAMesh 在專案啟動時就明確要求在效能上要有更高的追求，為此，我們不得不在 Istio 標準實現之外尋求可以獲取更高效能的方式，比如支援各種 RPC 協議。 期間有兩個發現： 1.Istio 在處理所有的請求轉發如 REST/gRPC 時，會解碼整個請求的 header 資訊，拿到各種資料，提取為 Attribute，然後以此為基礎，提供各種豐富的功能，典型如 Content Based Routing。 2.而在測試中，我們發現：解碼請求協議的 header 部分，對 CPU 消耗較大，直接影響效能。 因此，我們有了一個很簡單的想法：是不是可以在轉發時，不開啟部分功能，以此換取轉發過程中的更少更快的解碼消耗？畢竟，不是每個服務都需要用到 Content Based Routing 這樣的高階特性，大部分服務只使用 Version Based Routing，尤其是使用 RPC 通訊協議的服務，沒有HTTP那麼表現力豐富的 header，對 Content Based Routing 的需求要低很多。 此外，對於部分對效能有極高追求的服務，不開啟高階特性而換取更高的效能，也是一種滿足效能要求的折中方案。考慮到系統中總存在個別服務對效能非常敏感，我們覺得 Service Mesh 提供一種效能可以接近直連的方案會是一個有益的補充。為了滿足這些特例而不至於因此整體否決 Service Mesh 方案，我們需要在 Service Mesh 的大框架下提供一個折中方案。
請求轉發

在我們進一步深入前，我們先來探討一下實現請求轉發的技術細節。 有一個關鍵問題：當 Envoy/SOFA MOSN 這樣的代理程式，接收到來自客戶端的TCP 請求時，需要獲得哪些資訊，才可以正確的轉發請求到上游的伺服器端？ 最關鍵的資訊：destination 首先，毫無疑問的，必須拿到 destination 目的地，也就是客戶端請求必須通過某種方式明確的告之代理該請求的 destination，這樣代理程式才能根據這個 destionation去找到正確的目標伺服器，然後才有後續的連線目標伺服器和轉發請求等操作。 Destination 資訊的表述形式可能有： 1.IP地址 可能是伺服器端例項實際工作的 IP 地址和埠，也可能是某種轉發機制，如Nginx/HAProxy 等反向代理的地址或者 Kubernetes 中的 ClusterIP。
舉例：“192.168.1.1:8080”是實際IP地址和埠，“10.2.0.100:80”是 ngxin 反向代理地址，“172.168.1.105:80”是Kubernetes的ClusterIP。 2.目標服務的識別符號

可用於名字查詢，如服務名，可能帶有各種字首字尾。然後通過名字查詢/服務發現等方式，得到地址列表（通常是IP地址+埠形式）。 舉例：“userservice”是標準服務名， “com.alipay/userservice”是加了域名字首的服務名， “service.default.svc.cluster.local”是k8s下完整的全限定名。 Destination資訊在請求報文中的攜帶方式有： 1.通過通訊協議傳遞 這是最常見的形式，標準做法是通過header頭，典型如HTTP/1.1下一般使用 host header，舉例如“Host: userservice”。HTTP/2下，類似的使用“:authority” header。 對於非HTTP協議，通常也會有類似的設計，通過協議中某些欄位來承載目標地址資訊，只是不同協議中這個欄位的名字各有不同。如SOFARPC，HSF等。 有些通訊協議，可能會將這個資訊存放在payload中，比如後面我們會介紹到的dubbo協議，導致需要反序列化payload之後才能拿到這個重要資訊。
2.通過TCP協議傳遞 這是一種非常特殊的方式，通過在TCP option傳遞，上一節中我們介紹Istio DNS定址時已經詳細介紹過了。 TCP拆包 如何從請求的通訊協議中獲取destination？這涉及到具體通訊協議的解碼，其中第一個要解決的問題就是如何在連續的TCP報文中將每個請求內容拆分開，這裡就涉及到經典的TCP沾包、拆包問題。 轉發請求時，由於涉及到負載均衡，我們需要將請求傳送給多個伺服器端例項。因此，有一個非常明確的要求：就是必須以單個請求為單位進行轉發。即單個請求必須完整的轉發給某臺伺服器端例項，負載均衡需要以請求為單位，不能將一個請求的多個報文包分別轉發到不同的伺服器端例項。所以，拆包是請求轉發的必備基礎。 由於篇幅和主題限制，我們不在這裡展開TCP沾包、拆包的原理。後面針對每個具體的通訊協議進行分析時再具體看各個協議的解決方案。 多路複用的關鍵引數：RequestId RequestId用來關聯request和對應的response，請求報文中攜帶一個唯一的id值，應答報文中原值返回，以便在處理response時可以找到對應的request。當然在不同協議中，這個引數的名字可能不同（如streamid等）。 嚴格說，RequestId對於請求轉發是可選的，也有很多通訊協議不提供支援，比如經典的HTTP1.1就沒有支援。但是如果有這個引數，則可以實現多路複用，從而可以大幅度提高TCP連線的使用效率，避免出現大量連線。稍微新一點的通訊協議，基本都會原生支援這個特性，比如SOFARPC、Dubbo、HSF，還有HTTP/2就直接內建了多路複用的支援。 HTTP/1.1不支援多路複用（http1.1有提過支援冪等方法的pipeline機制但是未能普及），用的是經典的ping-pong模式：在請求傳送之後，必須獨佔當前連線，等待伺服器端給出這個請求的應答，然後才能釋放連線。因此HTTP/1.1下，併發多個請求就必須採用多連線，為了提升效能通常會使用長連線+連線池的設計。而如果有了requestid和多路複用的支援，客戶端和Mesh之間理論上就可以只用一條連線（實踐中可能會選擇建立多條）來支援併發請求： 而Mesh與伺服器（也可能是對端的Mesh）之間，也同樣可以受益於多路複用技術，來自不同客戶端而去往同一個目的地的請求可以混雜在同一條連線上傳送。通過RequestId的關聯，Mesh可以正確將reponse傳送到請求來自的客戶端。 由於篇幅和主題限制，我們不在這裡展開多路複用的原理。後面針對每個具體的通訊協議進行分析時再具體看各個協議的支援情況。 請求轉發引數總結 上面的分析中，我們可以總結到，對於Sidecar，要正確轉發請求： 必須獲取到destination資訊，得到轉發的目的地，才能進行服務發現類的定址 必須要能夠正確的拆包，然後以請求為單位進行轉發，這是負載均衡的基礎 可選的RequestId，這是開啟多路複用的基礎 因此，這裡我們的第一個優化思路就出來了：儘量只解碼獲取這三個資訊，滿足轉發的基本要求。其他資訊如果有效能開銷則跳過解碼，所謂“快速解碼轉發”。基本原理就是犧牲資訊完整性追求效能最大化。 而結合上一節中我們引入的DNS通用定址方案，我們是可以從請求的TCP options中得到ClusterIP，從而實現定址。這個方式可以實現不解碼請求報文，尤其是header部分解碼destination資訊開銷大時。這是我們的第二個優化思路：跳過解碼destination資訊，直接通過ClusterIP進行定址。 具體的實現則需要結合特定通訊協議的實際情況進行。 主流通訊協議 現在我們開始，以Proxy、Sidecar、Service Mesh的角度來看看目前主流的通訊協議和我們前面列舉的需要在SOFAMesh中支援的幾個協議。 SOFARPC/bolt協議 SOFARPC 是一款基於 Java 實現的 RPC 服務框架，詳細資料可以查閱 官方文件。SOFARPC 支援 bolt，rest，dubbo 協議進行通訊。REST、dubbo後面單獨展開，這裡我們關注bolt協議。 bolt 是螞蟻金服集團開放的基於 Netty 開發的網路通訊框架，其協議格式是變長，即協議頭+payload。具體格式定義如下，以request為例（response類似）： 我們只關注和請求轉發直接相關的欄位： TCP拆包 bolt協議是定長+變長的複合結構，前面22個位元組長度固定，每個位元組和協議欄位的對應如圖所示。其中classLen、headerLen和contentLen三個欄位指出後面三個變長欄位className、header、content的實際長度。和通常的變長方案相比只是變長欄位有三個。拆包時思路簡單明瞭： 先讀取前22個位元組，解出各個協議欄位的實際值，包括classLen，headerLen和contentLen 按照classLen、headerLen和contentLen的大小，繼續讀取className、header、content Destination Bolt協議中的header欄位是一個map，其中有一個key為“service”的欄位，傳遞的是介面名/服務名。讀取稍微麻煩一點點，需要先解碼整個header欄位，這裡對效能有影響。 RequestId Blot協議固定欄位中的requestID欄位，可以直接讀取。 SOFARPC中的bolt協議，設計的比較符合請求轉發的需要，TCP拆包，讀取RequestID，都沒有效能問題。只是Destination的獲取需要解碼整個header，效能開銷稍大。 總結：適合配合DNS通用解碼方案，跳過對整個header部分的解碼，從而提升效能。當然由於這個header本身也不算大，優化的空間有限，具體提升需要等對比測試的結果出來。 HSF協議 HSF協議是經過精心設計工作在4層的私有協議，由於該協議沒有開源，因此不便直接暴露具體格式和欄位詳細定義。 不過基本的設計和bolt非常類似：

• 採用變長格式，即協議頭+payload
• 在協議頭中可以直接拿到服務介面名和服務方法名作為Destination
• 有RequestID欄位

基本和bolt一致，考慮到Destination可以直接讀取，比bolt還要方便一些，HSF協議可以說是對請求轉發最完美的協議。 總結：目前的實現方案也只解碼了這三個關鍵欄位，速度足夠快，不需要繼續優化。 Dubbo協議 Dubbo協議也是類似的協議頭+payload的變長結構，其協議格式如下： 其中long型別的id欄位用來把請求request和返回的response對應上，即我們所說的RequestId。