国产天天操女人,影音先锋日韩资源网,视频一区二区三区四区久久 ,婷婷色综合五月天,无码啪啪啪,日韩手机在线视频,鸥美超逼视频,日本一道本视频一二三

簡介

在本教程中，我們將介紹服務(wù)網(wǎng)格的基礎(chǔ)知識，并了解它如何實現(xiàn)分布式系統(tǒng)架構(gòu)。

我們將主要關(guān)注Istio，它是服務(wù)網(wǎng)格的一種具體實現(xiàn)。在此過程中，我們將介紹Istio的核心架構(gòu)。

什么是服務(wù)網(wǎng)格？

在過去的幾十年中，我們已經(jīng)看到了單體應(yīng)用程序開始拆分為較小的應(yīng)用程序。此外，諸如Docker之類的容器化技術(shù)和諸如Kubernetes之類的編排系統(tǒng)加速了這一變化。

盡管在像Kubernetes這樣的分布式系統(tǒng)上采用微服務(wù)架構(gòu)有許多優(yōu)勢，但它也具有相當?shù)膹?fù)雜性。由于分布式服務(wù)必須相互通信，因此我們必須考慮發(fā)現(xiàn)，路由，重試和故障轉(zhuǎn)移。

還有其他一些問題，例如安全性和可觀察性，我們還必須注意以下問題：

現(xiàn)在，在每個服務(wù)中建立這些通信功能可能非常繁瑣，尤其是當服務(wù)范圍擴大且通信變得復(fù)雜時，更是如此。這正是服務(wù)網(wǎng)格可以為我們提供幫助的地方。基本上，服務(wù)網(wǎng)格消除了在分布式軟件系統(tǒng)中管理所有服務(wù)到服務(wù)通信的責任。

服務(wù)網(wǎng)格能夠通過一組網(wǎng)絡(luò)代理來做到這一點。本質(zhì)上，服務(wù)之間的請求是通過與服務(wù)一起運行但位于基礎(chǔ)結(jié)構(gòu)層之外的代理路由的：

這些代理基本上為服務(wù)創(chuàng)建了一個網(wǎng)狀網(wǎng)絡(luò)——因此得名為服務(wù)網(wǎng)格！通過這些代理，服務(wù)網(wǎng)格能夠控制服務(wù)到服務(wù)通信的各個方面。這樣，我們可以使用它來解決分布式計算的八個謬誤，這是一組斷言，描述了我們經(jīng)常對分布式應(yīng)用程序做出的錯誤假設(shè)。

服務(wù)網(wǎng)格的特征

現(xiàn)在，讓我們了解服務(wù)網(wǎng)格可以為我們提供的一些功能。請注意，實際功能列表取決于服務(wù)網(wǎng)格的實現(xiàn)。但是，總的來說，我們應(yīng)該在所有實現(xiàn)中都期望其中大多數(shù)功能。

我們可以將這些功能大致分為三類：流量管理，安全性和可觀察性。

流量管理

服務(wù)網(wǎng)格的基本特征之一是流量管理。這包括動態(tài)服務(wù)發(fā)現(xiàn)和路由。尤其影子流量和流量拆分功能，這些對于實現(xiàn)金絲雀發(fā)布和A/B測試非常有用。

由于所有服務(wù)之間的通信都是由服務(wù)網(wǎng)格處理的，因此它還啟用了一些可靠性功能。例如，服務(wù)網(wǎng)格可以提供重試，超時，速率限制和斷路器。這些現(xiàn)成的故障恢復(fù)功能使通信更加可靠。

安全性

服務(wù)網(wǎng)格通常還處理服務(wù)到服務(wù)通信的安全性方面。這包括通過雙向TLS（mTLS）強制進行流量加密，通過證書驗證提供身份驗證以及通過訪問策略確保授權(quán)。

服務(wù)網(wǎng)格中還可能存在一些有趣的安全用例。例如，我們可以實現(xiàn)網(wǎng)絡(luò)分段，從而允許某些服務(wù)進行通信而禁止其他服務(wù)。而且，服務(wù)網(wǎng)格可以為審核需求提供精確的歷史信息。

可觀察性

強大的可觀察性是處理分布式系統(tǒng)復(fù)雜性的基本要求。由于服務(wù)網(wǎng)格可以處理所有通信，因此正確放置了它可以提供可觀察性的功能。例如，它可以提供有關(guān)分布式追蹤的信息。

