乾貨 | 螞蟻金服是如何實現經典服務化架構往 Service Mesh 方向的演進的？

摘要： 小螞蟻說： 螞蟻金服在服務化上面已經通過多年的沉澱，支撐了每一年雙十一的高峯峯值。Service Mesh 做爲微服務的一個新方向，在最近兩年成爲領域的一個大熱點，可是如何從經典服務化架構往 Service Mesh 的方向上演進，中間可能會遇到什麼樣的問題，幾乎沒有能夠借鑑的經驗。

小螞蟻說：

螞蟻金服在服務化上面已經通過多年的沉澱，支撐了每一年雙十一的高峯峯值。Service Mesh 做爲微服務的一個新方向，在最近兩年成爲領域的一個大熱點，可是如何從經典服務化架構往 Service Mesh 的方向上演進，中間可能會遇到什麼樣的問題，幾乎沒有能夠借鑑的經驗。

本文會給你們分享 Service Mesh 在螞蟻金服的演進歷程和在2018年6月舉辦的 GIAC 全球互聯網架構大會中螞蟻金服高級技術專家與現場人員關於Service Mesh的熱門QA互動。

前言

在過去的一段時間中螞蟻金服已經開始採用 Service Mesh 來幫助解決一些架構上的問題，而且在 Service Mesh 如何更好地與經典的服務化架構結合上有必定的經驗，但願藉此分享和你們交流咱們這部分的實踐。使你們對螞蟻金服當前的服務化架構有更多瞭解，並對 Service Mesh 如何解決經典服務化架構中的問題以及螞蟻金服實際在落地Service Mesh 中的時候的一些設計考慮和將來展望有更進一步的瞭解，也但願能與行業分享螞蟻金服服務化架構現狀。

螞蟻金服從單體應用轉移到服務化的架構下已經通過了差很少 10 年的時間，在整個過程當中，爲了知足螞蟻金服金融級的要求，咱們也構建了一整套地面向金融級的分佈式架構的解決方案，也就是 SOFA。

SOFA 其實包含了金融級分佈式中間件，CICD 以及 PAAS 平臺。SOFA中間件部分包含的內容包括 SOFABoot 研發框架、SOFA微服務相關的框架（RPC，服務註冊中心，批處理框架，動態配置等等）、消息中間件、分佈式事務和分佈式數據訪問等等中間件。

以上的這些中間件都是基於 Java 技術棧的，目前 SOFA 在螞蟻金服內部大概超過 90% 的系統在使用，除了這些系統以外，還有剩下的 10% 的系統，採用 NodeJS，C++，Python 等等技術棧研發的。這剩下的 10% 的系統想要融入到 SOFA 的整個體系中，一種辦法是用對應的語言再去寫一遍 SOFA 中間件的各個部分對應的客戶端。

事實上，以前咱們正是這麼幹的，螞蟻金服內部以前就有一套用 NodeJS 搞的 SOFA 各個組件的客戶端，可是最近幾年隨着 AI 等領域的興起，C++ 也在螞蟻金服內部也在被應用到愈來愈多的地方，那麼咱們是否也要用 C++ 再來寫一遍 SOFA 中間件的各個客戶端？若是咱們繼續採用這種方式去支持 C++ 的系統，首先會遇到成本上的問題，每一個語言一套中間件的客戶端，這些中間件的客戶端就像一個個煙囪，都須要獨立地去維護，去升級。另外一方面，從穩定性上來說，以前 Java 的客戶端踩過的一些坑，可能其餘的語言又得從新再踩一遍坑。

對於多語言的問題來講，Service Mesh 其實就很好地解決了這部分的問題，經過 Service Mesh的方案，咱們能夠儘可能把最多的功能從中間件的客戶端中移到 Sidecar 中，這樣就能夠作到一次實現，就搞定掉全部語言，這個對於基礎設施團隊來講，在成本和穩定性上都是一個提高。

另外的一個問題實際上是全部在往雲原生架構中轉型的公司都會遇到的問題，雲原生看起來很是美好，可是咱們怎麼漸進式的演進到雲原生的架構下？特別是對於遺留系統，到底怎麼作比較好。固然，一種簡單粗暴的方式就是直接用雲原生的設施和架構從新寫一套，可是這樣，投入的成本就很是高，並且重寫就意味着可能會引入 Bug，致使線上的穩定性的問題。那麼有沒有一種方式可讓這些遺留系統很是便捷地享受到雲原生帶來的好處呢？Service Mesh 其實爲咱們指明瞭一個方向，經過 Service Mesh，咱們爲遺留系統安上一個 Sidecar，少許地修改遺留系統的配置甚至不用修改遺留系統的配置就可讓遺留系統享受到服務發現，限流熔斷，故障注入等等能力。

