隨着微服務架構在互聯網企業的廣泛實踐，新一代微服務開發技術悄然興起， Service Mesh 便是其中之一。根據 Linkerd CEO Willian Morgan 對 Service Mesh 的定義：Service Mesh 是一個基礎設施層，用於處理服務間通信。雲原生應用有着複雜的服務拓撲，Service Mesh 保證請求可以在這些拓撲中可靠地穿梭。在實際應用當中，Service Mesh 通常是由一系列輕量級的網絡代理組成的，它們與應用程序部署在一起，但應用程序不需要知道它們的存在。
這個定義聽起來有點繞，如何簡單定義一下 Service Mesh 呢？美團點評基礎架構團隊技術專家郭繼東認爲 Service Mesh 屬於受中心化管控的服務間通信基礎設施層，將業務與基礎設施進一步解耦的新一代雲原生微服務架構模式，其最關鍵的部分是將非業務的功能下沉到通用的基礎設施層，是推進雲原生體系具備高度移植性、易用性及彈性能力建設的關鍵一環。
Service Mesh 的適用場景
針對 Service Mesh 的理念及產品有很多，不同產品解決的問題及建設目標也會有所差異，但總體而言，郭繼東認爲 Service Mesh 主要是用來解決以下問題的：
將基礎設施與業務隔離開促進彼此迭代效率的提升；
Kubernetes 在應用生命週期管理方面很成熟，但尚不具備在服務流量粒度進行調度及管理的能力，Service Mesh 可以填補這個空白並協同組建雲原生的微服務治理體系；
提升基礎設施及應用的可靠性、易用性、可伸縮性。
如果企業開始實踐 Service Mesh，那麼會給企業各部門人員帶來哪些變化呢？郭繼東表示：“對業務開發人員而言，Service Mesh 會帶來更全面、靈活的服務運營支撐能力，協助他們更好的應對服務化或微服務帶來的複雜性；對架構師而言，Service Mesh 會爲他們的技術決策提供更多的選擇和更少的約束，這得益於 Service Mesh 促進基礎設施的簡化與全方位運營能力的提升；對運維人員而言，Service Mesh 解耦了研發與運維，運維人員可以更加專注底層設施能力的建設和運維效率的提升，如減少對 Nginx、LVS 等各類複雜配置的維護成本等。”
當然，在企業所有人員中，基礎研發同學是最需要重點關注 Service Mesh 的，因爲基礎架構可以基於 Service Mesh 擴大微服務治理的功能及語言覆蓋範圍，這非常有益於技術標準化；Service Mesh 會爲工程效率團隊帶來新的思路和方向，使得包含構建、測試、發佈的流水線更高效和可靠；RPC 及 Http 外的基礎設施如存儲、MQ 團隊也可以積極關注業界動態並積極探索，Service Mesh 是一種架構模式，未來應用場景很可能並不侷限於服務間通信，而是覆蓋更多類型的網絡通信設施。
美團點評的 Service Mesh 實踐
美團點評的 Service Mesh 建設開始於 2018 年底，在 2019 年 5 月底進行了線上少量業務的試點。據瞭解，美團點評內部的 Java 語言棧服務治理體系相對完善和統一，承載了上萬應用日均萬億級的調用，覆蓋了公司 90% 以上的服務，在治理能力方面，路由策略比 Istio 更爲精細，也有完善的分佈式鏈路追蹤系統、立體化監控系統、全鏈路壓測系統等設施。但美團點評的微服務治理也存在一些侷限，那就是除了 Java，其它語言對應的治理體系相對薄弱。
基於這樣的微服務治理現狀，美團點評的 Service Mesh 實踐主要是與 OCTO 系統進行深度打通，通過 Service Mesh 將現有的治理能力開放給基礎設施薄弱的語言棧、通過解耦業務與基礎設施進一步提升業務迭代效率、支持新合併的異構技術棧公司更便捷融入美團點評現有治理體系，同時也在嘗試通過中心化能力實現全局最優治理。
在技術選型方面，美團點評在儘量保持現有體系的架構下，通過自研技術持續演進，數據層是基於 Envoy 進行了二次開發，而控制層則是進行了完全自研。爲什麼會是這樣的技術選型呢？郭繼東表示主要是出於三個方面的考慮：“一是因爲 Envoy 已經幾乎成爲數據面的事實標準，其 xDS 模型和 IO 模型可以滿足 sidecar 的需求；二是 Istio 的 API 尚不穩定，美團點評的初期目標是對齊現有全部的治理能力，Istio 現有能力及擴展性不能很好的支撐；三是美團點評現有的治理體系較爲完善且各個系統都經歷了真實業務場景的充分考驗，Istio 深度依賴的 Kubernetes 及 Etcd 現支撐的集羣規模並不能滿足當前的需求。”
郭繼東把美團點評的 OCTO-Mesh 建設分爲了四個階段：
第一階段：實現了 OCTO-Mesh 的數據面與控制面的 MVP 版本，整體打通 Service Mesh 與 OCTO，進行小範圍試點，驗證可行性；
第二階段：全面對齊 OCTO 現有的治理能力，並在多種語言業務應用試點，具備新融入公司快速切換技術棧能力；
第三階段：實現 OCTO-Mesh 對業務接入透明，具備極高的穩定性支撐核心業務高效運營，實現全局中心化更靈活治理能力建設三個目標，在這個前提下核心業務廣泛接入 OCTO-Mesh；
第四階段：分佈式應用完全不感知服務發現、路由、集羣容錯、安全等問題，但這需要 OCTO-Mesh 協同其他基礎設施共同演進纔有可能達到。
據郭繼東介紹美團點評的 OCTO-Mesh 仍處於探索階段，在整個建設過程中的難點集中在與現有體系的兼容性和穩定性這兩個方面。
兼容性遇到的問題及解決方法
問題一：Envoy 的 xDS 並不能支撐 OCTO 精細複雜的路由策略，衆多核心治理能力 Istio 也尚不具備，業務切換成本高。
解決方法：增強 xDS 語義並增加多項自定義 DS，提升靈活性的同時自研對齊現有功能，升級一次組件版本便做到無感知升級。
問題二：絕大部分治理子系統的存儲及架構呈現異構特性且並不綁定 Kubernetes 與 Etcd。
解決方法：我們在控制層做了架構統一工作，通過統一接入中心使得各異構系統或平臺可以快速接入並在數據面逐漸豐富能力，進而實現服務註冊、服務發現、路由、負載均衡、安全控制、全鏈路壓測、分佈式鏈路追蹤、限流、斷路器、故障演練等能力打通和在 Mesh 體系的落地。
問題三：性能與協議兼容性。
解決方法：爲了兼顧性能與協議兼容性，美團點評摒棄了 iptables 方案，而是將 SDK 與 Sidecar 間的通信統一改爲 UNIX Domain Socket，並升級了公司通用的協議，提升性能的同時解決 Mesh 模式和非 Mesh 模式應用通信的兼容問題。
穩定性方面遇到的問題及解決方法
問題一：OCTO 承載着萬級應用的日均超萬億調用量，這個量級下參考 Istio 模式會對控制面及後端協作的命名服務等系統造成巨大壓力，同時較難水平擴展。
解決方法：我們設計了超大規模服務註冊發現應對機制及多級緩存機制解決大規模集羣場景下對協作系統的壓力。
問題二：Istio、Kubernetes 在大規模集羣的能力尚有所欠缺。
解決方法：基於獨立的第三方服務用於管理控制面節點的服務註冊與發現，通過數據面與控制面間連接的“會話粘滯”等手段來解決 Istio 在大規模集羣能力上的乏力。
問題三：技術棧大範圍升級的同時需要保證業務穩定性。
解決方法：建設了完善的實時 Mesh 與非 Mesh 模式切換能力，優先保證業務穩定性。
“通過 OCTO-Mesh 建設整體提升了美團點評的研發效率，並降低了企業成本，治理能力層面能夠更好的支撐多元語言棧的技術選型，促進基礎設施標準化。”郭繼東表示：“對技術團隊而言，OCTO-Mesh 可以帶來更靈活運營能力及更高的研發效率，例如過去需要發佈才能使用的特性，現在只需 OCTO-Mesh 升級即可使用，過去分散化架構無法實現的功能，現在可以在中心化架構體系實現。除此之外，服務治理的覆蓋率也更廣泛，異構技術棧、非 Java 應用都可以接入美團點評的技術體系。”
Service Mesh 的技術選型
Service Mesn 最早是由開發 Linkerd 的 Buoyant 公司提出，並在內部使用。2016 年 9 月 29 日，Service Mesh 第一次被公開使用。2017 年，隨着 Linkerd 的傳入，Service Mesh 才進入國內技術社區的視野… 可以說，Service Mesh 在整個技術領域還是一個“新兵”，企業實踐也基本處於初級階段。
什麼樣的企業應用場景適合使用 Service Mesh 呢？郭繼東認爲以下三種場景比較合適：
-
業務部署在主流公有云上的企業，可以大膽嘗試 Service Mesh，依託於大廠的技術沉澱和穩定性保障能力，往往投入低的同時也能提升研發及運營效率。
-
私有云基礎設施建設處於早期階段，這類企業往往體量不大，建議立足於開源項目完善整個治理體系建設，注重社區親和性。
-
私有云基礎設施完備且有獨立自研能力的企業，可以基於開源項目二次開發或自研爲主，同時考慮和業界規範的兼容性，長久的收益是兼得 Service Mesh 和微服務治理體系的優勢，但這個週期往往較長，對技術決策的把控要求也很高。
在技術選型方面，目前業界主流的 Service Mesh 框架主要有三個，分別是 Istio、Linkerd 和 Linkerd 2（原爲 Conduit），這三種框架各有利弊，可根據具體情況來選擇。
-
Istio 是由 Google、IBM 和 Lyft 發起的開源的服務網格項目，雖然尚未加入 CNCF，但在業界受衆最多，也被認爲最有前景的 Service Mesh 產品，大有成爲事實標準的趨勢。Istio 功能豐富強大，xDS 協議及 Mixer 設計優秀，但其仍處於早期版本，距離成熟還有很長的路要走，此外性能也是 Istio 被詬病的最主要問題。
-
Linkerd 是由 Buoyant 2016 年推出的，用 Scala 語言實現的開源項目。最大的優勢是支持主機或虛擬機共享實例部署，不與 Kubernetes 綁定對使用環境約束較小，資源佔用也會小些，同時較爲成熟穩定。但共享實例異常時對所有服務都會造成影響，在微服務模式下影響更大，另外 Scala 並不適合做基礎組件，吃內存嚴重和 GC 問題對吞吐量和性能都很不友好。
-
Linkerd 2，即原來的 Conduit，數據層面使用 Rust 語言實現，控制層面使用 Golang 實現。Linkerd 2 的配置較 Istio 更簡單，整體性能及資源佔用情況也都比 Istio 更好，但 Rust 語言生態很不完善受衆也較小，國內基本呈現觀望態度。
當然，Service Mesh 實踐並非只有益處，肯定也存在風險。在郭繼東看來，雖然不同企業容器化和 Service Mesh 技術選型會有一定的差異，但是這些風險都應該重視起來，並且在大規模落地前，一定要進行充分的容災切換能力建設及實操演練：
-
技術棧大範圍調整帶來的穩定性風險都是最大的挑戰，誇張點說，這就好比給行進中的高鐵換輪子；
-
Service Mesh 體系所有的流量都穿過 Sidecar，在其餘設施不變的情況下，性能損耗是不可避免的，如果是服務容量接近瓶頸的系統可能會造成雪崩。
-
Service Mesh 技術棧是非常複雜的，任何一個小功能（如路由、安全等）的異常都可能會造成嚴重的服務中斷。
Service Mesh 的應用難點
目前國內企業較爲完善的治理系統基本都是重度依託於微服務框架的。在這種情況下，應用 Service Mesh 勢必需要做出較大改動，至少需要將服務發現、路由等功能遷移到 Sidecar 中。
如果是基礎架構不完善的企業，尤其是服務化和容器化不完善，在實踐過程中會有很大阻力。郭繼東並不建議這類企業貿然應用 Service Mesh：“Istio 雖有成爲事實標準的趨勢，但國內以螞蟻金服、華爲、騰訊爲代表的探索路徑差異非常大，說明技術體系仍不成熟。企業想擁抱 Service Mesh，往往需要深度自研或二次改造，這就會帶來不可預期的問題，風險把控往往比基礎能力完善要難的多，而且切換 Service Mesh 技術棧的挑戰不見得比從 0 到 1 引入 Service Mesh 的挑戰小。另外，Istio 的 API 尚不算穩定，尤其是對第三方系統的適配能力並不強，並且 Service Mesh 競品（Linkerd/Linkerd2、Envoy）同時進入 CNCF，這說明了新生事物的不確定性，標準化之路可能還很遙遠，大量的投入可能會付諸東流。”
如果是基礎架構較爲完善的企業，憑藉紮實的技術沉澱大可一試，但郭繼東表示這類企業仍需把控好技術方向及技術決策，深度調研結合技術棧現狀。
另外，如果企業是在原有技術棧的基礎上引入 Service Mesh，從實際的應用實踐情況來看，往往會存在以下 4 種問題：
-
標準的不確定性引發重複建設的風險；
-
Service Mesh 模式在業務每次遠程調用增加 1 跳至 2 跳時，會帶來性能損耗，一條實際的調用鏈路可能包含多次遠程調用，性能損耗會被明顯放大；
-
與基礎技術體系融合的難度很大，國內衆多企業的服務通信框架及治理系統技術棧往往不是雲原生優先支持的 gRPC 和 HTTP，在 RPC 框架不兼容的背景下改造成本和挑戰非常大；
-
基礎設施與業務解耦帶來的複雜性對運營系統的易用性和 Service Mesh 的穩定性要求極高，否則排查問題時很可能會面臨根本無從下手的情況。
國內 Service Mesh 早期實踐基本分爲先建設數據層後建設控制層和同時建設兩類，從後續發展看，隨着對服務運營能力的要求的提高，控制層會越來越重要。在實際落地方面，衆多企業都在積極探索私有云建設，也有很多通過 Service Mesh 提供治理能力的案例。在現有開源產品方面，郭繼東認爲未來發展趨勢會逐漸平緩，但 Service Mesh 勢必會和更多種類的雲原生系統深度集成。
採訪嘉賓
郭繼東，美團點評基礎架構團隊技術專家，先後深度參與了美團點評服務治理系統 OCTO 的演進與 Service Mesh 的探索與落地。目前專注於服務架構、大規模分佈式服務治理、Service Mesh、性能優化等方向。致力於爲多元業務提供標準化、高可用、高可靠的服務治理解決方案。曾就職於百度鳳巢商業平臺部，擁有豐富的高可用架構設計經驗。