服務(wù)網(wǎng)格可以生成許多指標，例如延遲，流量，錯誤和飽和度。此外，服務(wù)網(wǎng)格還可以生成訪問日志，為每個請求提供完整記錄。這些對于理解單個服務(wù)以及整個系統(tǒng)的行為非常有用。

Istio簡介

Istio是最初由IBM，Google和Lyft開發(fā)的服務(wù)網(wǎng)格的開源實現(xiàn)。它可以透明地分層到分布式應(yīng)用程序上，并提供服務(wù)網(wǎng)格的所有優(yōu)點，例如流量管理，安全性和可觀察性。

它旨在與各種部署配合使用，例如本地部署，云托管，Kubernetes容器以及虛擬機上運行的服務(wù)程序。盡管Istio與平臺無關(guān)，但它經(jīng)常與Kubernetes平臺上部署的微服務(wù)一起使用。

從根本上講，Istio的工作原理是以Sidcar的形式將Envoy的擴展版本作為代理布署到每個微服務(wù)中：

該代理網(wǎng)絡(luò)構(gòu)成了Istio架構(gòu)的數(shù)據(jù)平面。這些代理的配置和管理是從控制平面完成的：

控制平面基本上是服務(wù)網(wǎng)格的大腦。它為數(shù)據(jù)平面中的Envoy代理提供發(fā)現(xiàn)，配置和證書管理。

當然，只有在擁有大量相互通信的微服務(wù)時，我們才能體現(xiàn)Istio的優(yōu)勢。在這里，sidecar代理在專用的基礎(chǔ)架構(gòu)層中形成一個復(fù)雜的服務(wù)網(wǎng)格：

Istio在與外部庫和平臺集成方面非常靈活。例如，我們可以將Istio與外部日志記錄平臺，遙測或策略系統(tǒng)集成。

了解Istio組件

我們已經(jīng)看到，Istio體系結(jié)構(gòu)由數(shù)據(jù)平面和控制平面組成。此外，還有幾個使Istio起作用的核心組件。

在本節(jié)中，我們將詳細介紹這些核心組件。

數(shù)據(jù)平面

Istio的數(shù)據(jù)平面主要包括Envoy代理的擴展版本。Envoy是一個開源邊緣和服務(wù)代理，可幫助將網(wǎng)絡(luò)問題與底層應(yīng)用程序分離開來。應(yīng)用程序僅向localhost發(fā)送消息或從localhost接收消息，而無需了解網(wǎng)絡(luò)拓撲。

Envoy的核心是在OSI模型的L3和L4層運行的網(wǎng)絡(luò)代理。它通過使用可插入網(wǎng)絡(luò)過濾器鏈來執(zhí)行連接處理。此外，Envoy支持用于基于HTTP的流量的附加L7層過濾器。而且，Envoy對HTTP/2和gRPC傳輸具有一流的支持。

Istio作為服務(wù)網(wǎng)格提供的許多功能實際上是由Envoy代理的基礎(chǔ)內(nèi)置功能啟用的：

流量控制：Envoy通過HTTP，gRPC，WebSocket和TCP流量的豐富路由規(guī)則啟用細粒度的流量控制應(yīng)用
網(wǎng)絡(luò)彈性：Envoy包括對自動重試，斷路和故障注入的開箱即用支持
安全性：Envoy還可以實施安全策略，并對基礎(chǔ)服務(wù)之間的通信應(yīng)用訪問控制和速率限制

Envoy在Istio上表現(xiàn)出色的另一個原因之一是它的可擴展性。Envoy提供了基于WebAssembly的可插拔擴展模型。這在定制策略執(zhí)行和遙測生成中非常有用。此外，我們還可以使用基于Proxy-Wasm沙箱API的Istio擴展在Istio中擴展Envoy代理。

控制面

如上所述，控制平面負責管理和配置數(shù)據(jù)平面中的Envoy代理。在Istio架構(gòu)中，控制面核心組件是istiod，Istiod負責將高級路由規(guī)則和流量控制行為轉(zhuǎn)換為特定于Envoy的配置，并在運行時將其傳播到Sidercar。

如果我們回顧一下Istio控制平面的架構(gòu)，將會注意到它曾經(jīng)是一組相互協(xié)作的獨立組件。它包括諸如用于服務(wù)發(fā)現(xiàn)的Pilot，用于配置的Galley，用于證書生成的Citadel以及用于可擴展性的Mixer之類的組件。由于復(fù)雜性，這些單獨的組件被合并為一個稱為istiod的單個組件。

