架構師成長之路也該瞭解的新一代微服務技術-ServiceMesh（上）

itxiaoshen發表於2022-03-24
架構微服務

架構演進

發展歷程

我們再來回顧一下架構發展歷程，從前往後的順序依次為單機小型機->垂直拆分->叢集化負載均衡->服務化改造架構->服務治理->微服務時代

  • 單機小型機：採用典型的單機+資料庫模式，將所有功能寫在一個應用程式進行集中部署。

image-20220323103251645

  • 垂直拆分：隨著應用的日益複雜和多樣性，對系統容災、伸縮和業務響應能力有了更高的要求。單機小型機架構中如果小型機和資料庫任何一個出現故障或當機，整個系統都會奔潰；若某個板塊的功能需要更新，那麼整個系統也需重新發布，顯然這在業務快速發展的萬物網際網路時代是不被允許的。需要將系統進行拆分，拆分為多個子應用。
    • 優點：應用和應用解耦，系統容錯提高了，也解決了獨立應用釋出的問題。

image-20220323104020272

  • 叢集化負載均衡：隨著使用者數量的增加，單個小型機的計算能力依舊是杯水車薪，無法應對業務的增加的需要。且小型機的價格比較昂貴，維護成本較高。在此時更優的選擇是採用多臺PC機部署同一個應用的方案，考慮到客戶端不知道那個請求需要落在哪一個後端PC應用上，因此引入負載均衡的機制。負載均衡思想是對外暴露一個統一的介面，根據使用者請求進行相應規則的轉發，而這樣後端的應用可以根據流量的大小進行動態擴容或者成為水平擴充套件。國內阿里巴巴在2008年提出去IOE（也即為IBM小型機、Oracle資料庫、EMC儲存），全部改為叢集負載均衡架構，到2013年最後一批IBM小型機下線。

    • 負載均衡主要分為硬體層面和軟體層面均衡：
      • 硬體層面負載均衡常用的如F5。
      • 軟體負載均衡如LVS、Nginx、Haproxy。
    • 優點：在垂直拆分優點基礎上增加水平擴充套件來支援大流量業務。

    image-20220323140651815

  • 服務化改造架構：雖然有垂直拆分，但是拆分之後發現論壇和聊天室中有重複功能，比如登入、使用者註冊、發郵件等等，重複功能會造成資源的浪費，因此服務化改造會把重複的功能抽取出來做成Service服務的形式來呼叫，為了解決服務之間的相互呼叫就有了RPC（遠端呼叫）的通訊協議，作用就是讓服務之間的呼叫就像本地呼叫一樣的簡單。

    • 優點：在前面基礎解決業務重用的問題。

    image-20220323141921426

  • 服務治理：隨著業務增加，基礎服務也越來越多，服務之間呼叫關係越來越錯綜複雜，對此有了服務治理的需求。服務治理基本要求如下，基於Java技術棧在這一階段典型的框架有Dubbo，預設採用Zookeeper作為註冊中心。

    • 當服務數量幾十上百個的時候，需要對服務有動態的感知，因此引入註冊中心。
    • 當服務的呼叫鏈路很長的時候如何實現鏈路的監控。
    • 單個服務的異常如何能避免整條鏈路的異常或雪崩，需要考慮熔斷、限流、降級等機制。
    • 服務的高可用，服務負載均衡。

  • 微服務時代:微服務希望一個只負責一個獨立的功能並可以做到獨立部署和運維。比如使用者中心，對於為服務來說還可以分為賣家服務、賣家服務、商家服務等。基於Java技術棧這一階段典型的代表就是SpringCloud，預設使用HTTP協議作為RPC，增加分散式配置中心、分散式事務、分散式訊息佇列等融合。

    • Spring Cloud Alibaba元件：
      • Nacos:服務註冊和發現、配置中心:可以向阿里巴巴Nacos註冊例項，客戶端可以使用spring管理的bean發現例項。支援Ribbon，通過Spring Cloud Netflix的客戶端負載均衡器，分散式配置使用阿里巴巴Nacos作為資料儲存。
      • Sentinel:流量控制和服務降級:阿里巴巴Sentinel流量控制、斷路和系統自適應保護。
      • Seata:一種高效能、易於使用的分散式事務解決方案，適用於微服務架構。解決微服務中的分散式事務問題。
      • Dubbo與Spring Cloud Alibaba的整合:Dubbo為Apache Dubbo 是一款高效能、輕量級的開源服務框架，提供了六大核心能力：面向介面代理的高效能RPC呼叫，智慧容錯和負載均衡，服務自動註冊和發現，高度可擴充套件能力，執行期流量排程，視覺化的服務治理與運維。
    • Spring Cloud Netflix Ribbon：客戶端負載均衡器，Nacos客戶端中已預設整合Ribbon。
    • Spring-Cloud-OpenFeign：是一個宣告式的偽RPC（Feign英文意思為“假裝，偽裝，變形”）的REST客戶端，它用了基於介面的註解方式，可以以Java介面註解的方式呼叫Http請求，從而將請求模組化。
    • Spring Cloud Gateway：提供了一個在Spring WebFlux上構建API閘道器的庫，旨在提供一種簡單而有效的方式來路由到api，併為它們提供橫切關注點，如安全性、監控/指標和彈性。
    • Apache SkyWalking：國產優秀開源的分散式系統的應用程式效能監控工具，特別為微服務，雲本地和基於容器(Docker, Kubernetes, Mesos)架構設計。

