Service Mesh 在『路口』的產品思考與實踐：務實是根本

一、引言

Service Mesh 是螞蟻金服下一代架構的核心，經過了2年的沉澱，我們探索出了一套切實可行的方案並最終透過了雙十一的考驗。本文主要分享在當下『路口』，我們在產品設計上的思考和實踐，希望能給大家帶來一些啟發。

二、為什麼需要 Service Mesh?

2.1 微服務治理與業務邏輯解耦

在 Service Mesh 之前，微服務體系的玩法都是由中介軟體團隊提供一個 SDK 給業務應用使用，在 SDK 中會整合各種服務治理的能力，如：服務發現、負載均衡、熔斷限流、服務路由等。

在執行時，SDK 和業務應用的程式碼其實是混合在一個程式中執行的，耦合度非常高，這就帶來了一系列的問題：

1. 升級成本高

a.每次升級都需要業務應用修改 SDK 版本號，重新發布；

      b.在業務飛速往前跑的時候，是不太願意停下來做這些和自身業務目標不太相關的事情的；

  2.版本碎片化嚴重

      a.由於升級成本高，但中介軟體還是會向前發展，久而久之，就會導致線上 SDK 版本各不統一、能力參差不齊，造成很難統一治理；

  3.中介軟體演進困難

      a.由於版本碎片化嚴重，導致中介軟體向前演進過程中就需要在程式碼中相容各種各樣的老版本邏輯，戴著『枷鎖』前行，無法實現快速迭代；

有了 Service Mesh 之後，我們就可以把 SDK 中的大部分能力從應用中剝離出來，拆解為獨立程式，以 Sidecar 的模式部署。透過將服務治理能力下沉到基礎設施，可以讓業務更加專注於業務邏輯，中介軟體團隊則更加專注於各種通用能力，真正實現獨立演進，透明升級，提升整體效率。

2.2 異構系統統一治理

隨著新技術的發展和人員更替，在同一家公司中往往會出現使用各種不同語言、不同框架的應用和服務，為了能夠統一管控這些服務，以往的做法是為每種語言、每種框架都重新開發一套完整的 SDK，維護成本非常高，而且對中介軟體團隊的人員結構也帶來了很大的挑戰。

有了 Service Mesh 之後，透過將主體的服務治理能力下沉到基礎設施，多語言的支援就輕鬆很多了，只需要提供一個非常輕量的 SDK、甚至很多情況都不需要一個單獨的 SDK，就可以方便地實現多語言、多協議的統一流量管控、監控等治理需求。

圖片來源

2.3 金融級網路安全

當前很多公司的微服務體系建設都建立在『內網可信』的假設之上，然而這個原則在當前大規模上雲的背景下可能顯得有點不合時宜，尤其是涉及到一些金融場景的時候。

透過 Service Mesh，我們可以更方便地實現應用的身份標識和訪問控制，輔之以資料加密，就能實現全鏈路可信，從而使得服務可以執行於零信任網路中，提升整體安全水位。

三、在當下『路口』的思考

3.1 雲原生方案？

正因為 Service Mesh 帶來了上述種種的好處，所以這兩年社群中對 Service Mesh 的關注度越來越高，也湧現出了很多優秀的 Service Mesh 產品，Istio 就是其中一款非常典型的標杆產品。

Istio 以其前瞻的設計結合雲原生的概念，一出現就讓人眼前一亮，心之嚮往。不過深入進去看了之後發現，在目前階段要落地的話，還是存在一些 gap 的。

圖片來源

3.2 Greenfield vs Brownfield

在正式展開討論之前，我們先來看一副漫畫。

圖片來源

上面這幅漫畫描繪了這樣一個場景：

• 有兩個工人在工作，其中一個在綠色的草地（Greenfield）上，另一個在棕色的土地（Brownfield）上
• 在綠色草地上的工人對在棕色土地上的工人說：“如果你沒有給自己挖這麼深的坑，那麼你也可以像我一樣做一些很棒的新東西”
• 然後在棕色土地上的工人回答道：“你倒是下來試試！”

