Service Mesh的本質、價值和應用探索

作者 | 李雲

編輯 | 小智

Service Mesh 進入國內技術社區後很快就成了微服務的「新秀」。2018 年 Service Mesh 這一技術可以用「火爆」一詞去形容：Istio 1.0 正式發布、Linkerd 2.0 發布、Knative 基於 Istio 打造等等。

網上介紹 Service Mesh 的資料不少，但關注這一技術的本質、價值的內容卻不多。阿里巴巴高級技術專家李雲帶領團隊在這一領域探索的過程中想清楚了這兩點，並在 QCon 2018 上海站分享了阿里巴巴對 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 之上的所有業務完全可以根據團隊的技術棧特長以更為經濟和高效的方式去發展和探索。

Dubbo 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 層、軟體與硬體的結合發展。

Dubbo Mesh 的進展

目前 Dubbo Proxy 完成了 Dubbo 服務調用統計信息收集的開發工作，這部分代碼已合入了 GitHub 上 Envoy 倉庫的 master 主幹。Dubbo Proxy 全面支持 Dubbo 服務路由的工作正在進行，相信很快這部分代碼將出現在開源社區。

在阿里巴巴集團內部，為了快速落地已經完成 Dubbo over HTTP 技術方案的開發，目前已在兩個多語言場景業務方的環境中完成部署並開始著手性能測試和調優工作。內部落地方案中，需要考慮通過 Nacos 與集團內部的 VIPServer、ConfigServer 集群進行對接去完成服務發現，這些對接工作開源社區無需關注，因為開源的 Nacos 已包含阿里集團內部的服務註冊與發現和配置管理能力。

值得一提，pilot-discovery 目前並非集群化部署，而是與 Dubbo Proxy 一樣進行了下沉。未來在合適的時機會再考慮將之上拉並形成獨立的部署集群。

ServiceMesh 作為微服務「新貴」在 2018 年火爆異常，未來應該也會有更廣闊的應用前景。接下來還有哪些值得投入使用的新技術？持續關注 QCon 北京 2019 應該會有更多啟發。

點一下好看試試微信的新功能？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！