最後咱們在螞蟻金服的服務化的過程當中遇到的問題是中間件升級的問題，螞蟻金融從單體應用演進到服務化的架構，再演進到單元化的架構，再演進到彈性架構，其實伴隨了大量中間件升級，每次升級，中間件不用說要出新的版本去提供新的能力，業務系統也須要升級依賴的中間件，這中間再出個 Bug，又得從新升級一遍，不光是中間件研發同窗痛苦，應用的研發同窗也很是痛苦。

咱們從單體應用演進到了服務化的架構，從原來好幾個團隊維護同一個應用，到各個團隊去維護各自領域的應用，團隊之間經過接口去溝通，已經將各個業務團隊之間作到了最大程度的解耦，可是對於基礎設施團隊來講，仍是和每個業務團隊耦合在一塊兒。

咱們中間嘗試過用各類方法去解決升級過程當中的耦合的問題，一種是經過咱們本身研發的應用服務器 CloudEngine 來管理全部的基礎類庫，儘可能地去減小給用戶帶來的升級成本，不用讓用戶一個個升級依賴，一次升級就能夠。

可是隨着螞蟻的業務的不斷髮展，規模地不斷擴大，團隊的數量，業務的規模和咱們交付的效率已經成爲了主要的矛盾，因此咱們指望以更高的效率去研發基礎設施，而不但願基礎設施的迭代受制於這個規模。

後來螞蟻本身研發的數據庫 OceanBase 也在用一個 Proxy 的方式來屏蔽掉 OceanBase 自己的集羣負載，FailOver切換等方面的邏輯，而恰好 Service Mesh 的這種 Sidecar 的模式也是這樣的一個思路，這讓咱們看到將基礎設施的能力從應用中下移到 Sidecar 這件事情是一個業界的總體的趨勢和方向，經過這種方式應用和中間件的基礎設施今後成了兩個進程，咱們能夠針對中間件的基礎設施進行單獨的升級，而不用和應用的發佈升級綁定在一塊兒，這不只解放了應用研發和基礎設施團隊，也讓基礎設施團隊的交付能力變地更強，之前可能須要經過半年或者一年甚至更長時間的折騰，纔可以將基礎設施團隊提供的新的能力鋪到全部的業務系統中去，如今咱們經過一個月的時間，就能夠將新能力讓全部的業務系統享受到。這也讓基礎設施團隊的中臺能力變得更強了。這樣咱們就能夠把咱們仍是把一些架構當中很是關鍵的支撐點以及一些邏輯下沉到 Sidecar上面去，由於整個螞蟻金服的總體架構有很是多的邏輯和能力承載在這一套架構上面的。這些東西咱們有一個最大的職責是要支撐它快速向前演進和靈活。

Service Mesh 的選型

前面講到了螞蟻金服當前服務化架構下遇到的問題以及咱們但願可以經過 Service Mesh 可以去解決的一些問題，接下來就面臨一個很現實的問題，Service Mesh 的框架咱們到底應該怎麼選，咱們應該用什麼樣的標準去衡量，那接下來，我就給你們分享一下螞蟻金服在Service Mesh 的框架上的選型上的一些思考。

首先，全部的架構的演進都不是一蹴而就的，都是一個漸進式地演進的一個過程，越大的公司在架構演進的過程當中其實越須要考慮這一點。因此咱們在選型的時候就須要去考慮這一點，考慮目標框架可否很好地和當前的架構融合在一塊兒。另外一個點，做爲一個和錢打交道的公司，咱們須要特別地去關注目標框架是否在生產環境通過大規模的驗證，在場景上，是否通過了各種場景的驗證。

目前，業界主流的 Service Mesh 相關的框架有三個，分別是 Google，IBM，Lyft都參與其中的 Istio，以及 Bouyant 公司下的兩個開源的 Service Mesh 的框架 Linkerd 以及 Conduit。