從根本上來說，istiod仍使用與先前各個組件相同的代碼和API。例如，Pilot負責抽象特定于平臺的服務(wù)發(fā)現(xiàn)機制，并將其合成為Sidecar可以使用的標準格式。因此，Istio可以支持針對多個環(huán)境（例如Kubernetes或虛擬機）的發(fā)現(xiàn)。

此外，istiod還提供安全性，通過內(nèi)置的身份和憑據(jù)管理實現(xiàn)強大的服務(wù)到服務(wù)和最終用戶身份驗證。此外，借助istiod，我們可以基于服務(wù)身份來實施安全策略。該過程也充當證書頒發(fā)機構(gòu)（CA）并生成證書，以促進數(shù)據(jù)平面中的相互TLS（MTLS）通信。

Istio工作原理

我們已經(jīng)了解了服務(wù)網(wǎng)格的典型特征是什么。此外，我們介紹了Istio架構(gòu)及其核心組件的基礎(chǔ)。現(xiàn)在，是時候了解Istio如何通過其架構(gòu)中的核心組件提供這些功能了。

我們將專注于我們之前經(jīng)歷過的相同類別的功能。

流量管理

我們可以使用Istio流量管理API對服務(wù)網(wǎng)格中的流量進行精細控制。我們可以使用這些API將自己的流量配置添加到Istio。此外，我們可以使用Kubernetes自定義資源定義（CRD）定義API資源。幫助我們控制流量路由的關(guān)鍵API資源是虛擬服務(wù)和目標規(guī)則：

基本上，虛擬服務(wù)使我們可以配置如何將請求路由到Istio服務(wù)網(wǎng)格中的服務(wù)。因此，虛擬服務(wù)由一個或多個按順序評估的路由規(guī)則組成。評估虛擬服務(wù)的路由規(guī)則后，將應(yīng)用目標規(guī)則。目標規(guī)則有助于我們控制到達目標的流量，例如，按版本對服務(wù)實例進行分組。

安全性

Istio為每個服務(wù)提供身份。與每個Envoy代理一起運行的Istio代理與istiod一起使用以自動進行密鑰和證書輪換：

Istio提供兩種身份驗證——對等身份驗證和請求身份驗證。對等身份驗證用于服務(wù)到服務(wù)的身份驗證，其中Istio提供雙向TLS作為全棧解決方案。請求身份驗證用于最終用戶身份驗證，其中Istio使用自定義身份驗證提供程序或OpenID Connect（OIDC）提供程序提供JSON Web令牌（JWT）驗證。

Istio還允許我們通過簡單地將授權(quán)策略應(yīng)用于服務(wù)來實施對服務(wù)的訪問控制。授權(quán)策略對Envoy代理中的入站流量實施訪問控制。這樣，我們就可以在各種級別上應(yīng)用訪問控制：網(wǎng)格，命名空間和服務(wù)范圍。

可觀察性

Istio為網(wǎng)格網(wǎng)絡(luò)內(nèi)的所有服務(wù)通信生成詳細的遙測，例如度量，分布式跟蹤和訪問日志。Istio生成一組豐富的代理級指標，面向服務(wù)的指標和控制平面指標。

之前，Istio遙測體系結(jié)構(gòu)將Mixer作為核心組件。但是從Telemetry v2開始，混音器提供的功能已替換為Envoy代理插件：

此外，Istio通過Envoy代理生成分布式跟蹤。Istio支持許多跟蹤后端，例如Zipkin，Jaeger，Lightstep和Datadog。我們還可以控制跟蹤速率的采樣率。此外，Istio還以一組可配置的格式生成服務(wù)流量的訪問日志。

Istio實戰(zhàn)

上面我們已經(jīng)講述了Istio原理和架構(gòu)，接下來我們開始實戰(zhàn)部分。首先，我們將在Kubernetes集群中安裝Istio。此外，我們將使用一個簡單的基于微服務(wù)的應(yīng)用程序來演示Istio在Kubernetes上的功能。

安裝

有多種安裝Istio的方法，但最簡單的方法是下載并解壓縮特定操作系統(tǒng)（例如Windows）的最新版本。提取的軟件包在bin目錄中包含istioctl客戶端二進制文件。我們可以使用istioctl在目標Kubernetes集群上安裝Istio：

istioctl?install?--set?profile=demo?-y

這會使用演示配置文件將Istio組件安裝在默認的Kubernetes集群上。我們還可以使用任何其他特定于供應(yīng)商的配置文件來代替演示。