這是一幅很有意思的漫畫，從表面上看我們可以認為在綠色草地上的工人是站著說話不腰疼，不過其實本質的原因還是兩者所處的環境不同。

在一片未開發過的土地上施工確實是很舒服的，因為空間很大，也沒有周遭各種限制，可以使用各種新技術、新理念，我們國家近幾十年來的一些新區新城的建設就屬於這類。而在一片已經開發過的土地上施工就大不一樣了，周圍環境會有各種限制，比如地下可能有各種管線，一不小心就挖斷了，附近還有各種大樓，稍有不慎就可能把樓給挖塌了，所以做起事來就要非常小心，設計方案時也會受到各種約束，無法自由發揮。

對於軟體工程，其實也是一樣的，Greenfield 對應著全新的專案或新的系統，Brownfield 對應著成熟的專案或遺留系統。

我相信大部分程式設計師都是喜歡做全新的專案的，包括我自己也是一樣。因為可以使用新的技術、新的框架，可以按照事物本來的樣子去做系統設計，自由度很高。而在開發/維護一個成熟的專案時就不太一樣了，一方面專案已經穩定執行，邏輯也非常複雜，所以無法很方便地換成新的技術、新的框架，在設計新功能時也會礙於已有的架構和程式碼實現做很多妥協，另一方面前人可能不知不覺挖了很多坑，稍有不慎就會掉進坑裡，所以行事必須要非常小心，尤其是在做大的架構改變的時候。

3.3 現實場景

3.3.1 Brownfield 應用當道

在現實中，我們發現目前大部分的公司還沒有走向雲原生，或者還剛剛在開始探索，所以大量的應用其實還跑在非 k8s 的體系中，比如跑在虛擬機器上或者是基於獨立的服務註冊中心構建微服務體系。

雖然確實有少量 Greenfield 應用已經在基於雲原生來構建了，但現實是那些大量的 Brownfield 應用是公司業務的頂樑柱，承載著更大的業務價值，所以如何把它們納入 Service Mesh 統一管控，從而帶來更大的價值，也就成了更需要優先考慮的話題。

     圖片來源          

               獨立的服務註冊中心

3.3.2 雲原生方案離生產級尚有一定距離

另一方面，目前 Istio 在整體效能上還存在一些有待解決的點（引述小劍老師在 螞蟻金服 Service Mesh 深度實踐中的觀點）：

1.Mixer

a.Mixer 的效能問題，一直都是 Istio 中最被人詬病的地方；

b.尤其在 Istio 1.1/1.2 版本之後引入了 Out-Of-Process Adapter，更是雪上加霜；

c.從落地的角度看， Mixer V1 糟糕至極的效能，已經是“生命無法承受之重”。對於一般規模的生產級落地而言，Mixer 效能已經是難於接受，更不要提大規模落地……

d.Mixer V2 方案則給了社群希望：將 Mixer 合併進 Sidecar，引入 web assembly 進行 Adapter 擴充套件，這是我們期待的 Mixer 落地的正確姿勢，是 Mixer 的未來，是 Mixer 的『詩和遠方』。然而社群望穿秋水，但Mixer V2 遲遲未能啟動，長期處於 In Review 狀態，遠水解不了近渴；

2.Pilot

      a.Pilot 是一個被 Mixer 掩蓋的重災區：長期以來大家的效能關注點都在 Mixer，表現糟糕而且問題明顯的Mixer 一直在吸引火力。但是當選擇放棄 Mixer（典型如官方在 Istio 新版本中提供的關閉 Mixer 的配置開關）之後，Pilot 的效能問題也就很快浮出水面；

      b.我們實踐下來發現 Pilot 目前主要有兩大問題：1）無法支撐海量資料 2）每次變化都會觸發全量推送，效能較差；