Service Mesh時代

上一張接著微服務時代繼續說，之前文章也介紹SpringCloud Alibaba一站式微服務解決方案入門示例（後續文章我們會詳細介紹相關的微服務元件），有了一定理解，但這些微服務存在以下問題，因此可以說Service Mesh概念提出的初衷就是來解決這些問題的。

  • 侵入性太強：比如基於Java技術棧主流的SpringCloud Alibaba也需要引用各類微服務元件如配置中心、註冊中心、閘道器、限流、分散式事務等starter依賴，有些還需在啟動類開啟使用、配置檔案配置、註解等，與我們微服務業務模組耦合繫結在一起，有可能因為微服務元件的版本相容問題影響整個微服務模組。
  • 多語言支援：不能同時支援多種開發語言，對於團隊要求統一語言太苛刻。
  • 學習框架成本太高：雖然目前如SpringCloud Alibaba對於使用者來說還算比較簡單的，但是還是需要理解微服務架構、元件原理和應用、開發等，一整套下來學習成本也很高。
  • 框架版本升級：主流微服務框架目前更新迭代速度較快，適應版本升級帶來額外的工作量。

Service Mesh解決思路

  • 本質上就是要解決服務之間的通訊問題，不應該將非業務的程式碼融入業務程式碼當中。服務之間通訊如服務發現、負載均衡、版本控制等等。
  • 客戶端發起請求要能順利到達對應的服務，在這中間的網路通訊要儘量和業務程式碼無關。

簡單介紹Sidecar

Sidecar降低了與微服務架構相關的複雜性，並且提供負載均衡、服務發現、流量管理、電路中斷、故障注入等特點。該種模式允許嚮應用無侵入的新增多種功能，避免為滿足第三方元件需求而對應用新增額外的配置程式碼。其借鑑了Proxy代理模式，代表產品有 Lyft 構建的Envoy、Netflix的Prana。

image-20220323171444172

Sidecar為了通用基礎設定而設計，服務的業務程式碼與Sidecar繫結在一起，每個服務配置一個Sidecar代理，每個服務所有流量都要經過Sidecar,控制服務流量的進出，Sidecar幫我們遮蔽通訊的細節，開發人員只需關注業務程式碼實現，通訊的工作就交由Sidecar處理，做到與技術框架無侵入性。

Envoy

Envoy是一個開源的邊緣和服務代理，專為雲本地應用設計用於雲原生應用，雲原生基金會 CNCF 專案。 最初是在 Lyft 構建的，它是為單一服務和應用程式設計的高效能 C++ 分散式代理，以及為大型微服務 Service Mesh 體系結構設計的通訊匯流排和通用資料平面。目前最新版本為1.21.1.特點：

  • Envoy是為大型現代面向服務架構設計的L7代理和通訊匯流排，Envoy是一個自包含的程式，旨在與每個應用程式伺服器一起執行。所有的envoy都形成了一個透明的通訊網路，每個應用程式在其中向本地主機傳送和接收訊息，並且不知道網路拓撲。

    • 適用於任何應用語言。一個Envoy部署可以在Java、c++、Go、PHP、Python等之間形成一個網格。面向服務的體系結構使用多個應用程式框架和語言越來越普遍。
    • 可以在大型面向服務體系結構的整個基礎設施上透明地快速部署和升級，解決部署庫升級的痛苦問題。

  • L3/L4 filter architecture

  • HTTP L7 filter architecture

  • First class HTTP/2 support

  • HTTP/3 support (currently in alpha):

  • HTTP L7 routing

  • gRPC支援

  • 服務發現和動態配置

  • 執行狀況檢查

  • 負載平衡

  • 前/邊緣代理支援

  • 最好的觀察性

