2018年，微服務方興未艾，Service Mesh（服務網格）又快速崛起。有觀點認為，2018年可被稱之為“Service Mesh元年”，在未來兩年中，Service Mesh將迎來爆發式增長，成為下一代的微服務架構。
那麼，Service Mesh到底是什麼？自2016年被提出，為何不到兩年就獲得瞭如此高的人氣？Service Mesh又能為企業解決哪些問題？在近日召開的GIAC全球互聯網架構大會上，螞蟻金服高級技術專家黃挺以螞蟻金服的自身實踐為例，深入解讀了Service Mesh。
螞蟻金服高級技術專家黃挺
解決螞蟻金服三大難題
“Service Mesh”最早由開發Linkerd的Buoyant公司提出，2016年9月第一次公開使用該名詞。對於什麼是Service Mesh，Linkerd首席執行官William Morgan曾經給出這樣的解釋：
“服務網格是一個基礎設施層，用於處理服務間通信。雲原生應用有著複雜的服務拓撲，服務網格負責在這些拓撲中實現請求的可靠傳輸。在實踐中，服務網格通常實現為一組輕量級網絡代理，它們與應用程序部署在一起，而對應用程序透明。”
這聽起來還是有些抽象，黃挺用螞蟻金服自身的例子，解讀了Service Mesh的三個主要應用場景：
其一，解決多語言通信的問題，用同一套基礎設施解決不同的語言的通信問題。
眾所周知，SOFA 中間件（Scalable Open Financial Architecture）是螞蟻金服自主研發的金融級分佈式中間件，被螞蟻金服廣泛應用於支付、借貸、信用、基金、保險等全金融場景，支撐螞蟻金服平穩度過歷次“雙11”、“雙12”、“新春紅包”等苛刻考驗。
如今SOFA包含豐富的組件，如SOFA Boot、微服務、數據訪問代理、分佈式事物、消息隊列、分佈式鏈路跟蹤等，基本上包含了分佈式架構所需的各種中間件。
“然而有一個問題是，這些中間件都是用Java寫的”，黃挺指出，當前螞蟻金服技術棧大部分基於Java語言，包含2000+應用和20000+服務；但還有一部分應用是基於NodeJS、C++、Golang和Python語言，要把這些應用融入到SOFA體系，按照傳統的方式，各種語言的客戶端都需要再實現一遍，帶來巨大的工作量，同時要承擔大量風險。
而通過Service Mesh中的Sidecar，服務註冊中心、限流熔斷、動態配置、故障注入等客戶端可以和NodeJS、C++、Golang、Python等具體語言解綁，讓基礎中間件和具體的應用脫離關聯，即“一次實現，搞定所有語言的客戶端”，用一套基礎設施解決不同語言的通信問題，大大節省了工作量。
其二，解決遺留系統融入問題，讓一些遺留系統更好的融入到雲原生體系。
很多傳統企業，包括金融機構往往有著大量的遺留系統，隨著傳統企業雲化的深入，這些遺留系統也需要轉變為雲原生應用。“一種方式是直接把系統代碼重新做一遍，直接用雲原生的方式再寫一遍”，黃挺認為，這種方式雖然比較直接，但是也比較粗暴，有可能在遷移過程當中出現非常多的Bug。
而有了Service Mesh之後，通過Sidecar，遺留系統不經改造，或是隻需要很少的改造，可以非常方便的和雲原生體系融合到一起。
其三，解耦基礎設施團隊和應用研發團隊，增強基礎設施團隊的交付能力和交付速度。
近些年，螞蟻金服的技術架構逐漸從單體應用向服務化架構演進。據黃挺介紹，在單體應用中，通常需要多個團隊去改同一套代碼，一起部署、一起發佈，以及發現問題一起回滾，這個過程非常痛苦。
“應用研發有時候無法很好的理解基礎設施的東西，升級容易出現問題。基礎設施團隊有時候也無法很好地去了解應用研發。應用研發和基礎設施團隊耦合在一起發佈、變更、升級，非常容易出現問題”，黃挺說。
Service Mesh讓螞蟻金服找到了解決問題的方法，通過Service Mesh，應用研發和基礎設施團隊能夠最大程度地解耦，做厚技術中臺，讓中間件可以更快的交付業務需要的能力。
黃挺舉例說，以前SOFARPC中新的能力需要半年甚至一年的時間才能逐步應用於螞蟻金服核心系統，有了SOFA Mesh（螞蟻金服自研的Service Mesh），螞蟻金服可以在一個月的時間內將新的能力快速地提供給所有的業務系統，而不用一個個的去升級業務系統。
螞蟻金服SOFA Mesh自研路
Service Mesh是一個很新的框架，2016年1月 15日，Linkerd 0.0.7版本發佈，這是能夠在Github上看到的第一個Service Mesh。如今，業界流行的Service Mesh框架已經包括Linkerd、Istio和Conduit等。
據黃挺介紹，螞蟻金服在考量業界主流Service Mesh框架的時候，有著兩個明確的需求：其一，能否從螞蟻金服當前的架構下漸進式地演進到Service Mesh架構之下；其二，在性能和穩定性上能否滿足螞蟻金服金融級以及高流量的要求。
經過大規模的驗證，當前業界主流的Service Mesh並不能很好地滿足螞蟻金服這兩個需求。例如，Istio在性能上存有缺陷，無法滿足螞蟻金服高流量和高性能的需求；Linkerd架構不夠開放，資源佔用率較高；Conduit當前版本還不夠成熟，並且基於非常新的RUST語言，精通的人較少。
現有Service Mesh架構均不能滿足需求，而螞蟻金服在傳統服務化架構上已經有十餘年積累，這兩個因素讓螞蟻金服選擇自研Service Mesh——SOFA Mesh。
但“自研”並不代表一定要“從零開始”。“我們沒有從零開始直接構建一個Service Mesh框架，而是借鑑了一些現有Service Mesh框架的優秀經驗，同時儘量遵從整個Service Mesh社區的規範”，黃挺表示，例如，在Control Plane的Pilot以及Auth，SOFA Mesh直接選擇了集成Istio的部分，並且進行了適當地增強。
“SOFA Mesh一切的技術選擇都是能夠讓螞蟻金服穩定、高效、漸進式地演進到 Serivce Mesh 架構下，因此SOFA Mesh在技術上的選擇更加務實，也希望能夠和業界保持技術上的互通”，黃挺強調。
儘管不是從零開始構建，但SOFA Mesh的開發過程也並不簡單。
黃挺回憶說，SOFA Mesh自研過程中最大的困難是第一次上線時候的進度壓力，因為當時有著切實的業務需求：“當時的一個場景需要用C++去調用後端一個用SOFA寫的Java系統，為了滿足業務上的要求，我們集結了應用網絡和中間件團隊，組成了技術攻堅團隊，最終花了差不多兩個月的時間從零開始構建了SOFA Mesh Golang版本的Sidecar，並且對接到SOFA服務化體系下，最終保證了業務的正常上線，在性能以及穩定性上都滿足了業務的需求。”
經過螞蟻金服業務場景的不斷磨練，SOFA Mesh如今已經在螞蟻金服多個場景中落地。據黃挺介紹，SOFA Mesh在螞蟻金服內部更多的被應用於多語言支持，亦被應用於解決內部服務調用的安全以及在能力發佈上的問題，此外也在規劃解決異構體系的通信問題，在螞蟻金服業務中發揮著越來越關鍵的作用。
Mesh的未來——Xmesh
作為一個新興的技術框架，Service Mesh從2016年被提出來，去年迎來了蓬勃發展。不僅是螞蟻金服，谷歌、IBM、華為等業界巨頭已經參與到Service Mesh的研發之中，國內多家互聯網和雲計算企業也開始在Service Mesh進行驗證和投入。
黃挺認為，2018年，隨著雲原生理唸的進一步地被傳播，以及 Kubernetes 等容器編排平臺被更多的公司所採納，Service Mesh 也必將在今年有更好蓬勃地發展。
“我們預計今年會有更多的公司在內部去實踐Service Mesh，也非常期待在業界能夠聽到更多公司的Service Mesh的實踐。從形態上，除了Service Mesh，也會逐步出現其他形式的Mesh，比如Message Mesh或者DB Mesh等等”，對於Service Mesh的未來，黃挺十分樂觀。
而對於螞蟻金服來說，其自研的SOFA Mesh會繼續在內部更多場景下落地，用更多的場景去“磨練”SOFA Mesh。“未來我們也不排除在服務調用上之外的場景做 Mesh，在數據訪問、消息通信上也用上Mesh的場景，以達到在基礎設施上更加統一的目的”黃挺說。
據黃挺透露，螞蟻金服目前也正在緊鑼密鼓地準備SOFA Mesh的開源。SOFA Mesh的誕生結合了業界的先進理念和經驗，而螞蟻金服也希望將SOFA Mesh的成果反饋給社區，推動SOFA Mesh生態的良性發展。
閱讀更多 IT圈兒里人 的文章
