操逼综合网,军人野外岔开腿呻吟bl,亚洲自拍露出极品,五月天丁香社区,草逼com.,做爱www,成人一区二区三区在线A片,国产免费成人视频

簡(jiǎn)介

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

我們將主要關(guān)注Istio，它是服務(wù)網(wǎng)格的一種具體實(shí)現(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ì)，但它也具有相當(dāng)?shù)膹?fù)雜性。由于分布式服務(wù)必須相互通信，因此我們必須考慮發(fā)現(xiàn)，路由，重試和故障轉(zhuǎn)移。

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

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

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

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

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

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

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

流量管理

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

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

安全性

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

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

可觀察性

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

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

Istio簡(jiǎn)介

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

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

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

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

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

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

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

了解Istio組件

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

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

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

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

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

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

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

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

控制面

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

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

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

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

Istio工作原理

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

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

流量管理

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

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

安全性

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

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

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

可觀察性

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

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

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

Istio實(shí)戰(zhàn)

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

安裝

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

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

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

最后，當(dāng)我們?cè)诖薑ubernetes集群上部署任何應(yīng)用程序時(shí)，我們需要指示Istio自動(dòng)注入Envoy sidecar代理：

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

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

示例應(yīng)用

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

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

部署

在像Minikube這樣的Kubernetes集群上部署容器化的工作負(fù)載非常簡(jiǎn)單。我們將使用Deployment和Service資源類型來聲明和訪問工作負(fù)載。通常，我們?cè)赮AML文件中定義它們：

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

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

使用kubectl部署這些資源也非常簡(jiǎn)單：

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

由于我們已經(jīng)為默認(rèn)命名空間啟用了自動(dòng)注入Envoy sidecar代理，因此一切都會(huì)由istiod來處理?；蛘撸覀兛梢允褂胕stioctl的kube-inject命令手動(dòng)注入Envoy sidecar代理。

訪問應(yīng)用

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

我們將為我們的應(yīng)用程序創(chuàng)建一個(gè)網(wǎng)關(guān)和一個(gè)虛擬服務(wù)來實(shí)現(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提供的默認(rèn)入口控制器。此外，我們已經(jīng)定義了一個(gè)虛擬服務(wù)，將我們的請(qǐng)求路由到預(yù)訂服務(wù)。

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

Istio的常見用例

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

請(qǐng)求路由

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

我們可以使用虛擬服務(wù)的路由規(guī)則來實(shí)現(xiàn)這一點(diǎ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í)際目的地。

熔斷

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

在Istio中，我們可以使用DestinationRule中的trafficPolicy配置在調(diào)用諸如清單服務(wù)之類的服務(wù)時(shí)應(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。這實(shí)際上意味著，如果我們將并發(fā)請(qǐng)求數(shù)超過1，熔斷器將開始trap一些請(qǐng)求。

啟用雙向 TLS

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

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

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

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

使用JWT進(jìn)行訪問控制

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

我們可以在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強(qiáng)制所有請(qǐng)求具有有效的JWT，并將requestPrincipal設(shè)置為特定值。Istio通過組合聲明JWT的iss和sub來創(chuàng)建requestPrincipal屬性。

思考

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

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

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

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

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

Istio的替代品有哪些？

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

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

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

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

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

總結(jié)

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

萬字長(zhǎng)文詳解Istio