最后，當我們在此Kubernetes集群上部署任何應(yīng)用程序時，我們需要指示Istio自動注入Envoy sidecar代理：

kubectl?label?namespace?default?istio-injection=enabled

我們在這里使用kubectl的前提是，我們的機器上已經(jīng)有像Minikube這樣的Kubernetes集群和Kubernetes CLI kubectl。

示例應(yīng)用

為了演示，我們將想象一個非常簡單的在線下訂單應(yīng)用程序。該應(yīng)用程序包含三個微服務(wù)，它們相互交互以滿足最終用戶的訂購請求：

我們沒有討論這些微服務(wù)的細節(jié)，但是使用Spring Boot和REST API可以很簡單地創(chuàng)建它們。最重要的是，我們?yōu)檫@些微服務(wù)創(chuàng)建了一個Docker鏡像，以便我們可以將它們部署在Kubernetes上。

部署

在像Minikube這樣的Kubernetes集群上部署容器化的工作負載非常簡單。我們將使用Deployment和Service資源類型來聲明和訪問工作負載。通常，我們在YAML文件中定義它們：

apiVersion:?apps/v1beta1
kind:?Deployment
metadata:
??name:?order-service
??namespace:?default
spec:
??replicas:?1
??template:
????metadata:
??????labels:
????????app:?order-service
????????version:?v1
????spec:
??????containers:
??????-?name:?order-service
????????image:?kchandrakant/order-service:v1
????????resources:
??????????requests:
????????????cpu:?0.1
????????????memory:?200
---
apiVersion:?v1
kind:?Service
metadata:
??name:?order-service
spec:
??ports:
??-?port:?80
????targetPort:?80
????protocol:?TCP
????name:?http
??selector:
????app:?order-service

對于訂單服務(wù)的“部署和服務(wù)”，這是一個非常簡單的定義。同樣，我們可以為庫存服務(wù)和運輸服務(wù)定義YAML文件。

使用kubectl部署這些資源也非常簡單：

kubectl?apply?-f?booking-service.yaml?-f?inventory-service.yaml?-f?shipping-service.yaml

由于我們已經(jīng)為默認命名空間啟用了自動注入Envoy sidecar代理，因此一切都會由istiod來處理。或者，我們可以使用istioctl的kube-inject命令手動注入Envoy sidecar代理。

訪問應(yīng)用

現(xiàn)在，Istio主要負責處理所有的網(wǎng)狀網(wǎng)絡(luò)流量。因此，默認情況下，不允許進出網(wǎng)格的任何流量。Istio使用網(wǎng)關(guān)來管理來自網(wǎng)格的入站和出站流量。這樣，我們可以精確地控制進入或離開網(wǎng)格的流量。Istio提供了一些預(yù)配置的網(wǎng)關(guān)代理部署：istio-ingressgateway和istio-egressgateway。

我們將為我們的應(yīng)用程序創(chuàng)建一個網(wǎng)關(guān)和一個虛擬服務(wù)來實現(xiàn)此目的：

apiVersion:?networking.istio.io/v1alpha3
kind:?Gateway
metadata:
??name:?booking-gateway
spec:
??selector:
????istio:?ingressgateway
??servers:
??-?port:
??????number:?80
??????name:?http
??????protocol:?HTTP
????hosts:
????-?"*"
---
apiVersion:?networking.istio.io/v1alpha3
kind:?VirtualService
metadata:
??name:?booking
spec:
??hosts:
??-?"*"
??gateways:
??-?booking-gateway
??http:
??-?match:
????-?uri:
????????prefix:?/api/v1/booking
????route:
????-?destination:
????????host:?booking-service
????????port:
??????????number:?8080

在這里，我們利用了Istio提供的默認入口控制器。此外，我們已經(jīng)定義了一個虛擬服務(wù)，將我們的請求路由到預(yù)訂服務(wù)。

同樣，我們也可以為來自網(wǎng)格的出站流量定義出口網(wǎng)關(guān)。

Istio的常見用例

現(xiàn)在，我們已經(jīng)看到了如何使用Istio在Kubernetes上部署一個簡單的應(yīng)用程序。但是，我們?nèi)匀粵]有利用Istio為我們啟用的任何有趣功能。在本節(jié)中，我們將介紹服務(wù)網(wǎng)格的一些常見用例，并了解如何使用Istio為我們的簡單應(yīng)用程序?qū)崿F(xiàn)它們。

請求路由

我們可能要以特定方式處理請求路由的原因有多個。例如，我們可能會部署微服務(wù)的多個版本，例如運輸服務(wù)，并希望僅將一小部分請求路由到新版本。

