火了 2 年的服務網格究竟給微服務帶來了什麼？

本文節選自 ServiceMesher 社區出品的開源電子書《Istio Handbook——Istio 服務網格進階實戰》，做者羅廣明，來自百度。

在過去幾年中，微服務成爲了業界技術熱點，大量的互聯網公司都在使用微服務架構，也有不少傳統企業開始實踐互聯網技術轉型，基本上也是以微服務和容器爲核心。本文將主要介紹微服務架構的概述以及雲原生環境下的 Service Mesh 和傳統微服務應用的區別。

微服務架構概述

微服務架構可謂是當前軟件開發領域的技術熱點，在各類博客、社交媒體和會議演講上的出鏡率很是之高，不管是作基礎架構仍是作業務系統的工程師，對微服務都至關關注，而這個現象與熱度到目前爲止，已經持續了近 5 年之久。

尤爲是近些年來，微服務架構逐漸發展成熟，從最初的星星之火到如今的大規模落地與實踐，幾乎已經成爲分佈式環境下的首選架構。微服務成爲時下技術熱點，大量互聯網公司都在作微服務架構的落地和推廣。同時，也有不少傳統企業基於微服務和容器，在作互聯網技術轉型。

而在這個技術轉型中，國內有一個趨勢，以 Spring Cloud 與 Dubbo 爲表明的微服務開發框架很是普及和受歡迎。然而軟件開發沒有銀彈，基於這些傳統微服務框架構建的應用系統在享受其優點的同時，痛點也越加明顯。這些痛點包括但不限於如下幾點：

• 侵入性強。想要集成 SDK 的能力，除了須要添加相關依賴，每每還須要在業務代碼中增長一部分的代碼、或註解、或配置；業務代碼與治理層代碼界限不清晰。
• 升級成本高。每次升級都須要業務應用修改 SDK 版本，從新進行功能迴歸測試，而且對每一臺機器進行部署上線，而這對於業務方來講，與業務的快速迭代開發是有衝突的，大多不肯意停下來作這些與業務目標不太相關的事情。
• 版本碎片化嚴重。因爲升級成本高，而中間件卻不會中止向前發展的步伐，長此以往，就會致使線上不一樣服務引用的 SDK 版本不統1、能力良莠不齊，形成很難統一治理。
• 中間件演變困難。因爲版本碎片化嚴重，致使中間件向前演進的過程當中就須要在代碼中兼容各類各樣的老版本邏輯，帶着 「枷鎖」 前行，沒法實現快速迭代。
• 內容多、門檻高。Spring Cloud 被稱爲微服務治理的全家桶，包含大大小小几十個組件，內容至關之多，每每須要幾年時間去熟悉其中的關鍵組件。而要想使用 Spring Cloud 做爲完整的治理框架，則須要深刻了解其中原理與實現，不然遇到問題仍是很難定位。
• 治理功能不全。不一樣於 RPC 框架，Spring Cloud 做爲治理全家桶的典型，也不是萬能的，諸如協議轉換支持、多重受權機制、動態請求路由、故障注入、灰度發佈等高級功能並無覆蓋到。而這些功能每每是企業大規模落地不可獲缺的功能，所以公司每每還須要投入其它人力進行相關功能的自研或者調研其它組件做爲補充。

以上列出了傳統微服務框架的侷限性，但這並不意味着它們就一無可取了。在中小企業，採用 Spring Cloud 這樣的傳統微服務框架已經能夠知足絕大部分服務治理的需求，而且藉此快速推動微服務化改造。這些痛點每每是技術發展到必定的程度必然要經歷的階段，這些痛點促使技術不斷髮展、不斷前進。

在衆多熱門技術趨勢中，雲原生的關注度居高不下，不少開發者都對由此興起的一衆技術十分追捧，衆多企業又開始探索雲原生架構的轉型與落地。這一年，中國的開發者們經歷了從關注「雲原生概念」到關注「雲原生落地實踐」的轉變。而 Service Mesh 技術也所以愈來愈火熱，受到愈來愈多開發者的關注，並擁有了大批擁躉。那麼 Service Mesh 是什麼呢？它爲何會受到開發者的關注？它和傳統微服務應用有什麼區別？

Service Mesh 定義

Service Mesh 一詞最先由開發 Linkerd 的 Buoyant 公司提出，並於 2016 年 9 月29 日第一次公開使用了這一術語。William Morgan，Buoyant CEO，對 Service Mesh 這一律念定義以下：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

翻譯成中文以下：

Service Mesh 是一個專門處理服務通信的基礎設施層。它的職責是在由雲原生應用組成服務的複雜拓撲結構下進行可靠的請求傳送。在實踐中，它是一組和應用服務部署在一塊兒的輕量級的網絡代理，而且對應用服務透明。

以上這段話有四個關鍵點：

• 本質：基礎設施層；
• 功能：請求分發；
• 部署形式：網絡代理；
• 特色：透明；

