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