我們可以使用虛擬服務(wù)的路由規(guī)則來實現(xiàn)這一點：

apiVersion:?networking.istio.io/v1alpha3
apiVersion:?networking.istio.io/v1alpha3
kind:?VirtualService
metadata:
??name:?shipping-service
spec:
??hosts:
????-?shipping-service
??http:
??-?route:
????-?destination:
????????host:?shipping-service
????????subset:?v1
??????weight:?90
????-?destination:
????????host:?shipping-service
????????subset:?v2
??????weight:?10
---
apiVersion:?networking.istio.io/v1alpha3
kind:?DestinationRule
metadata:
??name:?shipping-service
spec:
??host:?shipping-service
??subsets:
??-?name:?v1
????labels:
??????version:?v1
??-?name:?v2
????labels:
??????version:?v2

路由規(guī)則還允許我們基于諸如header參數(shù)之類的屬性來定義匹配條件。此外，目的地字段指定與條件匹配的流量的實際目的地。

熔斷

熔斷器基本上是一種軟件設(shè)計模式，用于檢測故障并封裝防止故障進一步級聯(lián)的邏輯。這有助于創(chuàng)建有彈性的微服務(wù)應(yīng)用程序，以限制故障和延遲尖峰的影響。

在Istio中，我們可以使用DestinationRule中的trafficPolicy配置在調(diào)用諸如清單服務(wù)之類的服務(wù)時應(yīng)用熔斷：

apiVersion:?networking.istio.io/v1alpha3
kind:?DestinationRule
metadata:
??name:?inventory-service
spec:
??host:?inventory-service
??trafficPolicy:
????connectionPool:
??????tcp:
????????maxConnections:?1
??????http:
????????http1MaxPendingRequests:?1
????????maxRequestsPerConnection:?1
????outlierDetection:
??????consecutive5xxErrors:?1
??????interval:?1s
??????baseEjectionTime:?3m
??????maxEjectionPercent:?100

在這里，我們將DestinationRule配置為maxConnections為1，httpMaxPendingRequests為1，maxRequestsPerConnection為1。這實際上意味著，如果我們將并發(fā)請求數(shù)超過1，熔斷器將開始trap一些請求。

啟用雙向 TLS

雙向身份驗證是指雙方在諸如TLS之類的身份驗證協(xié)議中同時相互進行身份驗證的情況。默認情況下，具有代理的服務(wù)之間的所有流量在Istio中都使用相互TLS。但是，沒有代理的服務(wù)仍繼續(xù)以純文本格式接收流量。

雖然Istio將具有代理的服務(wù)之間的所有流量自動升級為雙向TLS，但這些服務(wù)仍可以接收純文本流量。我們可以選擇使用PeerAuthentication策略在整個網(wǎng)格范圍內(nèi)實施雙向TLS：

apiVersion:?"security.istio.io/v1beta1"
kind:?"PeerAuthentication"
metadata:
??name:?"default"
??namespace:?"istio-system"
spec:
??mtls:
????mode:?STRICT

我們還提供了對每個命名空間或服務(wù)而不是在網(wǎng)格范圍內(nèi)強制實施雙向TLS的選項。但是，特定于服務(wù)的PeerAuthentication策略優(yōu)先于命名空間范圍的策略。

使用JWT進行訪問控制

JSON Web令牌（JWT）是用于創(chuàng)建數(shù)據(jù)的標準，該數(shù)據(jù)的有效載荷中包含聲明許多聲明的JSON。為了在身份提供者和服務(wù)提供者之間傳遞經(jīng)過身份驗證的用戶的身份和標準或自定義聲明，這一點已被廣泛接受。

我們可以在Istio中啟用授權(quán)策略，以允許訪問基于JWT的預(yù)訂服務(wù)之類的服務(wù)：

apiVersion:?security.istio.io/v1beta1
kind:?AuthorizationPolicy
metadata:
??name:?require-jwt
??namespace:?default
spec:
??selector:
????matchLabels:
??????app:?booking-service
??action:?ALLOW
??rules:
??-?from:
????-?source:
???????requestPrincipals:?["[email protected]/[email protected]"]

在這里，AuthorizationPolicy強制所有請求具有有效的JWT，并將requestPrincipal設(shè)置為特定值。Istio通過組合聲明JWT的iss和sub來創(chuàng)建requestPrincipal屬性。

思考