2017 年，隨着 Linkerd 的傳入，Service Mesh 進入國內社區的視野，而且由國內的技術佈道師們翻譯成「服務網格」。

服務網格概述

服務網格從整體架構上來說比較簡單，不過是一堆緊挨着各項服務的用戶代理，外加一組任務管理流程組成。代理在服務網格中被稱爲數據層或數據平面（data plane），管理流程被稱爲控制層或控制平面（control plane）。數據層截獲不一樣服務之間的調用並對其進行「處理」；控制層協調代理的行爲，併爲運維人員提供 API，用來操控和測量整個網絡。

更進一步地說，服務網格是一個專用的基礎設施層，旨在「在微服務架構中實現可靠、快速和安全的服務間調用」。它不是一個「服務」的網格，而是一個「代理」的網格，服務能夠插入這個代理，從而使網絡抽象化。在典型的服務網格中，這些代理做爲一個 sidecar（邊車）被注入到每一個服務部署中。服務不直接經過網絡調用服務，而是調用它們本地的 sidecar 代理，而 sidecar 代理又表明服務管理請求，從而封裝了服務間通訊的複雜性。相互鏈接的 sidecar 代理集實現了所謂的數據平面，這與用於配置代理和收集指標的服務網格組件（控制平面）造成對比。

總而言之，Service Mesh 的基礎設施層主要分爲兩部分：控制平面與數據平面。當前流行的兩款開源服務網格 Istio 和 Linkerd 實際上都是這種構造。

控制平面的特色：

• 不直接解析數據包。
• 與控制平面中的代理通訊，下發策略和配置。
• 負責網絡行爲的可視化。
• 一般提供 API 或者命令行工具可用於配置版本化管理，便於持續集成和部署。

數據平面的特色：

• 一般是按照無狀態目標設計的，但實際上爲了提升流量轉發性能，須要緩存一些數據，所以無狀態也是有爭議的。
• 直接處理入站和出站數據包，轉發、路由、健康檢查、負載均衡、認證、鑑權、產生監控數據等。
• 對應用來講透明，便可以作到無感知部署。

服務網格帶來的變革

那麼服務網格的出現帶來了哪些變革呢？

第一，微服務治理與業務邏輯的解耦。服務網格把 SDK 中的大部分能力從應用中剝離出來，拆解爲獨立進程，以 sidecar 的模式進行部署。服務網格經過將服務通訊及相關管控功能從業務程序中分離並下沉到基礎設施層，使其和業務系統徹底解耦，使開發人員更加專一於業務自己。

注意，這裏提到了一個詞「大部分」，SDK 中每每還須要保留 協議編解碼的邏輯，甚至在某些場景下還須要一個輕量級的 SDK 來實現細粒度的治理與監控策略。例如，要想實現方法級別的調用鏈追蹤，服務網格則須要業務應用實現 trace ID 的傳遞，而這部分實現邏輯也能夠經過輕量級的 SDK 實現。所以，從代碼層面來說，服務網格並不是是零侵入的。

第二，異構系統的統一治理。隨着新技術的發展和人員更替，在同一家公司中每每會出現不一樣語言、不一樣框架的應用和服務，爲了可以統一管控這些服務，以往的作法是爲每種語言、每種框架都開發一套完整的 SDK，維護成本很是之高，並且給公司的中間件團隊帶來了很大的挑戰。有了服務網格以後，經過將主體的服務治理能力下沉到基礎設施，多語言的支持就輕鬆不少了。只須要提供一個很是輕量級的 SDK，甚至不少狀況下都不須要一個單獨的 SDK，就能夠方便地實現多語言、多協議的統一流量管控、監控等需求。

此外，服務網格相對於傳統微服務框架，還擁有三大技術優點：

• 可觀察性。由於服務網格是一個專用的基礎設施層，全部的服務間通訊都要經過它，因此它在技術堆棧中處於獨特的位置，以便在服務調用級別上提供統一的遙測指標。這意味着，全部服務都被監控爲「黑盒」。服務網格捕獲諸如來源、目的地、協議、URL、狀態碼、延遲、持續時間等線路數據。這本質上等同於 web 服務器日誌能夠提供的數據，可是服務網格能夠爲全部服務捕獲這些數據，而不只僅是單個服務的 web 層。須要指出的是，收集數據僅僅是解決微服務應用程序中可觀察性問題的一部分。存儲與分析這些數據則須要額外能力的機制的補充，而後做用於警報或實例自動伸縮等。
• 流量控制。經過 Service Mesh，能夠爲服務提供智能路由（藍綠部署、金絲雀發佈、A/B test）、超時重試、熔斷、故障注入、流量鏡像等各類控制能力。而以上這些每每是傳統微服務框架不具有，可是對系統來講相當重要的功能。例如，服務網格承載了微服務之間的通訊流量，所以能夠在網格中經過規則進行故障注入，模擬部分微服務出現故障的狀況，對整個應用的健壯性進行測試。因爲服務網格的設計目的是有效地未來源請求調用鏈接到其最優目標服務實例，因此這些流量控制特性是「面向目的地的」。這正是服務網格流量控制能力的一大特色。
• 安全。在某種程度上，單體架構應用受其單地址空間的保護。然而，一旦單體架構應用被分解爲多個微服務，網絡就會成爲一個重要的攻擊面。更多的服務意味着更多的網絡流量，這對黑客來講意味着更多的機會來攻擊信息流。而服務網格偏偏提供了保護網絡調用的能力和基礎設施。服務網格的安全相關的好處主要體如今如下三個核心領域：服務的認證、服務間通信的加密、安全相關策略的強制執行。

