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

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!


在過去幾年中,微服務成爲了業界技術熱點,大量的互聯網公司都在使用微服務架構,也有很多傳統企業開始實踐互聯網技術轉型,基本上也是以微服務和容器爲核心。本文將主要介紹微服務架構的概述以及雲原生環境下的 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,用來操控和測量整個網絡。

1

更進一步地說,服務網格是一個專用的基礎設施層,旨在“在微服務架構中實現可靠、快速和安全的服務間調用”。它不是一個“服務”的網格,而是一個“代理”的網格,服務可以插入這個代理,從而使網絡抽象化。在典型的服務網格中,這些代理作爲一個 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)的架構與功能的不斷優化,服務網格將完全取代傳統微服務架構,成爲大小企業微服務化和上雲改造的首選架構。

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-14
本文作者:螞蟻金服分佈式架構
本文來自:“掘金”,瞭解相關信息可以關注“掘金”

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章