首先咱們來看下 Istio，Istio 應該是目前被關注最高的一個 ServiceMesh 框架，自己又有頂尖公司的光環加持，好比 Google，IBM 等等，他也完整地包含了一個 Data Plane 以及 Control Plane，可是Istio 一直以來被挑戰的地方其實在於他的 Control Plane 的 Mixer 的部分，Istio 的 Mixer 承擔了服務鑑權，Quota 控制，Tracing，Metrics等等能力，它是一箇中央的節點，若是不開啓緩存的狀況下，全部的調用都須要從 Mixer 中去過，即便開啓了緩存的狀況，也不可避免的有請求必定要從 Mixer 中去過，而在全螞蟻，有20000 多的服務，服務之間的調用是很是頻繁的，若是都須要過 Mixer，那 Mixer 就成了一個單點，這個單點的運維和高可用又成了一個問題。

另外，Istio 的性能是咱們一直以來比較擔憂的問題，雖然 Istio 每一個版本的發佈，性能都有了必定程度的提高。可是咱們來看下 Istio 的性能數據，0.5.1 的時候是 700 的 TPS，0.6.0 的時候是 1000 個 TPS，0.7.1 的時候是 1700 個 TPS，相對於通常的RPC 通訊框架，最低最低都是萬級別的 TPS，Istio 的這個性能數據的確是有點兒慘淡，徹底沒法知足螞蟻這邊的性能要求。

接下來咱們來看 Linkerd，Linkerd 算是業界幾個 Service Mesh的框架裏面最成熟的一個了，可是他也有一個問題，首先就是他脫胎於 Twitter 的 Finagle，架構上其實不夠開放，無法很好的適配到螞蟻的環境裏面去，另外Linkerd 也沒有 Control Plane 這一層，只有 Sidecar，再者 Linkerd 的路由規則 DTab 實際上是挺難理解的。最後，其實也是咱們當時選型的時候最關心的一個問題，Linkerd是用 Scala 寫的，跑在 JVM 上面，我從 Linkerd 的一篇博客上摘錄出了一張圖片，這篇博客主要講的是如何優化 JVM 的內存使用，這種文章通常上是的確有這個問題，纔會去寫這樣的文章，從這張圖片中咱們能夠看到 Linkerd 所須要的內存至少都須要 100M，這也是 Bouyant 官方不推薦 Linkerd 和應用作一對一的部署，而是採用 DaemonSet 的方式進行部署。而咱們指望的一個部署方式是和應用作一對一的部署，這樣的內存佔用對於咱們來講成本太過，咱們指望將 Sidecar 的內存佔用控制在 10M 左右。

最後，咱們來看下 Conduit，首先 Conduit 也是 Linkerd 不久以前推出的一個Service Mesh 的框架，其實不太成熟，其次，Conduit 選擇的語言是 Rust，咱們來看下 Rust 在 Tiebo 上的排名，Java 長時間高居第一位，C++在第三位，Golang 通過這幾年雲基礎設施的蓬勃發展，到了 14 位，而 Rust，和一衆語言的佔用率沒有太大的差異，排在了 50 位日後。

因此，咱們最後選擇了自研 Service Mesh，一方面固然是咱們基於前面的兩個準則去衡量目前業界流行的Service Mesh 框架，沒有可以徹底知足咱們的要求的，另外一方面螞蟻金服服務化上有長期以及深厚的積累，這部分的一些經驗也能夠支持咱們可以更好地去自研咱們本身的Service Mesh 的框架。

固然，咱們也不是說徹底從零開始搞 Service Mesh 框架，對於業界的Service Mesh 的框架中的優秀理念，咱們是但願可以吸取過來的，另外一方面，咱們也但願可以儘可能地去 Follow Service Mesh 目前社區中的一些規範。

SOFA Mesh 的設計

首先，SOFA Mesh 其實直接採用了 Istio 的 Control Plane 的Pilot 和 Auth，由於咱們以爲 Istio 在這塊上沒有太大的問題甚至裏面也有一些很是不錯的設計，好比Pilot 這部分的 Universal Data API 就是很是不錯的設計。Istio 的 Auth 這部分也充分地利用了 Kubernetes 的安全機制。

而Mixer 這部分，其實我以前就提到咱們是以爲有設計上問題的，因此咱們的想法是直接把 Mixer 搬到 Sidecar 中實現。

