Service Mesh以及Sidecar
在介紹Service Mesh概念之前，我們先來了解一下Sidecar。Sidecar是以第一次世界大戰時活躍在戰場上的軍用邊鬥車命名（也是我們在抗日神劇中最常見的道具之一）。Sidecar是Service Mesh中的重要組成部分，Sidecar在軟體系統架構中特指邊鬥車模式，這個模式的精髓在于實作了資料面（業務邏輯）和控制面的解耦。
在Service Mesh架構中，給每一個微服務執行個體部署一個Sidecar Proxy。該Sidecar Proxy負責接管對應服務的入流量和出流量，并将微服務架構中的服務訂閱、服務發現、熔斷、限流、降級、分布式跟蹤等功能從服務中抽離到該Proxy中。
Sidecar以一個獨立的程序啟動，可以每台主控端共用同一個Sidecar程序，也可以每個應用獨占一個Sidecar程序。所有的服務治理功能，都由Sidecar接管，應用的對外通路僅需要通路Sidecar即可。當該Sidecar在微服務中大量部署時，這些Sidecar節點自然就形成了一個服務網格。
Istio簡介
第二代Service Mesh主要改進集中在更加強大的控制面功能（與之對應的Sidecar Proxy被稱之為資料面），典型代表有Istio和Conduit。Istio是Google、IBM和Lyft合作的開源項目，是目前最主流的Service Mesh方案，也是事實上的第二代Service Mesh标準。在Istio中，直接把Envoy作為Sidecar。除了Sidecar，Istio中的控制面元件都是使用Go語言編寫。
根據Istio官方文檔的介紹，Istio在服務網絡中主要提供了以下關鍵功能：
•流量管理：控制服務之間的流量和API調用的流向，使得調用更可靠，并使網絡在惡劣情況下更加健壯。•可觀察性：了解服務之間的依賴關系，以及它們之間流量的本質和流向，進而提供快速識别問題的能力。•政策執行：将組織政策應用于服務之間的互動，確定通路政策得以執行，資源在消費者之間良好配置設定。政策的更改是通過配置網格而不是修改應用程式代碼。•服務身份和安全：為網格中的服務提供可驗證身份，并提供保護服務流量的能力，使其可以在不同可信度的網絡上流轉。•平台支援：Istio旨在在各種環境中運作，包括跨雲、Kubernetes、Mesos等。最初專注于Kubernetes，但很快将支援其他環境。•內建和定制：政策執行元件可以擴充和定制，以便與現有的ACL、日志、監控、配額、稽核等解決方案內建。
Istio針對可擴充性進行了設計，以滿足不同的部署需要。這些功能極大的減少了應用程式代碼、底層平台和政策之間的耦合，使得微服務更加容易實作。
下圖為Istio的架構設計圖，主要包括了Envoy、Pilot、Mixer和Istio-Auth等。
•Envoy: 扮演Sidecar的功能，協調服務網格中所有服務的出入站流量，并提供服務發現、負載均衡、限流熔斷等能力，還可以收集與流量相關的性能名額。•Pilot: 負責部署在Service Mesh中的Envoy執行個體的生命周期管理。本質上是負責流量管理和控制，将流量和基礎設施擴充解耦，這是Istio的核心。可以把Pilot看做是管理Sidecar的Sidecar, 但是這個特殊的Sidacar并不承載任何業務流量。Pilot讓運維人員通過Pilot指定它們希望流量遵循什麼規則，而不是哪些特定的pod/VM應該接收流量。有了Pilot這個元件，我們可以非常容易的實作 A/B 測試和金絲雀Canary測試。•Mixer: Mixer在應用程式代碼和基礎架構後端之間提供通用中介層。它的設計将政策決策移出應用層，用運維人員能夠控制的配置取而代之。應用程式代碼不再将應用程式代碼與特定後端內建在一起，而是與Mixer進行相當簡單的內建，然後Mixer負責與後端系統連接配接。Mixer可以認為是其他後端基礎設施（如資料庫、監控、日志、配額等）的Sidecar Proxy。•Istio-Auth: 提供強大的服務間認證和終端使用者認證，使用互動TLS，内置身份和證書管理。可以更新服務網格中的未加密流量，并為運維人員提供基于服務身份而不是網絡控制來執行政策的能力。Istio的未來版本将增加細粒度的通路控制和審計，以使用各種通路控制機制（包括基于屬性和角色的通路控制以及授權鈎子）來控制和監視通路服務、API或資源的通路者。
istio安裝
https://github.com/istio/istio，本文使用1.02版本，安裝沒有auth驗證版本
kubectl apply -f install/kubernetes/istio-demo.yaml