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

架構演進

發展歷程

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

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

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

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

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

  

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

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

  

• 服務治理：隨着業務增加，基礎服務也越來越多，服務之間調用關系越來越錯綜復雜，對此有了服務治理的需求。服務治理基本要求如下，基於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。

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（邊⻋，很形象的翻譯）代理之間的連接形成⽹格結構並成為了微服務的通訊基礎設施層，承載了微服務之間的所有流量。

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

Linked項目

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

但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項目，它和集群中啟動的每個服務一起部署，或者運行在每一個虛擬機服務。
• 控制平面：獲取所需的配置及其服務視圖，並動態地根據規則或環境對代理進行管理。

核心特性

• 流量管理：在單個集群內和跨集群路由流量都會影響性能，支持更好的部署策略。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