本文作者：至簡，阿裡巴巴進階技術專家，是集團 Service Mesh 方向的重要參與者和推動者。曾出版《專業嵌入式軟體開發——全面走向高質高效程式設計》一書，堅信和倡導軟體設計是軟體品質之根本，并對軟體開發的複雜性本質有着深刻的認識，對如何高質高效實施軟體開發有着自己獨到的見解和方法。
Service Mesh 進入國内技術社群後很快就成了微服務的“新秀”。2018 年 Service Mesh 這一技術可以用“火爆”一詞去形容：Istio 1.0 正式釋出、Linkerd 2.0 釋出、Knative 基于 Istio 打造等等。
網上介紹 Service Mesh 的資料不少，但關注這一技術的本質、價值的内容卻不多。阿裡巴巴進階技術專家至簡和他的團隊在這一領域探索的過程中想清楚了這兩點。
大規模分布式應用的挑戰
微服務軟體架構（microservices）已經被越來越多的企業作為規模分布式軟體開發的首選架構。引入該架構之初是将一個單體應用拆解成多個更小粒度的微服務 (micro-service)，通過 HTTP API 或像 Dubbo 這樣的 RPC 架構将這些服務組裝起來作為整體去提供服務。由于每個微服務足夠地小且功能内聚，是以能很好地解決以往單體應用的開發與釋出困難的問題。即便如此，随着企業的業務發展和人員規模的壯大，不同業務所形成的微服務群之間的協同卻面臨新的挑戰。
在阿裡巴巴内部，RPC 架構由中間件事業部統一開發與維護，以 SDK 形式提供給集團内的其他事業部使用。由于 SDK 與應用邏輯是耦合在同一個程序中的，當 SDK 向前演進所增加的特性并不是某些業務方所需要的時，這些業務方就沒有動力配合中間件事業部去同步更新自己應用中的 SDK 版本，使得 SDK 在整個集團存在多個版本甚至變成長尾而形成包袱。類似的包袱反過來制約了 RPC 架構自身的演進效率。
當微服務架構是單一程式設計語言獨大（Java 在阿裡巴巴就是這樣的）、不能同步支援好其他多個主流程式設計語言時（比如 C++、Go、Node.js 等）, 就會出現非獨大程式設計語言的 SDK 在特性上嚴重滞後于獨大程式設計語言的，最終影響使用非獨大程式設計語言的業務方以自己最為熟悉的程式設計語言去發展和探索業務。程式設計語言獨大所帶來的好處是多數人的技術棧是一樣的而提高了技術層面的協作效率，但卻無法收獲程式設計語言多樣性所帶來的其他好處。即便同步地對多個程式設計語言的 SDK 進行維護，同樣的特性需要用不同的程式設計語言去實作其成本着實很高。
也許在企業内部統一單一的主流程式設計語言并不會帶來什麼劣勢，但當企業需要通過收購其他公司來擴充自己的商業版圖時就很可能面臨技術棧不統一而帶來業務無法低風險、高效率共存演進的挑戰。當碰到母子公司的技術棧不統一時，在被收購子公司中進行推倒重建基本上是一件業務價值不大的勞命傷财之事。
最後，在微服務軟體架構所主張的拆分手法下，确實可以将每個拆分出來的服務從監管控層面做到足夠的精緻，但這勢必會因為概念抽象不同、團隊成熟度不一緻等原因而使得這些“精緻的煙囪”難以高效無縫協同，最終的結果是軟體功能的易用性、風險的可控性和适應業務變化的靈活性無法做到全局最優。
不難想象，采取強有力的團隊組織形式、技術規範等手段是很難解決以上挑戰的。回歸通過技術途徑去解決技術挑戰才更為有力、有效，這正是 Service Mesh 這一技術可以幫助做好的。
Service Mesh 的形态
Service Mesh 的核心思路與微服務軟體架構的思路是一脈相承的，即通過拆分實作解耦——将 SDK 中頻繁變更的邏輯與業務邏輯分别放到不同的程序中。下圖以 RPC 架構為例示例了這一手法。
拆分之後，服務調用的流量通過技術手段以應用無感的形式導入 sidecar 程序。每個服務程序邊上新增的 sidecar 使得完整的服務調用鍊中用戶端和服務端分别增加了一跳，這是享受 Service Mesh 技術所需付出的成本。
Service Mesh 的挑戰
第一個挑戰來自心智模式需要改變。享受 Service Mesh 所帶來的益處是需要付出成本的，這如同單體應用向微服務軟體架構轉變那樣，核心是成本與收益問題。之是以業内仍有不少人糾結于 Service Mesh 的價值，根本原因在于企業的業務規模是否面臨 Service Mesh 所緻力于解決的那些挑戰，如果沒有則采納 Service Mesh 隻帶來更高的成本而沒有收益。
對于那些服務規模還小的企業，确實沒有必要引入尚處于探索和普及階段的 Service Mesh 的必要。他們可以持續關注業務發展與技術的比對，在合适的時間點去擁抱新技術。
第二個挑戰來自于技術層面，即如何做到增加 sidecar 後的“路徑無損”。具體說來，如何在引入 Service Mesh 的情形下，最大可能地不增加服務的調用延時和消耗更多的 CPU 資源。這是未來需要持續去突破的技術方向。可以預見，突破的途徑無外乎“應用層 + 核心層”或“軟體 + 硬體”。
Service Mesh 的本質
無疑，技術發展是服務于業務價值創造的。在單體應用時代，因為軟體規模、業務複雜度和參與人員數量的持續增大，使得軟體開發和疊代工作因為耦合而舉步為艱，這就有了微服務軟體架構的出現。那時的業務發展效率問題集中展現于人員協同，在微服務軟體架構的需要下産生了 RPC、Messaging 等技術。
當人員的協同問題通過微服務軟體架構得以解決時，随着軟體規模、業務複雜度和參與人員數量的進一步增大，需要更好地解決多個業務（或服務）之間的協同問題，而這是 Service Mesh 這一技術的本質。
Service Mesh 的價值
在 Service Mesh 的形态下，RPC 架構中容易變更的内容被剝離到了 sidecar 程序，之前的胖 SDK 瘦身為隻保留了功能恒定的協定編解碼能力。如此一來，與 RPC 架構演進相關的邏輯幾乎集中在 sidecar 程序中，這就完全可以做到讓使用 RPC 架構的業務方無感覺地對之進行更新與維護。最終的結果是，業務與 RPC 架構可以做到獨立發展與更新，完全消除了之前胖 SDK 所導緻的兩者互相制約發展的不利局面。這一解耦所帶來的好處是，使用 RPC 架構的業務團隊可以更加聚焦于業務開發本身，這正是發揮技術價值應達到的境界。
不難看出，Service Mesh 很好地解決了以往 RPC 架構多語言 SDK 的問題。雖然在 Service Mesh 下仍然需要 SDK，但由于 SDK 中的功能是相當穩定的，不存在應付頻繁變更所帶來的長期維護成本問題。由于 sidecar 是以程序的形式存在的，是以完全不關心使用 RPC 架構的業務邏輯是用什麼程式設計語言實作的，隻需實作一次而沒有讓人感到無聊的多語言特性對齊問題，将 RPC 架構技術團隊的人力釋放出來做更有價值的事。
也因為 sidecar 是以獨立程序的形式存在，當出現因為公司收購所面臨的母子公司技術棧不一緻問題時，可以将 sidecar 部署在兩個技術棧的銜接處，由 sidecar 通過協定轉換等形式完成兩個異構服務架構的連接配接，為異構服務架構的漸進式融合發展提供了可能，很好地緩解了短期高強度技術改造所面臨的技術風險和對業務發展的拖累。
服務架構易變的功能剝離到了 sidecar 後，意味全網的服務流量治理能力可以通過 sidecar 進行收口——sidecar 自身的版本全網一緻、流量規則與執行政策一緻、監控口徑一緻，等等。諸多的“一緻”将實作全網服務治理的體系化監管控，使得 Service Mesh 成為微服務軟體架構拆分手法下完成橫向連接配接與限制的強有力技術手段。
如果用一句話來描述 Service Mesh 的話，那就是“階層化、規範化、體系化、無侵入的分布式服務（或應用）治理技術”。
Service Mesh 的終局
延着 Service Mesh 的切分邏輯，不難預見未來 Service Mesh 所形成的終局是一張大網。這個大網是企業統一且唯一的分布式應用治理的基礎設施，其上天然地支援多語言應用的開發。當然，sidecar 是包羅萬象地支援 RPC、DB、Messaging，還是衍生出 RPC sidecar、DB sidecar、Messaging sidecar 是仍需探索的主題。
Service Mesh 的發展路徑
新技術誕生于邏輯上能解決當下所面臨的技術或業務挑戰，但能否真正落地去最大程度地發揮價值卻具有不确定性和模糊性。正因如此，不少新技術出現之時存在各種基于自身立場去解讀和挖掘其背後的價值，當然也不乏各種質疑之聲。所有這一切讓業内對挑戰看得更加透徹，對新技術的探索也愈加高效。
根本上，Service Mesh 的出現并非填補了技術空白，不少公司因為曾經有過相似的探索而給人“換湯不換藥”的感覺，與今天時興的雲計算在十幾、二十年前被稱之為分布式計算、網格計算頗有相似之處。當一項新技術不是給人橫空出世的感覺時，它的運用與采納就會經曆更多的波折，因為沒有它似乎企業的業務發展仍能進行下去。
在經曆了一定的思考和市場感覺後，發現 Service Mesh 真正發揮價值是需要分布式應用大到一定的規模并面臨一開始所提出的那些挑戰，這些在阿裡巴巴集團内部都滿足。最終我将 Service Mesh 的發展劃分成三大階段。
階段一：撬動。新技術被采納的關鍵是它能解決業務當下所面臨的痛點，阿裡巴巴因為 Java 語言一家獨大而使得多語言問題相當突出，這使得小衆的程式設計語言樂于擁抱 Service Mesh 去解決自己維護 SDK 或 SDK 特性老舊的痛點。此外，阿裡巴巴不時通過收購子公司擴大自己的商業版圖，确實經曆了異構服務架構共存演進所帶來的挑戰。
撬動階段讓新技術得以落地而接觸到更多的業務機會并争取到打磨技術的時間視窗，讓 Service Mesh 技術團隊對于需求的了解和把控更加到位。為進入下一發展階段提供可能。
階段二：做透價值滲透。光解決多語言和異構服務架構共存演進并不足以實作大範圍的體系化監管控，需要圍繞集團内部更為豐富的業務場景去挖掘 Service Mesh 的價值，并在探索的過程中尋求技術突破去降低引入 Service Mesh 的成本。當分布式應用的體量特别大時，成本問題将變得備受關注。一旦 Service Mesh 的價值得以做透，還得考慮無縫遷移等使用者體驗使之得以更為友善地應用到更多的業務場景。
階段三：實作技術換代。分布式應用的全局、體系化監管控一定是未來雲原生時代的強訴求。進入這一階段代表技術進入了更高層次的集約發展時期，是償還過去“跑馬圈地”和“野蠻生長”所欠下技術債的重大裡程碑。在這一階段，Service Mesh 将成為企業所有分布式應用的基礎設施，通過這一設施強有力地執行流量灰階、流量排程去保障業務的持續性，讓安全、穩定性問題得以采用一緻性、系統性的方案解決。“生長”在 Service Mesh 之上的所有業務完全可以根據團隊的技術棧特長以更為經濟和高效的方式去發展和探索。
Service Mesh 的發展思路
Dubbo Mesh 是 Service Mesh 在 Dubbo 生态下的落腳點。其發展不僅立足于在阿裡巴巴集團遺留應用場景的包并相容，還将迎合 Kubernetes 已成計算資源編排王者的大勢，讓 Service Mesh 在未來以 Kubernetes Way 去提供概念一緻、體驗一緻的技術産品。
整個 Service Mesh 的發展與探索将走“源于開源，反哺開源，集團内外版本一緻”的思路。希望探索之路少走彎路、與更多的同行攜手前行，成為開源社群的一名積極建設者。
最終的技術選型是采用 Istio 的部分元件（Dubbo Control 控制面）和 Envoy（Dubbo Proxy 資料面）形成阿裡巴巴自己的解決方案。Istio 中的 pilot-discovery 對于平台的抽象便于擴充支援阿裡巴巴最近開源出來的 Nacos 而友善落地，同時為将來集團全面的 Kubernetes 化做好準備。Envoy 的性能與軟體品質在很多生産環境上得到了檢驗，而采用 C++ 能從性能上得到很好的保證，避免有些語言存在 GC（垃圾回收）而帶來的不确定性，也便于将來應用層與 OS 層、軟體與硬體的結合發展。
Service Mesh 的進展
目前 Dubbo Proxy 完成了 Dubbo 服務調用統計資訊收集的開發工作，這部分代碼已合入了 GitHub 上 Envoy 倉庫的 master 主幹。Dubbo Proxy 全面支援 Dubbo 服務路由的工作正在進行，相信很快這部分代碼将出現在開源社群。
在阿裡巴巴集團内部，為了快速落地已經完成 Dubbo over HTTP 技術方案的開發，目前已在兩個多語言場景業務方的環境中完成部署并開始着手性能測試和調優工作。内部落地方案中，需要考慮通過 Nacos 與集團内部的 VIPServer、ConfigServer 叢集進行對接去完成服務發現，這些對接工作開源社群無需關注，因為開源的 Nacos 已包含阿裡集團内部的服務注冊與發現和配置管理能力。
值得一提，pilot-discovery 目前并非叢集化部署，而是與 Dubbo Proxy 一樣進行了下沉。未來在合适的時機會再考慮将之上拉并形成獨立的部署叢集。