istio 整體架構圖
Istio 服務網格從邏輯上分為數據平面和控制平面。
- 數據平面由一組智能代理（Envoy）組成，被部署為 sidecar。這些代理通過一個通用的策略和遙測中心（Mixer）傳遞和控制微服務之間的所有網絡通信。
- 控制平面管理並配置代理來進行流量路由。此外，控制平面配置 Mixer 來執行策略和收集遙測數據。
※什么是sidecar？
sidecar 的中文意思為邊車，可以參考下面這張圖。
試想， 我們部署一個web 應用的服務，除了應用本身， 可能還需要監控，日志采集等功能，如果將這些功能統一放到一個容器中，web應用的體積會變得很大。 不便於維護(業務更新升級過程中，可能監控和日志采集並不需要更新)，這種情況下。 我們可以將監控和日志采集功能單獨部署在這個Pod 中的另外container（容器）中， 這種將應用程序的功能划分為單獨的進程可以被視為 Sidecar 模式
istio各個組件
部署完istio后， 我們可以在istio命名空間下找到istio 的各個組件，我們接下來會依次介紹這幾個組件的功能和工作方式。
istio-proxy（envoy)
istio 的sidecar（istio-proxy）是開源項目envoy的擴展版，Envoy是用C＋＋開發的非常有影響力的輕量級高性能開源服務代理。作為服務網格的數據面，是istio架構中唯一的數據面組件， Envoy 提供了動態服務發現、負載均衡、TLS , HTTP/2 及gRPC 代理、熔斷器、健康檢查、流量拆分、灰度發布、故障注入等功能。在istio-proxy容器中除了有Envoy ，還有一個pilot-agent的守護進程。
pilot
服務列表中的istio-pilot是istio的控制中樞Pilot服務。如果把數據面的envoy 也看作一種agent， 則Pilot 類似傳統C /S 架構中的服務端Master，下發指令控制客戶端完成業務功能。和傳統的微服務架構對比， Pilot 至少涵蓋服務注冊中心和Config Server等管理組件的功能。
如下圖所示：pilot直接從運行平台(kubernetes,consul)提取數據並將其構造和轉換成istio的服務發現模型， 因此pilot只有服務發現功能，無須進行服務注冊。這種抽象模型解耦Pilot 和底層平台的不同實現，可支持kubernetes，consul等平台
除了服務發現， Pilot 更重要的一個功能是向數據面下發規則，包括VirtualService 、DestinationRule 、Gateway 、ServiceEntry 等流量治理規則，也包括認證授權等安全規則。Pilot 負責將各種規則轉換成Envoy 可識別的格式，通過標准的XDS 協議發送給Envoy,指導Envoy 完成功作。在通信上， Envoy 通過gRPC 流式訂閱Pilot 的配置資源。如下圖所示， Pilot 將VirtualService 表達的路由規則分發到Evnoy 上， Envoy 根據該路由規則進行流量轉發。
mixer
Istio 控制面部署了兩個Mixer 組件： istio-telemetry 和istio-policy ，分別處理遙測數據的收集和策略的執行。查看兩個組件的Pod 鏡像會發現，容器的鏡像是相同的，都是"/istio/mixer"
Mixer 是Istio 獨有的一種設計,不同於Pilot ，在其他平台上總能找到類似功能的服務組件。從調用時機上來說,Pilot 管理的是配置數據，在配置改變時和數據面交互即可；然而，對於Mixer 來說，在服務間交互時Envoy 都會對Mixer 進行一次調用，因此這是一種實時管理。當然，在實現上通過在Mixer 和Proxy 上使用緩存機制，可保證不用每次進行數據面請求時都和Mixer 交互。
- istio-telemetry
istio-telemetry是專門用於收集遙測數據的Mixer服務組件;如下圖所示 所示，當網格中的兩個服務間有調用發生時，服務的代理Envoy 就會上報遙測數據給istio-telemetry服務組件，istio-telemetry 服務組件則根據配置將生成訪問Metric等數據分發給后端的遙測服務。數據面代理通過Report 接口上報數據時訪問數據會被批
量上報。
- istio-policy
istio-policy 是另外一個Mixer 服務，和istio-telemetry 基本上是完全相同的機制和流程。
如圖下圖所示，數據面在轉發服務的請求前調用istio-policy 的Check接口檢查是否允許訪問， Mixer 根據配置將請求轉發到對應的Adapter 做對應檢查，給代理返回允許訪問還是拒絕。可以對接如配額、授權、黑白名單等不同的控制后端，對服務間的訪問進行可擴展的控制。
istio-citadel
服務列表中的istio-citadel 是Istio 的核心安全組件，提供了自動生成、分發、輪換與撤銷密鑰和證書功能。Citadel 一直監聽Kube-apiserver ，以Secret 的形式為每個服務都生成證書密鑰，並在Pod 創建時掛載到Pod 上，代理容器使用這些文件來做服務身份認證，進而代理兩端服務實現雙向TLS認證、通道加密、訪問授權等安全功能，這樣用戶就不用在代碼里面維護證書密鑰了。如下圖 所示，frontend 服務對forecast 服務的訪問用到了HTTP 方式，通過配置即可對服務增加認證功能， 雙方的Envoy 會建立雙向認證的TLS 通道，從而在服務間啟用雙向認證的HTTPS 。
istio-galley
istio-galley 並不直接向數據面提供業務能力，而是在控制面上向其他組件提供支持。Galley 作為負責配置管理的組件，驗證配置信息的格式和內容的正確性，並將這些配置信息提供給管理面的Pilot和Mixer服務使用，這樣其他管理面組件只用和Galley 打交道，從而與底層平台解耦。在新的版本中Galley的作用越來越核心。
istio-sidecar-injector
istio-sidecar-inj ector 是負責向動注入的組件，只要開啟了自動注入，在Pod 創建時就會自動調用istio-sidecar-injector 向Pod 中注入Sidecar 容器。
在Kubernetes環境下，根據自動注入配置， Kube-apiserver 在攔截到Pod 創建的請求時，會調用自動注入服務istio-sidecar-injector生成Sidecar 容器的描述並將其插入原Pod的定義中，這樣，在創建的Pod 內除了包括業務容器，還包括Sidecar 容器。這個注入過程對用戶透明，用戶使用原方式創建工作負載。
istio-ingressgateway
istio-ingressgateway 就是入口處的Gateway ，從網格外訪問網格內的服務就是通過這個Gateway 進行的。istio-ingressgateway 比較特別， 是一個Loadbalancer 類型的Service,不同於其他服務組件只有一兩個端口,istio-ingressgateway 開放了一組端口，這些就是網格內服務的外部訪問端口.如下圖 所示，網格入口網關istio-ingressgateway 的負載和網格內的Sidecar 是同樣的執行體，也和網格內的其他Sidecar 一樣從Pilot處接收流量規則並執行。 。Istio 通過一個特有的資源對象Gateway 來配置對外的協議、端口等。
