Istio 的起源
爲了實現由 William Morgan 提出的微服務 Service Mesh 模式和諸多理念，Google , IBM 和 Lyft 這三家公司協同研發，並於 2017 年 6 月 8 日( 根據 Github 最後一次提交的時間 )發佈了 Istio 的第一個發行版——Istio 0.1 版本。
Istio 的設計目標
作爲一款 Service Mesh 模式的實現，Istio 最根本的設計目標就是實現 Service Mesh 的設計構想：
- 將“應用程序”與“網絡”解藕: 將服務之間、服務與集羣外部的網絡通訊和安全機制從微服務的業務邏輯中解藕，並作爲一個與平臺無關的、獨立運行的程序，以減少開發和運維人員的工作量。
- 保障網絡環節: 應用程序的目標是“將某些東西從A傳送到B”，而 Service Mesh 所要做的就是實現這個目標，並處理傳送過程中可能出現的任何故障。
- 提供應用層面的可見性和可控性: 通過每個微服務中的 Sidecar ，Service Mesh 得以將服務間通信從底層的基礎設施中分離出來，讓它成爲整個生態系統的一個獨立部分——它不再是單純的基礎設施，更可以被監控、託管和控制。
除此之外，Istio 還有着其他更加關鍵的設計目標，這些目標對於使系統能夠應對大規模流量和高性能地服務處理至關重要。
- 最大化透明度( 與“解藕”類似，但具體到基於 Pod 實現 ): Istio 使用 Sidecar 代理來捕獲流量，並且在儘可能的地方自動編程網絡層，以路由流量通過這些代理，而無需對已部署的應用程序代碼進行任何改動。注入 sidecar 代理到 pod 中並且修改路由規則後，Istio 就能夠調解所有流量。
- 增量擴容策略: 擴展策略系統，集成其他策略和控制來源，並將網格行爲信號傳播到其他系統進行分析。策略運行時支持標準擴展機制以便插入到其他服務中。
- 可移植性: Istio 必須能夠以最少的代價運行在任何雲或預置環境中。將基於 Istio 的服務移植到新環境應該是輕而易舉的，而使用 Istio 將一個服務同時部署到多個環境中也是可行的（例如，在多個雲上進行冗餘部署）。
- 策略一致性: 在服務間的 API 調用中，策略的應用使得可以對網格間行爲進行全面的控制，但對於無需在 API 級別表達的資源來說，對資源應用策略也同樣重要。策略系統作爲獨特的服務來維護，具有自己的 API，而不是將其放到代理或 Sidecar 中，這容許服務根據需要直接與其集成。
Istio 的核心功能
Istio 的核心功能有以下五點：
- 流量管理: Istio 通過 Pilot 所提供的 API 動態地配置所有 Pod 中 Sidecar 的路由規則，進而控制服務間的流量和 API 調用。Istio 簡化了斷路器、超時和重試等服務級別屬性的配置，並且可以輕鬆設置 A/B 測試、金絲雀部署和基於百分比的流量分割的分階段部署等重要任務。
- 安全: Istio 提供給開發人員應用程序級別的安全性。Istio 提供底層安全通信信道，並大規模管理服務通信的認證、授權和加密。使用 Istio ，服務通信在默認情況下是安全的，它允許跨多種協議和運行時一致地實施策略——所有這些都很少或根本不需要應用程序更改。將 Istio 與 Kubernetes 的網絡策略結合使用，其優勢會更大，包括在網絡和應用層保護 Pod 間或服務間通信的能力。
- 可觀察性: Istio 的 Mixer 組件負責策略控制和遙測收集。通過 Istio 的監控功能，可以瞭解服務性能如何影響上游和下游的功能；其自定義儀表板可以提供對所有服務性能的可視化，從而瞭解性能如何影響其他進程。
- 平臺獨立: Istio 是獨立於平臺的，旨在運行在各種環境中，包括跨雲、內部部署、Kubernetes、Mesos 等。您可以在 Kubernetes 上部署 Istio 或具有 Consul 的 Nomad 上部署。
- 集成和定製: 策略執行組件可以擴展和定製，以便與現有的 ACL、日誌、監控、配額、審計等方案集成。
Istio 的實現原理
Istio 的架構
- Istio 的架構在邏輯上分爲“控制面”和“數據面”。
“數據面“：由一組 Sidecar 構成。這些 Sidecar 可以調節和控制微服務及 Mixer 之間所有的網絡通信。
“控制面“：負責管理和配置代理路由流量。此外，控制面通過 Mixer 來實施策略和收集各個 Sidecar 的遙測數據。
( 具體見下文 Attribute 與服務監控 )
架構圖如下：
Istio 架構中每個部分的作用
- Sidecar ( 在 Istio 中，默認的 Sidecar 是 Envoy )
Envoy 是使用 C++ 開發的高性能代理，用於調解服務網格中所有服務的入站和出站流量。在 Istio 中，Envoy 被用於 Sidecar ，和對應的應用服務部署在同一個 Kubernetes 的 Pod 中。
Envoy 調解所有出入應用服務的流量。所有經過 Envoy 的流量行爲都會調用 Mixer，爲Mixer 提供一組描述請求和請求周圍環境的 Attribute 。根據 Envoy 的配置和 Attribute，Mixer 會調用各種後臺的基礎設施資源。而這些 Attribute 又可以在 Mixer 中用於決策使用何種策略，併發送給監控系統，以提供整個網格行爲的信息。 - Pilot
Pilot 爲 Sidecar 提供“服務發現”功能，並管理高級路由( 如 A/B 測試和金絲雀部署 )和故障處理( 超時、重試、熔斷器等 )的流量。Pilot 將這些“高級”的流量行爲轉換爲詳盡的 Sidecar (即 Envoy) 配置項，並在運行時將它們配置到 Sidecar 中。
Pilot 將服務發現機制提煉爲供數據面使用的 API ，即任何 Sidecar 都可以使用的標準格式。這種鬆耦合的設計模式使 Istio 能在多種環境( Kubernetes、Consul 和 Nomad )下運行，同時保持用於流量管理操作的相同。 - Mixer
Mixer 是一個獨立於平臺的組件，通過從 Sidecar 和一些其他服務處收集數據，進而在整個 Service Mesh 上控制訪問和執行策略。Sidecar 請求級別的 Attribute 被髮送到 Mixer 進行評估。( 關於 Attribute 的定西，詳見下文 )
Mixer 中還包括一個靈活的插件，使其能接入各種主機環境和基礎設施的後段，並得到 Sidecar 代理和 Istio 所管理的服務。
Mixer 的設計還具有以下特點：
- 無狀態：Mixer 本身是無狀態的，它沒有持久化存儲的管理功能。
- 高可用：Mixer 被設計成高度可用的組件，任何單獨的 Mixer 實例實現 > 99.999% 的正常運行時間
- 緩存和緩衝：Mixer 能夠積累大量短暫的瞬間狀態
( 其能夠作爲 Envoy 的二級緩存，見 Attribute 與服務監控 )
- Citadel
Citadel 通過內置身份和憑證管理提供“服務間”和“最終用戶”身份驗證。Citadel 可用於升級服務網格中未加密的流量，並能夠爲運維人員提供基於服務標識( 如 Kubernetes 中 Pod 的標籤或版本號 )而不是網絡層的強制執行策略。
Istio 與 Envoy 的關係
( 見 Istio 部分功能和工作流程 的 流量管理 部分 )
Istio 與容器管理平臺的關係 ( 以 K8s 爲例 )
從設計上來說，Istio 是平臺無關的，它可以在許多容器管理平臺上部署。但是當 Istio 與 Kubernetes 共同使用時，它的能力將得到最大化應用。
比如，Istio 可以通過 yaml ( Istio 有提供 yaml )的形式快速在 K8s 上部署；其服務註冊機制由 K8s 提供，而服務發現由 Istio 中的 Pilot 負責。
綜上所述，在 Kubernetes 上使用 Istio 是非常合適的，具體四種 Service Mesh 的各種功能特性對比見 下文。
Istio 部分功能的工作流程
流量管理及請求路由
將流量從應用程序中解藕，使得 Istio 能提供各種流量管理的功能，例如：動態路由( 負載均衡，A/B 測試，金絲雀部署 )、故障處理( 超時，重試，熔斷器，故障恢復 )以及故障注入( 測試服務之間的故障恢復策略的兼容性 )。這些都是通過 Pilot 與 Sidecar 共同協作完成的。
(上圖: Pilot 的構成及其與 Sidecar 協同工作原理示意)
由上圖可以看出，一個 Pilot 主要由“平臺適配器”、“抽象模型”、用於配置和調用 Envoy 的“Envoy API” 和 用於用戶指定流量管理規則的“Rules API”所組成。
Sidecar 的服務發現及傳輸規則機制，主要遵循以下流程：
- 平臺適配器( Platform Adapter )從 Kubernetes API server 中獲取 Pod 的註冊信息。( 注意：Istio 本身並不具備服務註冊的功能，它需要通過平臺適配器和特定的平臺結合才能具有完整的服務發現的功能。)
- 用戶通過 Pilot 的 Rules API 對所有被發現的服務的 Sidecar 進行各種高級特性( 包括路由規則、HTTP層的流量管理等 )的配置
- 用戶配置的這些規則被抽象模型翻譯成低級配置
- Sidecar API(即 Envoy API) 將這些翻譯好的低級配置通過 discovery API 分發到每個微服務上的 SIdecar(即 Envoy) 實例中
服務間通訊
運維人員可以用 Pilot 指定路由規則，而 Envoy 根據這些規則動態地確定其服務版本的實際選擇。Envoy 攔截並轉發客戶端和服務器之間的所有請求和相應。路由規則讓 Envoy 能夠根據諸如 header、source/destination 或分配給每個版本的權重等標準來進行版本選擇。
Service A 訪問不同版本的 Service B 的工作流程如下：
- 運維人員通過 Polit 的 Rules API 根據 destination 的相關標籤配置分流規則
- Service A 運行時，其 Envoy 的配置規則更新
- Service A 根據新配置的規則訪問帶有不同標籤的 Service B 的版本
集羣出入站規則
Istio 默認進入和離開網絡的所有流量都會通過 Envoy 進行傳輸。通過 Envoy 將流量路由到外部 Web 服務( 例如訪問 Maps API 或 視頻服務 API )的方式，運維人員可以爲這些服務添加超時控制、重試、熔斷器等功能；還能從服務連接中獲得各種細節指標。
流量從外網進入集羣再流出的流程如下：
- 通過 Kubernetes 的准入控制，外部流量進入 Istio
- 流量與 Service A 和 Service B 的 Envoy 交互，並由 Envoy 獲取服務具體相應的內容
- 流量通過 Egress gateway 或 直接流出的方式流出 Istio
服務發現和負載均衡
Istio 的服務註冊功能是基於平臺來實現的。Istio 默認存在用於跟蹤 Pod 的服務註冊表，而且還默認新的服務自動註冊，不健康的服務被自動刪除。目前，Kubernetes、Mesos 等平臺已經爲基於容器的應用程序提供了這樣的功能。
Pilot 使用服務註冊的信息，並提供與平臺無關的 discovery API。網格中的 Envoy 提供服務發現功能，並相應地動態更新負載均衡池。
運行流程如下：
- 每個微服務的 Pod 通過 Kubernetes 提供的服務註冊機制進行註冊
- 已註冊的 Service A 的 Envoy 通過 Pilot 中彙總的 Envoy 信息發現欲訪問的 Service B
- Service A 的 Envoy 根據設置好的負載均衡或流量管理規則，對 Service B 的 Envoy 發起請求
- Service B 的 Envoy 根據設置好的規則確認是否接收 Service A 發出的請求。
Attribute 與服務監控
Attribute 是 Istio 策略和遙測功能中的基本概念。Attribute 是一小段數據，用於描述服務請求的一系列屬性( 例如特定請求的大小、操作相應代碼、請求來自的 IP )；通過 Attribute，我們就可以洞悉服務的方方面面。
Mixer 是 Istio 中用於實現策略和遙測功能的組件，其本質上是一個 Attribute 處理機。每個經過 Sidecar 的請求都會調用 Mixer，爲 Mixer 提供一組描述請求及其周圍環境的 Attribute。基於 Envoy 的配置和相應 Attribute，Mixer 會調用各種基礎設施後端。
遙測功能的信息彙總流程如下( 注意所有微服務都是通過 Envoy 進行通信的 )：
- Envoy 通過調用將 Attribute 傳遞給 Mixer
- Mixer 得到 Envoy 的 Attribute，並根據 Attribute 調用各種後端資源
- 同時，Mixer 可以彙總所有 Envoy 的 Attribute，用於集羣範圍的監控以及爲運維人員提供可觀測性
位於網格中每個服務實例旁邊的 Sidecar 代理必須在內存消耗方面節約，這限制了本地緩存和緩衝的可能數量。然而，Mixer 獨立運行，可以使用相當大的緩存和輸出緩衝區。因此，Mixer 可用作 Sidecar 的高度擴展且高度可用的二級緩存。
Istio 與目前其他主流 Service Mesh 的比較
目前，市面上有許多 Service Mesh 的實現。我們這裏挑選 4 種當前最主流的 Service Mesh，對其諸多方面( 包括功能特性、支持平臺、是否付費等 )進行橫向對比，用以說明 Istio 所存在的優勢和不足。
Istio, Linkerd, Linkerd2 和 Consul 四種 Service Mesh 的橫向對比
( 黃色表明目前在該特性上處於優勢態 )
根據上表所示，目前選擇 Istio 作爲 Service Mesh 的主要優劣勢如下：
優勢：
- 使用 Sidecar 模式開發，便於流量控制和監測及安全機制
- 與 K8s 完美兼容
- 使用高性能的 Go 語言開發
- 支持多種高級快速的網絡協議
- Sidecar 默認 Envoy 並自動注入
- 容錯機制完善
- 集成了用於監測的可視化界面
- Jaeger 作爲跟蹤機制集成
- 具備權限認證功能
- Sidecar 代理具有緩存功能
- 完全免費
- 文檔和技術博客數量遠多於其他 3 種 Service Mesh
劣勢：
- 複雜度高，技術門檻和學習成本高
- 目前 Istio 不支持集羣內外通信的安全連接