再者，你們都知道 Istio 的 Sidecar 是 Envoy，它是一個用 C++ 寫的，那麼咱們怎麼把Mixer 移入到 Sidecar 中去呢，其實咱們的 SOFA Mesh 的 Sidecar 是採用了 Golang 來寫的，因此纔給把 Mixer 移入Sidecar 提供了可能性，固然，咱們選擇用 Golang 來研發 Sidecar 不只僅是爲了把 Mixer 移入到 Sidecar 而已，其實也有其餘的考慮，一方面，在雲計算的時代，Golang以及成爲構建基礎設施的首選語言，咱們看到大量的基礎設施都是用 Golang 寫的，包括 Docker，Kubernetes 等等，選擇 Golang，其實也是但願可以更好地和雲原生時代的這些基礎設施貼合。

另外，相比於 Envoy 採用的 C++，Golang 顯然更加容易上手，也更加容易找到這方面的人才，另外，Golang相對於 JVM 來講，Memory Footprint 低了很是多，咱們用 Golang 寫的 Sidecar，目前的峯值 TPS 下的內存在用在 11M，雖然還有必定的優化空間，可是相比於 JVM 來講，已經下降了10 倍。

另外，雖然咱們採用了 Istio 的 Pilot，可是在內部使用的時候，直接使用Pilot 並不能知足咱們的訴求。首先，Pilot 在 Kubernetes 上是直接對接到 Kubernetes 的服務發現機制上的，不管是 SOFARPC，仍是微博的Motan 等等國內的服務框架，其實都是單個應用多個服務這樣的模型，而 Kubernetes 的服務發現機制實際上針對的是單個應用單個服務的模型，在模型上就不太一致。另外，SOFA的服務註冊中心 SOFARegistry 在螞蟻金服內部通過了多年的實踐，面對內部大規模的服務化的場景，SOFARegistry 的擴展能力以及可靠性已經通過了大量的實踐證實，這裏說一下SOFARegistry 上的一些數據，上面大約註冊了 2W 多個服務，一個機房裏面的 Pub 和 Sub 的加起來在千萬級別。基於以上的考慮，咱們選擇了用Pilot 上增長 SOFARegistry 的 Adapter，使之可以拿到 SOFARegistry 上的服務註冊信息。

而後，Pilot 還有一個問題，就是原來 Pilot 會把全部的服務註冊相關的數據都同步到Pilot 上，這個對於 Pilot 的集羣的壓力是很是大的，因此咱們選擇了只同步必要的數據到一個 Pilot 的節點上，介紹 Pilot 自己的內存壓力。

最後，我再分享一個螞蟻金服的場景，在螞蟻金服，由於事業部衆多以及監管的問題，不用的事業部之間的一些機器多是網絡不通的，那麼他們要作服務訪問，就必須有一個角色來作跨環境之間的服務訪問，因此咱們基於 Sidecar 的概念，提出了 EdgeSidecar 的角色，他在技術的實現細節上其實和和應用部署在一塊兒的 Sidecar 是很是相似的，只是這個 Sidecar 做爲一個「邊緣」的角色，來負責跨環境的服務通訊問題。

因此，SOFA Mesh 在總體的大圖上大概是這樣的，咱們自研了一個 Golang 的Sidecar，而且把 Mixer 歸入到 Sidecar 中，來防止出現相似於 Istio 那樣的性能問題，在 Pilot 和 Auth 這兩個角色了，咱們選擇直接使用Istio 的，而後在上面作必定程度的適配，適配到螞蟻內部的環境中，而後咱們在整個部署上，新增了一個 EdgeSidecar 的角色，來解決跨環境的服務調用的問題。

我知道你們必定對 SOFA Mesh 在螞蟻內部的落地狀況很是感興趣，目前咱們已經落地的場景主要是多語言的場景，解決其餘的語言和 SOFA 的通訊問題，大約上了二三十個系統。而後咱們正在嘗試用 SOFA Mesh 去更好地解決服務間調用的安全，以及藍綠髮布的問題，在異構系統通訊的這件事情上，咱們也在不久的未來會嘗試用 SOFA Mesh 去解決。

固然，SOFA Mesh 在螞蟻內部的落地其實離不開開源社區，因此在將來的兩三個月內，咱們也會將 SOFA Mesh 開源出來，將螞蟻內部實踐 Service Mesh 的成果開源出來，給你們更多在這方面的參考。

