istio核心特性

• Istio 核心特性
• • 斷路器
  • 超時
  • 重試
  • 多路由規則
• Istio 架構
• 寫在最后

Istio 核心特性

1、流控(traffic management)
斷路器(circuit breakers)、超時、重試、多路由規則、AB 測試、灰度發布、按照百分比分配流量等。

2、安全(security)
加密、身份認證、服務到服務的權限控制、K8S 里容器到容器的權限控制等。

3、可觀察(observability)
追蹤、監控、數據收集，通過控制后臺全面了解上行下行流量，服務鏈路情況，服務運行情況，系統性能情況，國內微服務架構體系，這一塊做得比較缺乏。

4、平臺無關系(platform support)
K8s，物理機，自己的虛機都沒問題。

5、集成與定制(integration and customization)
可定制化擴展功能。

斷路器

舉個生活中的例子解釋斷路器

當電路發生故障或異常時，伴隨著電流不斷升高，并且升高的電流有可能能損壞電路中的某些重要器件，也有可能燒毀電路甚至造成火災。若電路中正確地安置了保險絲，那么保險絲就會在電流異常升高到一定的高度和熱度的時候，自身熔斷切斷電流，從而起到保護電路安全運行的作用。

很多技術都是來源生活的，隨著社會進步，科技發展，斷路器也稱為服務熔斷，在多個服務調用的時候，服務 A 依賴服務 B，服務 B 依賴服務 C，如果服務C 響應時間過長或者不可用，則會讓服務 B 占用太多系統資源，而服務 A 也依賴服 B，同時也在占用大量的系統資源，造成系統雪崩的情況出現。 Istio 斷路器通過網格中的邊車對流量進行攔截判斷處理，避免了在代碼中侵入控制邏輯，非常方便的就實服務熔斷的能力。

在微服務架構中，在高并發情況下，如果請求數量達到一定極限（可以自己設置閾值），超出了設置的閾值，斷路器會自動開啟服務保護功能，然后通過服務降級的方式返回一個友好的提示給客戶端（非計算機專業可能看不懂504這種錯誤碼）。假設當 10 個請求中，有 10%失敗時，熔斷器就會打開，此時再調用此服務，將會直接返回失敗，不再調遠程服務。直到 10s 鐘之后，重新檢測該觸發條件，判斷是否把熔斷器關閉，或者繼續打開。

服務降級（提高用戶體驗效果）

比如電商平臺，在針對 618、雙 11 的時候會有一些秒殺場景，秒殺的時候請求量大，可能會返回報錯標志“當前請求人數多，請稍后重試”等，如果使用服務降級，無法提供服務的時候，消費者會調用降級的操作，返回服務不可用等信息，或者返回提前準備好的靜態頁面寫好的信息。

超時

什么時候需要用到超時？

在生產環境中經常會碰到由于調用方等待下游的響應過長，堆積大量的請求阻塞了自身服務，造成雪崩的情況，通過超時處理來避免由于無限期等待造成的故障，進而增強服務的可用性。通過例子來理解

nginx 服務設置了超時時間為 3 秒，如果超出這個時間就不在等待，返回超時錯誤
httpd 服務設置了響應時間延遲 5 秒，任何請求都需要等待 5 秒后才能返回
client 通過訪問 nginx 服務去反向代理 httpd 服務，由于 httpd 服務需要 5 秒后才能返回，但 nginx 服務只等待 3 秒，所以客戶端會提示超時錯誤。

重試

istio 重試機制就是如果調用服務失敗，Envoy 代理嘗試連接服務的最大次數。而默認情況下，Envoy 代理在失敗后并不會嘗試重新連接服務。
舉個例子：

客戶端調用 nginx，nginx 將請求轉發給 tomcat。tomcat 通過故障注入而中止對外服務，nginx 設置如果訪問 tomcat 失敗則會重試 3 次。

多路由規則

1、HTTP 重定向（HTTPRedirect）

2、HTTP 重寫（HTTPRewrite）

3、HTTP 重試（HTTPRetry）

4、HTTP 故障注入（HTTPFaultInjection）

5、HTTP 跨域資源共享（CorsPolicy）

Istio 架構

istio 服務網格從邏輯上分為數據平面和控制平面。

