簡介：本文將主要介紹微服務架構的概述以及云原生環境下的 Service Mesh 和傳統微服務應用的區別。

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

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

微服務架構概述

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

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

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

• 侵入性強。想要集成 SDK 的能力，除了需要添加相關依賴，往往還需要在業務代碼中增加一部分的代碼、或注解、或配置；業務代碼與治理層代碼界限不清晰。
• 升級成本高。每次升級都需要業務應用修改 SDK 版本，重新進行功能回歸測試，并且對每一臺機器進行部署上線，而這對于業務方來說，與業務的快速迭代開發是有沖突的，大多不愿意停下來做這些與業務目標不太相關的事情。
• 版本碎片化嚴重。由于升級成本高，而中間件卻不會停止向前發展的步伐，久而久之，就會導致線上不同服務引用的 SDK 版本不統一、能力參差不齊，造成很難統一治理。
• 中間件演變困難。由于版本碎片化嚴重，導致中間件向前演進的過程中就需要在代碼中兼容各種各樣的老版本邏輯，帶著 “枷鎖” 前行，無法實現快速迭代。
• 內容多、門檻高。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

原文鏈接：https://developer.aliyun.com/article/768433?

版權聲明：本文中所有內容均屬于阿里云開發者社區所有，任何媒體、網站或個人未經阿里云開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式復制發布/發表。申請授權請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發者社區協議授權的媒體、網站，在轉載使用時必須注明"稿件來源：阿里云開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：developer2020@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的火了 2 年的服务网格究竟给微服务带来了什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。