圖片來源

3.4 當下『路口』我們該怎麼走？

我們都非常篤信雲原生就是未來，是我們的『詩和遠方』，但是眼下的現實情況是一方面 Brownfield 應用當道，另一方面雲原生的 Service Mesh 方案自身離生產級還有一定的距離，所以在當下這個『路口』我們該怎麼走？

圖片來源

我們給出的答案是：

其實如前面所述，我們採用 Service Mesh 方案的初心是因為它的架構改變可以帶來很多好處，如：服務治理與業務邏輯解耦、異構語言統一治理、金融級網路安全等，而且我們相信這些好處不管對 Greenfield 應用還是 Brownfield 應用都是非常需要的，甚至在現階段對 Brownfield 應用產生的業務價值會遠遠大於 Greenfield 應用。

所以從『務實』的角度來看，我們首先還是要探索出一套現階段切實可行的方案，不僅要支援 Greenfield 應用，更要能支援 Brownfield 應用，從而可以真正把 Service Mesh 落到實處，產生業務價值。

四、螞蟻金服的產品實踐

4.1 發展歷程和落地規模

Service Mesh 在螞蟻金服的發展歷程，先後經歷過如下幾個階段：

• 技術預研 階段：2017年底開始調研並探索 Service Mesh 技術，並確定為未來發展方向。
• 技術探索 階段：2018年初開始用 Golang 開發 Sidecar MOSN ，年中開源基於 Istio 的 SOFAMesh 。
• 小規模落地 階段：2018年開始內部落地，第一批場景是替代 Java 語言之外的其他語言的客戶端 SDK，之後開始內部小範圍試點。
• 規模落地 階段：2019年上半年，作為螞蟻金服金融級雲原生架構升級的主要內容之一，逐漸鋪開到螞蟻金服內部的業務應用，並平穩支撐了618大促。
• 對外輸出 階段：2019年9月，SOFAStack 雙模微服務平臺入駐阿里雲開始公測，支援 SOFA, Dubbo 和 Spring Cloud 應用
• 全面大規模落地 階段：2019年下半年，在螞蟻金服內部的大促核心應用中全面鋪開，落地規模非常龐大，而且最終如『絲般順滑』地支撐了雙十一大促。

在今年雙十一，Service Mesh 覆蓋了數百個交易核心鏈路應用，MOSN 注入的容器數量達到了數十萬，雙十一當天處理的 QPS 達到了幾千萬，平均處理響應時間<0.2 ms，MOSN 本身在大促中間完成了數十次的業務無感升級，達到了我們的預期，初步完成了基礎設施和業務的第一步的分離，見證了 Mesh 化之後基礎設施的迭代速度。

4.2 SOFAStack 雙模微服務平臺

我們的服務網格產品名是 SOFAStack 雙模微服務平臺，這裡的『雙模微服務』是指傳統微服務和 Service Mesh 雙劍合璧，即『基於 SDK 的傳統微服務』可以和『基於 Sidecar 的 Service Mesh 微服務』實現下列目標：

 • 互聯互通：兩個體系中的應用可以相互訪問

 • 平滑遷移：應用可以在兩個體系中遷移，對於呼叫該應用的其他應用，做到透明無感知

 • 異構演進：在互聯互通和平滑遷移實現之後，我們就可以根據實際情況進行靈活的應用改造和架構演進

在控制面上，我們引入了 Pilot 實現配置的下發（如服務路由規則），在服務發現上保留了獨立的 SOFA 服務註冊中心。

在資料面上，我們使用了自研的 MOSN，不僅支援 SOFA 應用，同時也支援 Dubbo 和 Spring Cloud 應用。

在部署模式上，我們不僅支援容器/K8s，同時也支援虛擬機器場景。

4.3 大規模場景下的服務發現

