# 背景 ## 微服務是什麼 > - 服務之間有輕量級的通訊機制，通常為REST API > - 去中心化的管理機制 > - 每個服務可以使用不同的程式語言實現，使用不同的資料儲存技術 > - 應用按業務拆分成服務，一個大型應用系統可以由多個獨立的服務組成 > - 各個服務均可獨立部署，都有自己的業務邏輯 > - 服務可被多個應用共享，其他服務可複用一些公共的資源服務 ## 微服務的優勢 > - 模組化開發，以單個服務為元件進行更新升級，提升系統整體異常穩定性 > - 模組化開發管理方便，單獨團隊開發維護，職責分明 > - 模組服用，公共服務模組可被其他業務模組使用 > - 系統架構更加分明 > - 結合CI/CD，實現DevOPS > - 彈性伸縮，結合服務編排K8S動態HPA > - 服務熔斷/降級，避免但節點異常雪崩效應，分散故障節點 ## 微服務帶來的挑戰 > - 服務越來越多，配置管理維護複雜 > - 服務間依賴關係複雜 > - 服務呼叫鏈追蹤難 > - 服務之間的負載均衡 > - 服務的拓展 > - 服務監控/日誌 > - 服務熔斷/降級 > - 服務鑑權 > - 服務上線與下線 > - 服務文件 ## 微服務架構和單體架構的對比 | 因素 | 單體架構 | 微服務架構 | 說明 | | :----------- | :------- | :--------- | :----------------------------------------------------------- | | 故障隔離 | 執行緒級 | 程序級 | 微服務獨立執行，通過程序的方式隔離，使故障範圍得到有效控制，架構變得更可靠 | | 整體可用性 | 較低 | 較高 | 微服務架構由於故障得到有效隔離，整體可用性更高，有效降低了單點故障對整體的影響 | | 架構持續演進 | 困難 | 容易 | 微服務的粒度更小，架構演進的影響面相應也更小，架構演進不需要大規模重構，只需調整個別微服務即可 | | 可重用性 | 低 | 高 | 微服務架構可以實現以服務為粒度，通過介面共享重用 | | 可擴充套件性 | 笨重 | 靈活 | 微服務架構可以根據服務對資源的要求以服務為粒度進行擴充套件，而單體應用只能整體進行擴充套件 | | 交付速遞 | 較慢 | 較快 | 服務拆分後，各個服務可以獨立進行開發、測試、部署、交付效率大大提升，產品更新換代速度更快，使用者體驗更好 | ## 什麼是微服務治理 微服務之間一旦建立起路由，就意味著會有資料在服務之間流通。由於不同服務可以提供的資源和對資料流量的承載能力不盡相同，為了防止單個 Consumer(消費者) 佔用 Provide(生產者） 過多的資源，或者突發的大流量衝擊導致 Provider 故障，需要服務限流來保證服務的高可用。 在服務治理中，雖然可以通過限流規則儘量避免服務承受過高的流量，但是在實際生產中服務故障依然難以完全避免。當整個系統中某些服務產生故障時，如果不及時採取措施，這種故障就有可能因為服務之間的互相訪問而被傳播開來，最終導致故障規模的擴大，甚至導致整個系統奔潰，這種現象我們稱之為“雪崩”。熔斷降級其實不只是服務治理中，在金融行業也有很廣泛的應用。比如當股指的波動幅度超過規定的熔斷點時，交易所為了控制風險採取的暫停交易措施。 針對以微服務帶來的方便以及挑戰，從裸金屬到虛擬化再到公有云，再到容器，到serverless，技術不斷革新，應對微服務帶來的挑戰，如何對服務進行註冊發現，請求鏈路追蹤，負載均衡，服務熔斷/降級，服務限流，訪問控制，監控日誌，配置管理，金絲雀釋出呢 # 微服務治理istio ## Service Mesh Service Mesh 的中文譯為“服務網格”，是一個用於處理服務和服務之間通訊的基礎設施層，它負責為構建複雜的雲原生應用傳遞可靠的網路請求，併為服務通訊實現了微服務所需的基本元件功能，例如服務發現、負載均衡、監控、流量管理、訪問控制等。在實踐中，服務網格通常實現為一組和應用程式部署在一起的輕量級的網路代理，但對應用程式來說是透明的。 服務網格（Service Mesh）這個術語通常用於描述構成這些應用程式的微服務網路以及應用之間的互動。隨著規模和複雜性的增長，服務網格越來越難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及通常更加複雜的運維需求，例如 A/B 測試、金絲雀釋出、限流、訪問控制和端到端認證等。 服務網格技術對企業現有分散式系統架構的影響主要體現在系統分層和能力下沉。傳統微服務框架以 RPC 框架為基礎，提供服務目錄、註冊發現、服務治理、流量管理、配置中心、全鏈路追蹤等核心能力，並且向外延伸到安全審計、監控告警、統計分析、知識庫等平臺化能力，服務網格技術要做的事情就是把這些微服務架構支撐能力下沉到 Sidecar 裡，並且在這個改造過程中不中斷業務。要做到這個過程平滑，除了在服務網格資料面和控制面元件中對服務註冊發現、RPC 協議、配置下發進行擴充套件之外，還要對現有的上層的研發工作臺、運維效能平臺等支撐平臺進行相容。 Istio 提供了一個完整的解決方案，通過為整個服務網格提供行為洞察和操作控制來滿足微服務應用程式的多樣化需求。 Service Mesh 部署網路結構圖:  Service Mesh有四大特點： > - 治理能力獨立（Sidecar） > - 應用程式無感知 > - 服務通訊的基礎設施層 > - 解耦應用程式的重試/超時、監控、追蹤和服務發現  如此一來，Service Mesh將業務模組和服務治理分開。 從上圖中看到，控制面和資料面分離，應用在部署的時候，每個應用附帶一個SideCar，這個SideCar是攔截每一個應用對外請求的。同時控制面的服務治理策略下到SideCar中具體的執行，這樣的話，即使業務模組升級和服務治理的升級也能互不影響的，還能動態調整服務治理的規則和策略。 從Service Mesh的結構和特點，可以總結出其對於服務治理的理念： > 1、微服務治理與業務邏輯解耦：把大部分SDK能力從應用中剝離出來，並拆解為獨立程序，以 sidecar 的模式進行部署。 > > 2、異構系統的統一治理：方便多語言的實施，解鎖升級帶來的困難。 > > 3、價值： > > （1）可觀察性：服務網格捕獲諸如來源、目的地、協議、URL、狀態碼、延遲、持續時間等線路資料； > > （2）流量控制：為服務提供智慧路由、超時重試、熔斷、故障注入、流量映象等各種控制能力。 > > （3）安全性高：服務的認證、服務間通訊的加密、安全相關策略的強制執行； > > （4）健壯性：支援故障注入，對於容災和故障演練等健壯性檢驗幫助巨大。 以Service Mesh的傑出代表Istio為例來聊聊最新的服務治理的架構，它對Service Mesh完全支援，架構清晰，拆分資料面、控制面；擁有通訊、安全、控制、觀察等功能，實現開放，且外掛化，多種可選實現。 Istio可結合K8S使用，K8S提供服務生命週期的管理，Istio在K8S之上實現服務治理的整體的功能。 ## Istio 概述 Isito是Service Mesh的產品化落地，是目前最受歡迎的服務網格，功能豐富、成熟度高。 Linkerd是世界上第一個服務網格類的產品 中文文件地址：https://istio.io/latest/zh/docs/ Istio 近幾個版本持續演進的方向：把控制面元件合併為 istiod 和完善 istioctl 的叢集生命週期管理能力來降低運維複雜性；將 Mixer 元件能力下沉到 Sidecar 降低服務東西向網路延時；增加對虛擬機器的原生支援，便於非容器化業務平滑遷移……等等，這其中的每一項都是業務生產落地 Istio 時面臨的痛點問題。 主要有以下特點 > • 連線（Connect） ``` - 流量管理 ``` > 通過簡單的規則配置和流量路由，您可以控制服務之間的流量和 API 呼叫。Istio 簡化了斷路器、超時和重試等服務級別屬性的配置，並且可以輕鬆設定 A/B測試、金絲雀部署和基於百分比的流量分割的分階段部署等重要任務。 > > 通過更好地瞭解您的流量和開箱即用的故障恢復功能，您可以在問題出現之前先發現問題，使呼叫更可靠，並且使您的網路更加強大——無論您面臨什麼條件。 ``` - 負載均衡 - 灰度釋出 - 動態路由 - 故障注入 ``` > • 安全（Secure） > > Istio 的安全功能使開發人員可以專注於應用程式級別的安全性。Istio 提供底層安全通訊通道，並大規模管理服務通訊的認證、授權和加密。使用Istio，服務通訊在預設情況下是安全的，它允許您跨多種協議和執行時一致地實施策略——所有這些都很少或根本不需要應用程式更改。 > > 雖然 Istio 與平臺無關，但將其與 Kubernetes（或基礎架構）網路策略結合使用，其優勢會更大，包括在網路和應用層保護 pod 間或服務間通訊的能力。 ``` - 認證 - 鑑權 ``` > • 控制（Control） ``` - 限流 - ACL ``` > • 觀察（Observe） > > Istio 強大的追蹤、監控和日誌記錄可讓您深入瞭解服務網格部署。通過 Istio 的監控功能，可以真正瞭解服務效能如何影響上游和下游的功能，而其自定義儀表板可以提供對所有服務效能的可視性，並讓您瞭解該效能如何影響您的其他程序。 > > Istio 的 Mixer 元件負責策略控制和遙測收集。它提供後端抽象和中介，將 Istio 的其餘部分與各個基礎架構後端的實現細節隔離開來，併為運維提供對網格和基礎架構後端之間所有互動的細粒度控制。 > > 所有這些功能可以讓您可以更有效地設定、監控和實施服務上的 SLO。當然，最重要的是，您可以快速有效地檢測和修復問題。 ``` - 監控 - 呼叫鏈 ``` 主要應用於服務治理： > - 注：此圖isito ???  ### Isito 架構與元件  > 注：此頁中圖片引用自Istio官網 > >  > > - Envoy - 也就是圖中的Proxy，有時候也叫Sidecar。 每個微服務中的Sidecar代理處理叢集內服務之間的入口/出口流量以及到外部服務的入口/出口流量。這個代理構成一個安全的微服務網格，提供豐富的功能集，如發現、豐富的7層路由、熔斷、策略執行和遙測記錄/報告功能。 > - Istiod - Istio控制平面。提供服務發現、配置和證書管理。它由以下子部分組成： > - Pilot - 負責在執行時配置代理。為Envoy sidecar提供服務發現功能，為智慧路由（例如A/B測試、金絲雀部署等）和彈性（超時、重試、熔斷器等）提供流量管理功能；它將控制流量行為的高階路由規則轉換為特定於Envoy的配置，並在執行時將它們傳播到sidecar； > - Citadel - 負責證書頒發和輪換。通過內建身份和憑證管理賦能強大的服務間和終端使用者身份驗證；可用於升級服務網格中未加密的流量，併為運維人員提供基於服務標識而不是網路控制的強制執行策略的能力； > - Galley - 負責Istio內部的驗證、採集、聚合、轉換和分發配置。 > - Operator - 該元件提供使用者友好的選項來操作Istio服務網格。 ### ◆ 效能總結 Istio 負載測試網格包含了 1000 個服務和 2000 個 sidecar，全網 格範圍內，QPS 為 70,000。 在使用 Istio 1.6.2 執行測試後，我們 得到了如下結果： • 通過代理的 QPS 有 1000 時，Envoy 使用了 0.5 vCPU 和 50 MB 記憶體。 • 網格總的 QPS 為 1000 時，istio-telemetry 服務使用了 0.6 vCPU。 • Pilot 使用了 1 vCPU 和 1.5 GB 記憶體。 • 90% 的情況 Envoy 代理只增加了 6.3 ms 的延遲  注：此頁中圖片和資料引用自Istio官網 ## 東西南北流量 > - 本節整理自網路 先看一張圖  > - 說明： > - VM_B3有FIP，其它VM沒有FIP > - 紅色資料流：跨伺服器東西流量 > - 紫色資料流：伺服器內東西流量 > - 藍色資料流：沒有FIP場景，VM訪問外網 > - 橙色資料流：有VIP場景，VM訪問外網，外網訪問VM 在Service Mesh微服務架構中，我們常常會聽到東西流量和南北流量兩個術語。 南北流量（NORTH-SOUTH traffic）和東西流量（EAST-WEST traffic）是資料中心環境中的網路流量模式。下面通過一個例子來理解這兩個術語。 假設我們嘗試通過瀏覽器訪問某些Web應用。Web應用部署在位於某個資料中心的應用伺服器中。在多層體系結構中，典型的資料中心不僅包含應用伺服器，還包含其他伺服器，如負載均衡器、資料庫等，以及路由器和交換機等網路元件。假設應用伺服器是負載均衡器的前端。 當我們訪問web應用時，會發生以下型別的網路流量： > - 客戶端（位於資料中心一側的瀏覽器）與負載均衡器（位於資料中心）之間的網路流量 > - 負載均衡器、應用伺服器、資料庫等之間的網路流量，它們都位於資料中心。 ### 南北流量 在這個例子中，前者即客戶端和伺服器之間的流量被稱為南北流量。簡而言之，南北流量是server-client流量。 ### 東西流量 第二種流量即不同伺服器之間的流量與資料中心或不同資料中心之間的網路流被稱為東西流量。簡而言之，東西流量是server-server流量。 當下，東西流量遠超南北流量，尤其是在當今的大資料生態系統中，比如Hadoop生態系統（大量server駐留在資料中心中，用map reduce處理），server-server流量遠大於server-client流量。 該命名來自於繪製典型network diagrams的習慣。在圖表中，通常核心網路元件繪製在頂部（NORTH），客戶端繪製在底部（SOUTH），而資料中心內的不同伺服器水平（EAST-WEST）