復原性通訊
在本書中，我們已採用微服務架構方法。 雖然這類架構提供重要的優點，但這有許多挑戰：
跨流程網路通訊。 每個微服務都會透過網路通訊協定進行通訊，結果引起網路壅塞、延遲和暫時性錯誤。
服務探索。 微服務透過本身的 IP 位址和連接埠在機器叢集上執行時，如何探索並彼此通訊？
復原。 如何管理短期失敗並讓系統保持穩定？
負載平衡。 輸入流量如何分散到微服務的多個執行個體？
安全性。 如何強制執行傳輸層級加密和憑證管理等安全性考量？
分散式監視。 - 如何跨越多個取用微服務相互關聯及擷取單一要求的追蹤和監視？
您可以使用不同的程式庫和架構來解決這些疑慮，但實作可能很昂貴、複雜且耗時。 您最後也會考量結合商務邏輯的基礎結構考量。
Service Mesh
較佳的方法是名為 Service Mesh 的演進技術。 Service Mesh 是可設定的基礎結構層，內建功能可用來處理服務通訊和上述其他挑戰。 這會將這些疑慮移至服務 Proxy 來分離這些疑慮。 Proxy 會部署到個別的流程 (稱為 sidecar)，以提供與商務程式碼的隔離。 不過，sidecar 會連結至服務 -sidecar 是與服務一起建立的流程，並共用其生命週期。 圖 6-7 顯示此案例。
圖 6-7。 Service Mesh 與 sidecar
在上圖中，請注意 Proxy 如何攔截和管理微服務和叢集之間的通訊。
Service Mesh 會以邏輯方式分割成兩個不同的元件：資料平面和控制平面。 圖 6-8 顯示這些元件及其責任。
圖 6-8。 Service Mesh 控制項和資料平面
設定之後，Service Mesh 功能非常正常。 這可以從服務探索端點擷取對應的執行個體集區。 網格接著可以將要求傳送至特定執行個體，記錄結果的延遲和回應型別。 網格可以選擇最可能根據許多因素傳回快速回應的執行個體，包括最近要求觀察到的延遲。
如果執行個體沒有回應或失敗，網格將會在另一個執行個體上重試要求。 如果傳回錯誤，網狀結構會從負載平衡集區收回執行個體，並在修復後重新整理執行個體。 如果要求逾時，網格可能會失敗，然後重試要求。 網格會擷取計量和分散式追蹤並發出至集中式計量系統。
Istio 和 Envoy
雖然目前有一些 Service Mesh 選項，但 Istio 在本文撰寫期間最受歡迎。 Istio 是 IBM、Google 和 Lyft 的聯合聯盟。 這是開放原始碼供應項目，可整合到新的或現有的分散式應用程式中。 這項技術提供一致且完整的解決方案，以保護、連接和監視微服務。 其中的功能包括：
- 使用強式身分識別型驗證和授權來保護叢集中的服務對服務通訊。
- HTTP、gRPC、WebSocket 和 TCP 流量的自動負載平衡。
- 使用多樣化的路由規則、重試、容錯移轉和錯誤插入，更精細地控制流量行為。
- 支援存取控制、速率限制和配額的插入式原則層和設定 API。
- 叢集中所有流量的自動計量、記錄和追蹤，包括叢集輸入和輸出。
Istio 實作的主要元件是名為 Envoy Proxy 的 Proxy 服務。 這會與每個服務一起執行，並為下列功能提供與平台無關的基礎：
- 動態服務探索。
- 負載平衡。
- TLS 終止。
- HTTP 和 gRPC Proxy。
- 斷路器復原能力。
- 健康情況檢查。
- 使用 Canary 部署輪替更新。
如前所述，Envoy 會部署為叢集中每個微服務的 sidecar。
與 Azure Kubernetes Service 整合
Azure 雲端採用 Istio，並在 Azure Kubernetes Service 內提供直接支援。 下列主題有助於您開始使用：