要在螞蟻金服落地，首先一個需要考慮的就是如何支撐雙十一這樣的大規模場景。前面已經提到，目前 Pilot 本身在叢集容量上比較有限，無法支撐海量資料，同時每次變化都會觸發全量推送，無法應對大規模場景下的服務發現。

所以，我們的方案是保留獨立的 SOFA 服務註冊中心來支援千萬級的服務例項資訊和秒級推送，業務應用透過直連 Sidecar 來實現服務註冊和發現。

4.4 流量劫持

Service Mesh 中另一個重要的話題就是如何實現流量劫持：使得業務應用的 Inbound 和 Outbound 服務請求都能夠經過 Sidecar 處理。

區別於社群的 iptables 等流量劫持方案，我們的方案就顯得比較簡單直白了，以下圖為例：

1. 假設服務端執行在1.2.3.4這臺機器上，監聽20880埠，首先服務端會向自己的 Sidecar 發起服務註冊請求，告知 Sidecar 需要註冊的服務以及 IP + 埠(1.2.3.4:20880)；
2. 服務端的 Sidecar 會向 SOFA 服務註冊中心發起服務註冊請求，告知需要註冊的服務以及 IP + 埠，不過這裡需要注意的是註冊上去的並不是業務應用的埠(20880)，而是Sidecar自己監聽的一個埠(例如：20881)；
3. 呼叫端向自己的 Sidecar 發起服務訂閱請求，告知需要訂閱的服務資訊；
4. 呼叫端的Sidecar向呼叫端推送服務地址，這裡需要注意的是推送的IP是本機，埠是呼叫端的 Sidecar 監聽的埠(例如：20882)；
5. 呼叫端的 Sidecar 會向 SOFA 服務註冊中心發起服務訂閱請求，告知需要訂閱的服務資訊；
6. SOFA 服務註冊中心向呼叫端的 Sidecar 推送服務地址(1.2.3.4:20881)；

經過上述的服務發現過程，流量劫持就顯得非常自然了：

1. 呼叫端拿到的『服務端』地址是127.0.0.1:20882，所以就會向這個地址發起服務呼叫；
2. 呼叫端的 Sidecar 接收到請求後，透過解析請求頭，可以得知具體要呼叫的服務資訊，然後獲取之前從服務註冊中心返回的地址後就可以發起真實的呼叫(1.2.3.4:20881)；
3. 服務端的 Sidecar 接收到請求後，經過一系列處理，最終會把請求傳送給服務端(127.0.0.1:20880)；

可能會有人問，為啥不採用 iptables 的方案呢？主要的原因是一方面 iptables 在規則配置較多時，效能下滑嚴重，另一個更為重要的方面是它的管控性和可觀測性不好，出了問題比較難排查。

4.5 平滑遷移

平滑遷移可能是整個方案中最為重要的一個環節了，前面也提到，在目前任何一家公司都存在著大量的 Brownfield 應用，它們有些可能承載著公司最有價值的業務，稍有閃失就會給公司帶來損失，有些可能是非常核心的應用，稍有抖動就會造成故障，所以對於 Service Mesh 這樣一個大的架構改造，平滑遷移是一個必選項，同時還需要支援可灰度和可回滾。

得益於獨立的服務註冊中心，我們的平滑遷移方案也非常簡單直白：

1.初始狀態

以一個服務為例，初始有一個服務提供者，有一個服務呼叫者。

2.透明遷移呼叫方

在我們的方案中，對於先遷移呼叫方還是先遷移服務方沒有任何要求，這裡假設呼叫方希望先遷移到 Service Mesh 上，那麼只要在呼叫方開啟 Sidecar 的注入即可，服務方完全不感知呼叫方是否遷移了。所以呼叫方可以採用灰度的方式一臺一臺開啟 Sidecar，如果有問題直接回滾即可。

3.透明遷移服務方