什麼是Service Mesh？

Service Mesh（服務⽹格）是一種控制應用程式不同部分彼此共享資料的方式，旨在以減少管理和程式設計開銷的形式來連線微服務。主要目的是讓開發⼈員更專注的聚焦到業務上，以程式碼無侵入形式實現微服務中的服務發現、服務註冊、負載均衡等常用功能。Service Mesh的核心思想是將為微服務提供通訊服務的這部分邏輯從應⽤程式程式中抽取出來，作為⼀個單獨的程式進⾏部署，並將其作為服務間的通訊代理當服務⼤量部署時，隨著服務部署的Sidecar（邊⻋，很形象的翻譯）代理之間的連線形成⽹格結構併成為了微服務的通訊基礎設施層，承載了微服務之間的所有流量。

特點：基礎設施、雲原生、網路代理、對應用透明

image-20220324164939784

Linked專案

Buoyant公司的Linked為第一個意義上的Service Mesh專案，由Twitter開發，很好結合了K8S的雲原生概念，無侵入業務程式碼就能管理服務的流量，相容K8S提供全部功能。設計思想如下圖：

image-20220323174259506

但Linked部署較為繁瑣，且只是實現資料層面的問題，缺乏對於資料層的管理。國外Service Mesh產品發展還是非常迅猛的，NginxMesh，F5的AspenMesh、HashiCorp的Consul Connect、Kong、AWS的AppMesh和微軟發起的一項標準化各種服務網格介面的倡議SMI。後面我們再來說說Istio-毫無疑問當前最主流的ServiceMesh產品。

國內ServiceMesh發展

這裡我們也提一下國內在ServiceMesh方向上實踐的一些公司，有時間也可以去了解下

  • 螞蟻金服的SofaMesh
  • 騰訊的Tencent Service Mesh Framework,簡稱 TSF Mesh，選擇的Sidecar是Envoy
  • 華為 Mesher 與 ASM
  • 阿里Dubbo Mesh
  • 網易雲輕舟微服務推出的Service Mesh平臺
  • 小紅書ServiceMesh落地與Aeraki 元件優化擴充套件

Istio

概述

Istio官網地址 https://istio.io/

Istio GitHub地址 https://github.com/istio

ServiceMesh：現代應用程式通常被架構為分散式的微服務集合，每個微服務集合執行一些的業務功能。服務網格是一個專用的基礎設施層，可以新增到應用程式中。它允許您透明地新增如可觀察性、流量管理和安全性等功能，程式碼無侵入。“服務網格”描述了用於實現該模式的軟體型別，以及在使用該軟體時建立的安全或網路域。

隨著分散式服務(比如基於kubernetes的系統)的部署規模和複雜性的增長，它可能會變得更難理解和管理，如服務發現、負載平衡、故障恢復、指標和監控。服務網格還可處理更復雜的操作需求如A/B測試、金絲雀部署、速率限制、訪問控制、加密和端到端身份驗證。

服務到服務通訊使得分散式應用程式成為可能，隨著服務數量的增長，在應用程式叢集內部和跨應用程式叢集路之間的通訊變得越來越複雜，Istio有助於降低這些部署的複雜性，並減輕開發團隊的壓力。

Istio是由Google、IBM和Lyft共同發起的開源服務網格專案，由go語言編寫，但又不僅僅是服務網格那麼簡單。Istio的目的是解決當單體應用程式向分散式微服務架構過渡時開發人員和運營商所面臨的挑戰。Istio透明地分層到現有的分散式應用程式上，通過在部署的每個應用程式中新增代理“sidecar”，Istio允許您在網路中程式設計應用程式感知的流量管理、不可思議的可觀察性和健壯的安全功能；能夠成功且高效地執行分散式微服務架構，並提供保護、連線和監控微服務的統一方法。Istio提供了對整個服務網格的行為洞察和操作控制的能力，以及一個完整的滿足微服務應用各種需求的解決方案。

為何使用？