因此，到目前為止，我們已經(jīng)看到像Istio這樣的服務(wù)網(wǎng)格如何使我們更輕松地處理諸如微服務(wù)之類的分布式架構(gòu)中的許多常見問題。但是盡管如此，Istio還是一個復(fù)雜的系統(tǒng)，會增加最終部署的復(fù)雜性。與其他所有技術(shù)一樣，Istio并非靈丹妙藥，必須謹慎使用。

我們應(yīng)該始終使用服務(wù)網(wǎng)格嗎？

盡管我們已經(jīng)看到了使用服務(wù)網(wǎng)格的足夠理由，但下面列舉了一些可能促使我們不使用它的原因：

服務(wù)網(wǎng)格處理所有服務(wù)到服務(wù)的通信，而部署和操作服務(wù)網(wǎng)格則需要支付額外的費用。對于較簡單的應(yīng)用程序，這可能是不合理的
由于我們已經(jīng)習慣于處理一些此類問題，例如應(yīng)用程序代碼中的熔斷，因此可能導(dǎo)致服務(wù)網(wǎng)格中的重復(fù)處理
越來越依賴于諸如服務(wù)網(wǎng)格之類的外部系統(tǒng)可能會損害應(yīng)用程序的可移植性，尤其是因為沒有針對服務(wù)網(wǎng)格的行業(yè)標準
由于服務(wù)網(wǎng)格通常通過攔截通過代理的網(wǎng)格流量來工作，因此它可能會給請求增加不希望的延遲
服務(wù)網(wǎng)格增加了許多其他組件和配置，需要精確處理。這需要專業(yè)知識，并增加了學(xué)習曲線
最后，我們可能最終將操作邏輯（應(yīng)在服務(wù)網(wǎng)格中存在）與業(yè)務(wù)邏輯（不應(yīng)在服務(wù)網(wǎng)格中）混合在一起

因此，正如我們所看到的，服務(wù)網(wǎng)格的故事不僅僅涉及好處，但這并不意味著它們不是真的。對我們來說，重要的是要仔細評估我們的需求和應(yīng)用程序的復(fù)雜性，然后權(quán)衡服務(wù)網(wǎng)格的好處和它們所增加的復(fù)雜性。

Istio的替代品有哪些？

盡管Istio非常受歡迎，并得到了業(yè)內(nèi)一些領(lǐng)導(dǎo)者的支持，但它當然不是唯一的選擇。盡管我們在這里無法進行全面的比較，但讓我們看一下Linkerd和Consul這兩個選項。

Linkerd是已為Kubernetes平臺創(chuàng)建的開源服務(wù)網(wǎng)格。它也很受歡迎，目前在CNCF中具有孵化項目的地位。它的工作原理類似于Istio等任何其他服務(wù)網(wǎng)格。它還利用TCP代理來處理網(wǎng)格流量。Linkerd使用用Rust編寫的微型代理，稱為Linkerd代理。

總體而言，Linkerd并不比Istio復(fù)雜，因為它僅支持Kubernetes。但是，除此之外，Linkerd中可用的功能列表與Istio中可用的功能非常相似。Linkerd的核心架構(gòu)也非常類似于Istio。基本上，Linkerd包含三個主要組件：用戶界面，數(shù)據(jù)平面和控制平面。

Consul是HashiCorp的服務(wù)網(wǎng)格的開源實現(xiàn)。它的好處是可以與HashiCorp的其他基礎(chǔ)架構(gòu)管理產(chǎn)品套件很好地集成，以提供更廣泛的功能。Consul中的數(shù)據(jù)平面可以靈活地支持代理以及本機集成模型。它帶有內(nèi)置代理，但也可以與Envoy一起使用。

除了Kubernetes，Consul還可以與Nomad等其他平臺一起使用。Consul通過在每個節(jié)點上運行Consul代理以執(zhí)行運行狀況檢查來工作。這些代理與一臺或多臺存儲和復(fù)制數(shù)據(jù)的Consul服務(wù)器通信。盡管它提供了服務(wù)網(wǎng)格（如Istio）的所有標準功能，但它是部署和管理的更復(fù)雜的系統(tǒng)。

總結(jié)

總而言之，在本教程中，我們介紹了服務(wù)網(wǎng)格模式的基本概念以及它提供給我們的功能。特別是，我們詳細介紹了Istio。這涵蓋了Istio的核心架構(gòu)及其基本組件。此外，我們詳細介紹了一些常見用例的安裝和使用Istio的細節(jié)。

萬字長文詳解Istio