假設服務方希望先遷移到 Service Mesh 上，那麼只要在服務方開啟 Sidecar 的注入即可，呼叫方完全不感知服務方是否遷移了。所以服務方可以採用灰度的方式一臺一臺開啟 Sidecar，如果有問題直接回滾即可。

4.終態

4.6 多協議支援

考慮到目前大部分使用者的使用場景，除了 SOFA 應用，我們同時也支援 Dubbo 和 Spring Cloud 應用接入SOFAStack 雙模微服務平臺，提供統一的服務治理。多協議支援採用通用的  x-protocol，未來也可以方便地支援更多協議。

4.7 虛擬機器支援

在雲原生架構下，Sidecar 藉助於 K8s 的 webhook/operator 機制可以方便地實現注入、升級等運維操作。然而大量系統還沒有跑在 K8s 上，所以我們透過 agent 的模式來管理 Sidecar 程式，從而可以使 Service Mesh 能夠幫助老架構下的應用完成服務化改造，並支援新架構和老架構下服務的統一管理。

4.8 產品易用性

在產品易用性上我們也做了不少工作，比如可以直接在介面上方便地設定服務路由規則、服務限流等，再也不用手工寫 yaml 了：

也可以在介面上方便地檢視服務拓撲和實時監控：

4.9 阿里雲公測中

最後打一個小小的廣告，SOFAStack 雙模微服務平臺現在在阿里雲公測中，歡迎感興趣的企業前來體驗， 。

五、展望未來

5.1 擁抱雲原生

目前已經能非常清楚地看到整個行業在經歷從雲託管(Cloud Hosted)到雲就緒(Cloud Ready)直至雲原生(Cloud Native)的過程，所以前面也提到我們都非常篤信雲原生就是未來，是我們的『詩和遠方』，雖然眼下在落地過程中還存在一定的 gap，不過相信隨著我們的持續投入，gap 會越來越小。

另外值得一提的是我們擁抱雲原生其根本還在於降低資源 成本，提升開發 效率，享受生態 紅利，所以雲原生本身不是目的，而是手段，切不可本末倒置了。

5.2 持續加強 Pilot 的能力

為了更好地擁抱雲原生，後續我們也會和 Istio 社群共建，持續加強 Pilot 的能力。

而就在最近，在綜合了過去一年多的思考和探索之後，螞蟻金服和阿里集團的同事們共同提出了一套完整的解決方案，來融合控制平面和傳統註冊中心/配置中心，從而可以在保持協議標準化的同時，加強 Pilot 的能力，使其逐步向生產級靠攏。

（更多細節可以參考小劍老師的 螞蟻金服 Service Mesh 深度實踐 一文，在此就不再贅述了）

5.3 支援透明劫持

前面提到在螞蟻金服的實踐中是基於服務註冊中心來實現流量劫持的，該方案不管是在效能、管控能力還是可觀測性方面都是不錯的選擇，不過對應用存在一定的侵入性（需要引入一個輕量的註冊中心 SDK）。

考慮到很多使用者對效能要求沒那麼敏感，同時有大量遺留系統希望透過 Service Mesh 實現統一管控，所以後續我們也會支援透明劫持，同時在管控性和可觀測性方面會做增強。

六、結語

基於『務實』的理念，Service Mesh 在螞蟻金服經過了2年的沉澱，我們探索出了一套現階段切實可行的方案並最終透過了雙十一的考驗。在這個過程中，我們也愈發體驗到了 Service Mesh 帶來的好處，例如 MOSN 在大促中間完成了數十次的業務無感升級，見證了 Mesh 化之後基礎設施的迭代速度。

我們判斷，未來 Service Mesh 會成為雲原生下微服務的標準解決方案，所以我們也會持續加大對 Service Mesh 的投入，包括接下來螞蟻金服將和阿里集團一起深度參與到 Istio 社群中去，和社群一起把 Istio 打造成 Service Mesh 的事實標準。

最後，也歡迎志同道合的夥伴 加入我們，一起參與建設激動人心的下一代雲原生架構！