對於將來，其實我以爲中間件做爲基礎設施將來和雲平臺融合是一個不可阻擋地趨勢，除了 Service Mesh，將來還可能會出現 Message Mesh，DB Mesh 等等產品，我知道業界有些同窗已經開始作這方面的努力了。最後總結一下我今天演講的內容，一個是 Service Mesh 給螞蟻金服解決的問題，包括多語言，遺留系統以及基礎設施團隊和業務團隊耦合的問題。在 ServiceMesh 的選型上，咱們主要考量和當前架構的可融合性，以及框架的高可用，穩定性。將來除了 ServiceMesh，可能還會出現其餘的 Mesh，中間件和底層雲平臺進一步融合的趨勢不可擋。多謝你們！

下面帶來的是GIAC大會中螞蟻金服高級技術專家與現場參會人員進行關於Service Mesh的問答互動，咱們精選了幾個比較熱門的問答分享給你們。

1、Mesh的高可用和安全，可否詳細說明一下？

答：咱們最近正在作安全這件事情，安全涉及到兩個方面，一個方面是 RPC 的整個服務調用健全的問題，這個是能夠直接在 Mesh 中去作的，能夠直接利用 Istio 的 RBAC 來實現，另外是 Mesh 和 Mesh 之間的 TLS雙向認證的事情。這個其實 Istio 裏面會有一些現成的方案，它與 K8S 融合的也很是好，這些東西是能夠直接拿過來去用的。

2、如何解決服務的多版本路由和數據單元的多版本路由的問題？

答：ServiceMesh 主要關注的是服務調用這一塊，我來解釋一下多版本的路由，其實咱們在內部的話，服務版本這件事情用得會比較少，用得更多的是同一服務不一樣的實現。可是其實多版本路由這一塊，若是說你們知道 K8S 的 Label 的話，能夠把它的這種設計來借鑑到整個Mesh當中，而後經過不一樣的標籤來作區分，後面也會有一些這方面的分享出來。

3、Service Mesh 主要是解決了請求的可靠傳輸和服務治理的問題嗎？

答：應該是說Service Mesh提出了更好的方式去解決請求的可靠傳輸和服務治理的問題。其實想像一下，若是說你要上一整套的服務治理的架構的話，在原來的方式下可能須要大家全部的上層業務系統都接入大家對應的服務治理的組件，如今的話，只要有一個Service Mesh，在這個 Sidecar 當中就能夠把服務治理的這件事情作掉。它沒有去解決新的問題，只是把一些老的問題用更好的方式去解決。

4、爲何Control Plane對於Mesh來講很重要？

答：其實這個就涉及到整個雲平臺和咱們整個服務化體系的融合的問題。其實目前你們能夠看到，Pilot 這部分的東西，在原來 Istio 設計當中是很是強的和 K8S 這個東西融合在一塊兒的，若是說你沒有這套東西存在的話，對於 Mesh 來講仍是一個很是上層的中間件這樣的東西。固然你能夠說不用 Control Plane 這一層，只有 Sidecar，對接到原來的一整套的服務治理體系當中去，這樣作也是能夠的，沒有太大的問題。可是有了 Control Plane 這一層東西，它定義了很是通用的 API，自己這個架構又是和雲平臺整個架構是綁定得比較緊的，有更好的融合度。因此咱們以爲整個Control Plane這一層是很是重要的。

另外，Istio 提出 Control Plane，實際上是在往微服務標準化方面邁進了很大一層。它裏面有很是多的服務發現的標準，治理的標準，雖說他大膽提出了這樣的概念和假設，咱們也看到了它的一些不足，因此咱們但願和社區一塊兒推動這一層的標準化。就像我一開始分享的，基礎設施一層一層的向上包。像咱們以爲愈來愈多的中間件的部分，實際上是會被沉澱到基礎設施當中的。如今也有云原生語言，咱們編譯了一下，發現很慢，問題也不少，可是咱們以爲這是一個方向。你們在寫的時候，可能就用這樣的語言去寫，不少能力就提高上去了。咱們但願把基礎設施向上再推一下，去扮演這樣一個角色。這也是咱們認爲 Control Plane 的最大的價值。

本文做者：兔子醬
閱讀原文本文爲雲棲社區原創內容，未經容許不得轉載。