背景：

在阿里服務端開發以Java為主的大背景下，其他異構語言業務如何調用現有Java服務，如何與集團中間件打通，就成為使用非Java語言團隊必須要解決的首要問題。

已有方案問題：

在ServiceMesh方案成熟之前，我們采用：通過Dart C/C++擴展方式調用各中間件客戶端SO庫（類JNI）。該方案在業務初期很好的解決了Dart服務端生態建設問題。但是該方案還存在以下幾個問題：

運維耦合度高。業務代碼和客戶端SO庫代碼打包在一起，運行在同一進程，一旦微服務框架需要升級，業務代碼也需要維護和重啟。

復雜性：進程內的多個語言環境，跨語言數據表示和傳輸等問題，都會增加系統的復雜性，降低原有服務的性能。

接入成本高

新功能滯后

ServiceMesh方案:

由于現有方案存在的一些問題，我們轉向ServiceMesh尋找解決問題的思路

如上圖所示：與目前比較常見的微服務框架相比，ServiceMesh把微服務客戶端核心功能獨立出來，并作為一個獨立Proxy進程部署在每一個主機上，業務進程通過Proxy進程與外界通信。這個獨立的Proxy進程就是ServiceMesh的核心: SideCar。

業務進程和SideCar之間最常見的兩種通信方案：1. 基于Iptables的流量攔截轉發方案，2. 業務進程通過輕量化Mesh客戶端直連SideCar。從實現原理上看，Iptables方案相比直連方案會有一定的性能損耗和延遲。我們選擇的ALiMesh方案采用了輕量級Mesh客戶端方案。

Mesh化之后，業務進程只包含業務代碼和輕量化的Mesh Client，代碼邏輯變得簡單，問題定位更清晰。業務同學可以更專注業務開發，而不用關注微服務龐雜的邏輯。微服務框架核心功能的開發維護擴展升級等工作由專門的Mesh團隊負責，獨立升級維護，與業務解耦，業務無感知。

ServiceMesh方案解決了現有方案存在的：運維成本、接入成本問題，代碼復雜問題。 而且采用開源的Mesh方案，還可以借助開源的力量，不斷增加新的功能。

ALiMesh接入:

SideCar的引入，使得原本業務跟微服務之間的進程內通信轉變成進程間的通信，進出流量增加了一跳，那么ServiceMesh的引入對業務性能帶來的影響具體怎么樣？接下來我們基于ALiMesh(Istio開源方案阿里版本)一起分情況看下。

ALiMesh提供了2種接入方案：Http方式、HSF方式。其中Http方式又分為Http1.0和Http2.0方式。

AliMesh Http方案（快速接入方案）：

如圖所示，Http方式下：在數據面，業務進程與SideCar，SideCar與Service Provider之間采用Http協議交互，數據編碼采用Json。業務進程集成了基于Http協議的Mesh Client，Mesh SideCar通過泛化調用遠程調用Java HSF服務。

而在控制面： ISTIO控制面同步ConfigServer的服務提供者列表數據，SideCar跟ISTIO pilot走原生的服務同步通道。

由于Http協議的通用性，該方案接入簡單，快速的驗證了Mesh方案的可行性，但是性能還達不到業務的線上要求，經測試，主要指標如下：

備注：目前閑魚只使用了ServiceMesh OutBound功能。為了模擬線上詳情頁真實流量情況，每次上游請求處理過程會調用21次下游Java HSF服務, 所以圖中QPS換算成Mesh流量時，需要乘以21倍，以下測試都是如此

如圖所示：Mesh方式相比直連方式，Consumer側CPU消耗增長一倍，每一次RPC調用RT增加了近2ms。且HSF Provider側CPU也有近40%的增加，這一點跟HSF同學的測試結果基本吻合。經過分析，我們初步定位引起CPU消耗增加的主要原因是Http1.1協議的連接方式（已經使用了連接池）和數據編碼。

為了驗證該方案的問題所在，我們測試接入了Http2.0方案。Http2.0相比Http1.x，在連接多路復用、數據格式、head壓縮等等方面具有天然的優勢。經過測試，ALiMesh的性能也較Http1.x有了較大的提升。部分滿足或者接近我們的技術要求。詳細指標如下圖所示：

如圖所示，優化后，業務進程Consumer側，CPU和RT消耗稍稍有些超標（CPU 增加不超過20%）。為了探索更高性能，更低延遲的方案，我們轉向了HSF私有協議方案。

AliMesh HSF擴展協議方案（高性能方案）：

如圖所示，HSF方案下，HSF RPC協議實現為Mesh SideCar的一個擴展協議。在數據面：業務進程與SideCar，SideCar與Service Provider 之間采用HSF 2.0私有協議，數據編碼采用Hessian 1.0。業務進程集成了Mesh化改造的HSFCPP SO庫作為MeshClient，負責與Mesh SideCar通信。而在控制面：SideCar與Configsvr直連，同步服務提供者列表和配置信息，采用差量同步方式，以降低控制面板的CPU消耗。詳細測試數據如下：

經過不斷優化，最終成功將Mesh CPU增長控制在20%以內，每跳RPC調用RT增加控制在1ms以內。

ServiceMesh在閑魚的應用：

目前Dart+ALiMesh方案在閑魚服務端已經穩定運行八個月+，服務于閑魚詳情頁、猜你喜歡，租房首頁等業務, 期間Mesh多次進行優化、升級、擴展功能等運維工作，業務進程都無感，正常對外提供服務，業務同學不需要參與。

ALiMesh引入后，對線上業務RT的影響如下圖所示：橙色的曲線是Mesh化后的業務RT監控曲線，藍色的曲線是Mesh化前一周業務RT監控曲線，排除線上環境日常的波動后，ALiMesh的引入對線上業務RT的影響相當小。

總結與展望:

ServiceMesh方案，將微服務邏輯和服務間通信這些與業務無關的邏輯從業務應用中解耦出來，讓業務應用瘦身，讓業務同學更專注于業務開發。同時也讓異構語言能夠低成本的建立服務端生態，接入現有系統。

當然對于性能損失，個人認為總體利大于弊。業務團隊可以根據自己業務實際情況進行測試評估，權衡利弊是否要接入ServiceMesh。

接下來我們會進一步擴大AliMesh在閑魚的應用，并與ALiMesh合作，推動AliMesh在Dart Faas落地，適配更多的中間件。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的看！闲鱼在ServiceMesh的探索和实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。