1、數據平面由一組以 Sidecar（邊車）方式部署的智能代理(Envoy+Polit-agent)組成。這些代理承載并控制微服務之間的所有網絡通信，管理入口和出口流量，類似于一線員工。 Sidecar 一般和業務容器綁定在一起（在 Kubernets 中以自動注入的方式注入到到業務 pod 中），來劫持業務應用容器的流量，并接受控制面組件的控制，同時會向控制面輸出日志、跟蹤及監控數據，Envoy 和 pilot-agent 打在同一個鏡像中，即 sidecar Proxy。

2、control plane 控制平面負責管理和配置代理來路由流量。
istio1.5+中使用了一個全新的部署模式，重建了控制平面，將原有的多個組件整合為一個單體結構istiod，這個組件是控制平面的核心，管理 Istio 的所有功能，主要包括 Pilot、Mixer、Citadel 等服務組件。

istiod 是新版本中最大的變化，以一個單體組件替代了原有的架構，降低了復雜度和維護難度，但原有的多組件并不是被完全移除，而是在重構后以模塊的形式整合在一起組成了 istiod。

結合下圖我們來理解 Istio 的各組件的功能及相互之間的協作方式。

自動注入：在創建應用程序時自動注入 Sidecar 代理 Envoy 程序。在 Kubernetes 中創建 Pod 時，Kube-apiserver 調用控制面組件的 Sidecar-Injector 服務，自動修改應用程序的描述信息并注入Sidecar。在真正創建 Pod 時，在創建業務容器的 Pod 中同時創建 Sidecar 容器。

流量攔截：在 Pod 初始化時設置 iptables 規則，基于配置的 iptables 規則攔截業務容器的 Inbound 流量和 Outbound 流量到 Sidecar 上。而應用程序感知不到 Sidecar 的存在，還以原本的方式進行互相訪問。上圖中，流出 frontend 服務的流量會被frontend 服務側的 Envoy 攔截，而當流量到達 forecast 容器時，Inbound 流量被 forecast 服務側的 Envoy 攔截。

服務發現：服務發起方的 Envoy 調用控制面組件 Pilot 的服務發現接口獲取目標服務的實例列表。上圖中，frontend 服務側的 Envoy 通過 Pilot 的服務發現接口得到 forecast 服務各個實例的地址。

負載均衡：服務發起方的 Envoy 根據配置的負載均衡策略選擇服務實例，并連接對應的實例地址。上圖中，數據面的各個 Envoy 從 Pilot 中獲取 forecast 服務的負載均衡配置，并執行負載均衡動作。

流量治理：Envoy 從 Pilot 中獲取配置的流量規則，在攔截到 Inbound（入境） 流量和 Outbound 流量時執行治理邏輯。上圖中， frontend 服務側的 Envoy 從 Pilot 中獲取流量治理規則，并根據該流量治理規則將不同特征的流量分發到 forecast 服務的 v1 或 v2 版本。

訪問安全：在服務間訪問時通過雙方的 Envoy 進行雙向認證和通道加密，并基于服務的身份進行授權管理。上圖中，Pilot 下發安全相關配置，在 frontend 服務和 forecast 服務的 Envoy 上自動加載證書和密鑰來實現雙向認證，其中的證書和密鑰由另一個管理面組件 Citadel 維護。

服務監測：在服務間通信時，通信雙方的 Envoy 都會連接管理面組件 Mixer 上報訪問數據，并通過 Mixer 將數據轉發給對應的監控后端。上圖中，frontend 服務對 forecast 服務的訪問監控指標、日志和調用鏈都可以通過這種方式收集到對應的監控后端。

策略執行：在進行服務訪問時，通過 Mixer 連接后端服務來控制服務間的訪問，判斷對訪問是放行還是拒絕。上圖中，Mixer 后端可以對接一個限流服務對從 frontend 服務到 forecast 服務的訪問進行速率控制等操作。

外部訪問：在網格的入口處有一個 Envoy 扮演入口網關的角色。上圖中，外部服務通過 Gateway 訪問入口服務 frontend，對 frontend 服務的負載均衡和一些流量治理策略都在這個 Gateway 上執行。

sidecar 和 proxy 相生相伴，就像汽車與車輪。未來，sidecar 和 proxy 就指微服務進程解耦成兩個進程之后，提供基礎能力的那個代理進程。

寫在最后

創作不易，如果覺得內容對你有幫助，麻煩給個三連關注支持一下我！如果有錯誤，請在評論區指出，我會及時更改！

目前正在更新的系列：從零開始學istio

感謝各位的觀看，文章摻雜個人理解，如有錯誤請聯系我指出~

總結

以上是生活随笔為你收集整理的【云原生 | 从零开始学istio】二、Istio核心特性与架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。