在Istio Service Mesh中，必須說一說以下基本要點：
-
什么是服務網格？
-
為什么我們需要服務網格？
-
可用的服務網格型別以及為什么使用Istio？
-
Istio-體系結構和實作，
-
Istio組件，
-
Istio功能，
什么是服務網格？
在任何基于微服務的體系結構中，只要存在從一個微服務到另一個微服務的服務呼叫，我們無法推斷或除錯網路服務呼叫中發生的情況，
如果無法正確診斷如果出現意外情況，那可能會導致很多問題，例如; 性能問題，安全性，負載均衡等，跟蹤服務呼叫或服務呼叫的可觀測性（鏈路追蹤），
當必須迎合更多的微服務以使任何應用程式正常運行時，此問題的嚴重性就會成倍增加，
服務網格是用于處理服務到服務通信的專用基礎結構層，它負責通過構成現代云原生應用程式的復雜服務擴展和傳遞可靠請求，實際上，服務網格通常被應用在輕量級網路代理的陣列，這種輕量級網路代理與應用程式代碼一起部署，而無需了解應用程式，
可用的服務網格
集群生態系統中有三個主要的競爭者爭奪服務網格，所有這些解決方案都是開源的，
-
Consul Connect：Consul Connect使用安裝在每個節點上的代理作為后臺駐留程式集，該后臺駐留程式與處理流量路由和轉發的Envoy Sidecar代理進行通信，它強調服務發現和服務身份管理，與Istio一樣，它使用Envoy代理和sidecar模式，
-
Linkerd：Linkerd設計為輕量級的服務網格，可以放置在任何現有平臺的頂部，它具有非常簡單的安裝和CLI工具，不需要使用平臺管理員，它使用RUST作為代理，它僅適用于Kubernetes，
-
Istio：Istio是Kubernetes本地解決方案，最初由Lyft發布，它的功能包括針對HTTP，gRPC，WebSocket和TCP通信的自動負載平衡，它提供對流量行為的細粒度控制，提供豐富的路由規則，重試，故障轉移和故障注入，Istio是第一個包含開發人員真正想要的附加功能的工具，例如深度分析，
為什么通過聯結器和Consul Connect進行Istio？
到目前為止，Istio在這三個服務網格中具有最大的功能和靈活性：
-
級聯故障預防（斷路），
-
身份驗證和授權，服務網格可以授權和驗證從應用程式外部和內部發出的請求，僅將經過驗證的請求發送到實體，
-
彈性功能（重試，超時，期限等），
-
強大的負載均衡演算法，
-
控制請求路由（對于CI / CD發行模式等很有用），
-
在通信端點之間引入和管理TLS終止的能力，
-
豐富的度量標準集，以在服務到服務層提供檢測，
-
服務發現，當實體需要與其他服務進行互動時，它需要找到（發現）其他服務的可用實體，
-
容器編排框架，
架構與實作
Istio服務網格周圍的流量分為兩部分，分別是：
-
資料平面流量
-
控制平面交通
資料平面
Envoy：用C ++開發的高性能代理可提供動態服務發現，負載均衡，TLS終止，HTTP / 2和gRPC代理，斷路器，運行狀況檢查，具有基于百分比的流量拆分的分階段推出，故障注入，豐富的指標，
控制平面
Pilot：Istio中用于流量管理的核心組件是試點，它可以管理和配置部署在特定Istio服務網格中的所有Envoy代理實體，
Mixer：混合器是與平臺無關的組件，Mixer跨服務網格實施訪問控制和使用策略，并從Envoy代理和其他服務收集遙測資料，代理提取請求級別屬性，并將其發送到Mixer進行評估，
Citadel：Citadel通過內置的身份和憑據管理提供強大的服務和最終用戶身份驗證，您可以使用Citadel升級服務網格中的未加密流量，使用Citadel，運營商可以根據服務身份而不是網路控制來實施策略，
使用Istio的一些核心用例是：
-
性能除錯，
-
流量管理（負載均衡和加權平均），
-
斷路器，
-
安全，
結論
到目前為止，Istio具有這三個服務網格中最多的功能和靈活性，但具有靈活性...也會產生復雜性，最好手動管理Istio，而不要依賴于云提供商的實施，它降低了成本和復雜性，
對于僅支持Kubernetes的簡單用法，Linkerd可能是最佳選擇，
如果一個同時包含Kubernetes和VM且不需要Istio復雜性的異構環境，那么Consul可能是最好的選擇，
你需不需要一個充滿技術氛圍的學習交流群？掃碼就行：
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/274039.html
標籤：其他
上一篇：一文徹底搞定Hystrix！