服務網格帶來了巨大變革而且擁有其強大的技術優點，被稱爲第二代「微服務架構」。然而就像以前說的軟件開發沒有銀彈，傳統微服務架構有許多痛點，而服務網格也不例外，也有它的侷限性。

• 增長了複雜度。服務網格將 sidecar 代理和其它組件引入到已經很複雜的分佈式環境中，會極大地增長總體鏈路和操做運維的複雜性。
• 運維人員須要更專業。在容器編排器（如 Kubernetes）上添加 Istio 之類的服務網格，一般須要運維人員成爲這兩種技術的專家，以便充分使用兩者的功能以及定位環境中遇到的問題。
• 延遲。從鏈路層面來說，服務網格是一種侵入性的、複雜的技術，能夠爲系統調用增長顯著的延遲。這個延遲是毫秒級別的，可是在特殊業務場景下，這個延遲可能也是難以容忍的。
• 平臺的適配。服務網格的侵入性迫使開發人員和運維人員適應高度自治的平臺並遵照平臺的規則。

服務網格的百花齊放

ServiceMesher 社區從成立以來，舉辦過九場線下 Meetup 以及一場線上 Virtual Meetup，來自螞蟻集團、網易、阿里集團、新浪、美團、百度等一線互聯網公司分別都分享了各自公司關於服務網格的設計、實踐與落地挑戰，業界知名技術大會，也常常能看到大廠的專家與架構師分享服務網格落地相關的主題。可謂是百花齊放，百家爭鳴！這些技術方案不外乎三種：其一，借鑑服務網格通訊代理的思想，基於公司內部服務框架改革而來，強依賴內部 RPC 框架與協議，僅適用於本公司的服務網格技術方案；其二，基於服務網格開源框架 Istio 與 知名數據面開源項目 Envoy 進行改版，以適配公司內部通訊與安全協議，兼容內部註冊中心與配置中心，具備必定普適性的企業級服務網格解決方案；其三，自研數據面（如螞蟻集團的 MOSN），或者徹底自研數據面與控制面，去除外部依賴，支持快速迭代與自由擴展，追求實際業務收益最大化。

然而，各大廠對服務網格的探索有一段時間了，實際的大規模落地案例卻很少。咱們不由反思，火了2年的服務網格究竟給微服務帶來了什麼？咱們很難在此刻去斷定上述三個方案的優劣，可是有一點，服務網格做爲第二代微服務框架的地位是一向且明確的。此外，無論直接採用開源方案仍是徹底自研，知名開源項目體現出來的架構思想與理念值得全部雲原生技術人員學習和參考。固然開源項目也須要你們共建，但願更多大廠內部的優秀實踐能不斷反饋到社區裏面來，共同促進服務網格的發展與繁榮。

總結

本文介紹了微服務架構的發展，以及服務網格的概念、服務網格相對於傳統微服務架構的優缺點，對於後者，須要讀者們辯證地去看待。從架構演進路徑來看，從最先期的巨石單體（Monolithic）到分佈式（Distributed），再到微服務（Microservices）、容器化（Containerization）、容器編排（Container Orchestration），最後到服務網格（Service Mesh）、無服務器（Serverless）。而服務網格正是這一演進路徑中，相當重要的一環。

展望將來，Kubernetes 正在爆炸式發展，它已經成爲企業綠地應用的容器編排的首選。若是說 Kubernetes 已經完全贏得了市場，而且基於 Kubernetes 的應用程序的規模和複雜性持續增長，那麼就會有一個臨界點，而服務網格則將是有效管理這些應用程序所必需的。縱使前路漫漫，可是隨着服務網格技術的持續發展，其實現產品（如 Istio）的架構與功能的不斷優化，服務網格將徹底取代傳統微服務架構，成爲大小企業微服務化和上雲改造的首選架構。

本文做者

羅廣明，百度高級研發工程師，開源項目與雲原生技術愛好者，ServiceMesher 社區治理委員會核心成員，雲原生社區聯合創始人，對微服務架構、模型、中間件有深刻研究。

本文來源

本文節選自 ServiceMesher 社區出品的開源電子書《Istio Handbook——Istio 服務網格進階實戰》，在線瀏覽地址：https://www.servicemesher.com/istio-handbook