istio in kubernetes (一) --原理篇

背景

微服務是什麼

• 服務之間有輕量級的通信機制，一般爲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的結構和特色，能夠總結出其對於服務治理的理念：

一、微服務治理與業務邏輯解耦：把大部分SDK能力從應用中剝離出來，並拆解爲獨立進程，以 sidecar 的模式進行部署。

二、異構系統的統一治理：方便多語言的實施，解鎖升級帶來的困難。

三、價值：

（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）繪製。