Istio 可以輕鬆地建立一個已經部署了服務的網路，比如實現負載平衡、服務到服務身份驗證和監視的服務的程式碼只需很少更改甚至無需更改。Istio極大的減少了應用程式程式碼，底層平臺和策略之間的耦合，使微服務更容易實現了！通過在整個環境中部署一個特殊的 sidecar 代理為服務新增 Istio 的支援，而代理會攔截微服務之間的所有網路通訊，然後使用其控制平面的功能來配置和管理 Istio控制平面的特點：

  • 為 HTTP、gRPC、WebSocket 和 TCP 流量自動負載均衡。
  • 通過豐富的路由規則、重試、故障轉移和故障注入對流量行為進行細粒度控制。
  • 可插拔的策略層和配置 API，支援訪問控制、速率限制和配額。
  • 叢集內（包括叢集的入口和出口）所有流量的自動化度量、日誌記錄和追蹤。
  • 在具有強大的基於身份驗證和授權的叢集中實現安全的服務間通訊。

Istio 為可擴充套件性而設計，可以滿足不同的部署需求。

組成部分

Istio由資料平面和控制平面兩部分組成：

  • 資料平面：各業務之間的通訊平面。如果沒有服務網格，網路就無法理解傳送過來的流量，也無法根據流量的型別來決定如何分發。Service mesh使用一個代理來攔截所有的網路流量。目前代理使用的Lyft的Envoy專案，它和叢集中啟動的每個服務一起部署，或者執行在每一個虛擬機器服務。
  • 控制平面：獲取所需的配置及其服務檢視，並動態地根據規則或環境對代理進行管理。

image-20220324152142896

核心特性

  • 流量管理：在單個叢集內和跨叢集路由流量都會影響效能，支援更好的部署策略。Istio 簡單的規則配置和流量路由允許您控制服務之間的流量和 API 呼叫過程。Istio 簡化了服務級屬性（如熔斷器、超時和重試）的配置，並且讓它輕而易舉的執行重要的任務（如 A/B 測試、金絲雀釋出和按流量百分比劃分的分階段釋出）。
  • 可觀察性：如何在服務複雜性環境監控服務呼叫和效能？Istio為服務網格內的所有通訊生成詳細的遙測技術。這種遙測技術提供了服務行為的可觀察性，使操作員能夠排除故障、維護和優化他們的應用程式，無侵入也即是不更改應用程式基礎上使用所有這些工具。通過Istio，操作人員可以全面瞭解被監視的服務如何互動，包括詳細的指標、分散式跟蹤和完整的訪問日誌。Istio 健壯的追蹤、監控和日誌特性讓您能夠深入的瞭解服務網格部署。通過 Istio 的監控能力，可以真正的瞭解到服務的效能是如何影響上游和下游的；而它的定製 Dashboard 提供了對所有服務效能的視覺化能力，可以看到與其他程式的影響關係。
  • 安全功能：的安全特性解放了開發人員，使其只需要專注於應用程式級別的安全。Istio 提供了底層的安全通訊通道，併為大規模的服務通訊管理認證、授權和加密。有了 Istio，服務通訊在預設情況下就是受保護的，可以讓您在跨不同協議和執行時的情況下實施一致的策略——而所有這些都只需要很少甚至不需要修改應用程式。Istio提供了一個全面的安全解決方案，使運營商能夠解決如防止中間人攻擊、靈活的訪問控制、審計工具和相互TLS的需求。它提供強大的身份和策略，透明的TLS加密，以及認證，授權和審計(AAA)工具來保護服務和資料。Istio的安全模型是基於預設安全的，旨在提供深入的防禦，部署具有安全意識的應用程式，甚至跨越不可信的網路。

元件

Istio是一個開放平臺，提供統一的方式來整合微服務、管理跨微服務的流量、執行策略和聚合遙測資料。Istio的控制平面在底層叢集管理平臺(如Kubernetes)上提供了一個抽象層，Istio由以下元件組成

  • Envoy：每個微服務的Sidecar代理，用於處理叢集中服務之間以及服務與外部服務之間的入口/出口流量。代理構成了一個安全的微服務網格，提供了一組豐富的功能，如發現、豐富的7層路由、斷路器、策略實施和遙測記錄/報告功能。
  • Istiod - Istio控制平面。它提供服務發現、配置和證照管理。它由下列子組成部分組成
    • Pilot ：負責在執行時配置代理。
    • Citadel ：負責證照的簽發和輪換。
    • Galley：負責驗證、吸收、聚合、轉換和分發Istio內部的配置。
  • Operator：該元件提供了使用者友好的選項來操作Istio服務網格。

下一篇我們再來部署和簡單實戰Istio

**本人部落格網站 **IT小神 www.itxiaoshen.com

相關文章