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

1、引言

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

2、爲何須要 Service Mesh?

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

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

在運行時，SDK 和業務應用的代碼實際上是混合在一個進程中運行的，耦合度很是高，這就帶來了一系列的問題：

1. 升級成本高

   1. 每次升級都須要業務應用修改 SDK 版本號，從新發布；
   2. 在業務飛速往前跑的時候，是不太願意停下來作這些和自身業務目標不太相關的事情的；

2. 版本碎片化嚴重

   1. 因爲升級成本高，但中間件仍是會向前發展，長此以往，就會致使線上 SDK 版本各不統1、能力良莠不齊，形成很難統一治理；

3. 中間件演進困難

   1. 因爲版本碎片化嚴重，致使中間件向前演進過程當中就須要在代碼中兼容各類各樣的老版本邏輯，戴着『枷鎖』前行，沒法實現快速迭代；

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

2.2 異構系通通一治理

隨着新技術的發展和人員更替，在同一家公司中每每會出現使用各類不一樣語言、不一樣框架的應用和服務，爲了可以統一管控這些服務，以往的作法是爲每種語言、每種框架都從新開發一套完整的 SDK，維護成本很是高，並且對中間件團隊的人員結構也帶來了很大的挑戰。

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

圖片來源

2.3 金融級網絡安全

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

經過 Service Mesh，咱們能夠更方便地實現應用的身份標識和訪問控制，輔之以數據加密，就能實現全鏈路可信，從而使得服務能夠運行於零信任網絡中，提高總體安全水位。

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

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

   1. Mixer 的性能問題，一直都是 Istio 中最被人詬病的地方；
   2. 尤爲在 Istio 1.1/1.2 版本以後引入了 Out-Of-Process Adapter，更是雪上加霜；
   3. 從落地的角度看，Mixer V1 糟糕至極的性能，已是「生命沒法承受之重」。對於通常規模的生產級落地而言，Mixer 性能已是難於接受，更不要提大規模落地……
   4. Mixer V2 方案則給了社區但願：將 Mixer 合併進 Sidecar，引入 web assembly 進行 Adapter 擴展，這是咱們期待的 Mixer 落地的正確姿式，是 Mixer 的將來，是 Mixer 的『詩和遠方』。然而社區望穿秋水，但Mixer V2 遲遲未能啓動，長期處於 In Review 狀態，遠水解不了近渴；

2. Pilot

   1. Pilot 是一個被 Mixer 掩蓋的重災區：長期以來你們的性能關注點都在 Mixer，表現糟糕並且問題明顯的Mixer 一直在吸引火力。可是當選擇放棄 Mixer（典型如官方在 Istio 新版本中提供的關閉 Mixer 的配置開關）以後，Pilot 的性能問題也就很快浮出水面；
   2. 咱們實踐下來發現 Pilot 目前主要有兩大問題：1）沒法支撐海量數據 2）每次變化都會觸發全量推送，性能較差；

圖片來源

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

咱們都很是篤信雲原生就是將來，是咱們的『詩和遠方』，可是眼下的現實狀況是一方面 Brownfield 應用當道，另外一方面雲原生的 Service Mesh 方案自身離生產級還有必定的距離，因此在當下這個『路口』咱們該怎麼走？

圖片來源

咱們給出的答案是：

其實如前面所述，咱們採用 Service Mesh 方案的初心是由於它的架構改變能夠帶來不少好處，如：服務治理與業務邏輯解耦、異構語言統一治理、金融級網絡安全等，並且咱們相信這些好處無論對 Greenfield 應用仍是 Brownfield 應用都是很是須要的，甚至在現階段對 Brownfield 應用產生的業務價值會遠遠大於 Greenfield 應用。

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

4、螞蟻金服的產品實踐

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 雙模微服務平臺如今在阿里雲公測中，歡迎感興趣的企業前來體驗，https://www.aliyun.com/product/sofa。

5、展望將來

5.1 擁抱雲原生

目前已經能很是清楚地看到整個行業在經歷從雲託管(Cloud Hosted)到雲就緒(Cloud Ready)直至雲原生(Cloud Native)的過程，因此前面也提到咱們都很是篤信雲原生就是將來，是咱們的『詩和遠方』，雖然眼下在落地過程當中還存在必定的 gap，不過相信隨着咱們的持續投入，gap 會愈來愈小。

另外值得一提的是咱們擁抱雲原生其根本還在於下降資源成本，提高開發效率，享受生態紅利，因此雲原生自己不是目的，而是手段，切不可本末倒置了。

5.2 持續增強 Pilot 的能力

爲了更好地擁抱雲原生，後續咱們也會和 Istio 社區共建，持續增強 Pilot 的能力。

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

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

5.3 支持透明劫持

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

考慮到不少用戶對性能要求沒那麼敏感，同時有大量遺留系統但願經過 Service Mesh 實現統一管控，因此後續咱們也會支持透明劫持，同時在管控性和可觀測性方面會作加強。

6、結語

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

咱們判斷，將來 Service Mesh 會成爲雲原生下微服務的標準解決方案，因此咱們也會持續加大對 Service Mesh 的投入，包括接下來螞蟻金服將和阿里集團一塊兒深度參與到 Istio 社區中去，和社區一塊兒把 Istio 打形成 Service Mesh 的事實標準。

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

公衆號：金融級分佈式架構（Antfin_SOFA）