共計 5123 個字符，預(yù)計需要花費 13 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“AWS App Mesh 和 Istio 怎么配置”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

概念產(chǎn)品定位

從官方的介紹來看，Istio 和 App Mesh 都比較明確的表示自己是一種服務(wù)網(wǎng)格產(chǎn)品。Istio 強調(diào)了自己在連接、安全、控制和可視化 4 個方面的能力；而 App Mesh 主要強調(diào)了一致的可見性和流量控制這兩方面能力，當(dāng)然也少不了強調(diào)作為云平臺下的產(chǎn)品的好處：托管服務(wù)，無需自己維護(hù)。

從某種程度上講，Istio 是一個相對重一點的解決方案，提供了不限于流量管理的各個方面的能力；而 App Mesh 是更加純粹的服務(wù)于運行在 AWS 之上的應(yīng)用并提供流控功能。筆者認(rèn)為這和它目前的產(chǎn)品形態(tài)還不完善有關(guān)（后面會具體提到）。從與 AWS 內(nèi)部開發(fā)人員的溝通中可以感覺到，App Mesh 應(yīng)該是一盤很大的棋，目前只是初期階段而已。

核心術(shù)語

和 AWS 里很多產(chǎn)品一樣，App Mesh 也不是獨創(chuàng)，而是基于 Envoy 開發(fā)的。AWS 這樣的閉環(huán)生態(tài)必然要對其進(jìn)行改進(jìn)和整合。同時，也為了把它封裝成一個對外的服務(wù)，提供適當(dāng)?shù)?API 接口，在 App Mesh 這個產(chǎn)品中提出了下面幾個重要的技術(shù)術(shù)語，我們來一一介紹一下。

服務(wù)網(wǎng)格（Service mesh）：服務(wù)間網(wǎng)絡(luò)流量的邏輯邊界。這個概念比較好理解，就是為使用 App mesh 的服務(wù)圈一個虛擬的邊界。

虛擬服務(wù)（Virtual services）：是真實服務(wù)的抽象。真實服務(wù)可以是部署于抽象節(jié)點的服務(wù)，也可以是間接的通過路由指向的服務(wù)。

虛擬節(jié)點（Virtual nodes）：虛擬節(jié)點是指向特殊工作組（task group）的邏輯指針。例如 AWS 的 ECS 服務(wù)，或者 Kubernetes 的 Deployment。可以簡單的把它理解為是物理節(jié)點或邏輯節(jié)點的抽象。

Envoy：AWS 改造后的 Envoy（未來會合并到 Envoy 的官方版本），作為 App Mesh 里的數(shù)據(jù)平面，Sidecar 代理。

虛擬路由器（Virtual routers）：用來處理來自虛擬服務(wù)的流量。可以理解為它是一組路由規(guī)則的封裝。

路由（Routes）：就是路由規(guī)則，用來根據(jù)這個規(guī)則分發(fā)請求。

上面的圖展示了這幾個概念的關(guān)系：當(dāng)用戶請求一個虛擬服務(wù)時，服務(wù)配置的路由器根據(jù)路由策略將請求指向?qū)?yīng)的虛擬節(jié)點，這些節(jié)點本質(zhì)上是 AWS 里的 EKS 或者 ECS 的節(jié)點。

那么這些 App Mesh 自創(chuàng)的術(shù)語是否能在 Istio 中找到相似甚至相同的對象呢？我歸納了下面的表格來做一個對比：

App MeshIstio 服務(wù)網(wǎng)格（Service mesh）Istio 并未顯示的定義這一概念，我們可以認(rèn)為在一個集群中，由 Istio 管理的服務(wù)集合，它們組成的網(wǎng)絡(luò)拓?fù)浼词欠?wù)網(wǎng)格。虛擬服務(wù)（Virtual services）Istio 中也存在虛擬服務(wù)的概念。它的主要功能是定義路由規(guī)則，使請求可以根據(jù)這些規(guī)則被分發(fā)到對應(yīng)的服務(wù)。從這一點來說，它和 App Mesh 的虛擬服務(wù)的概念基本上是一致的。虛擬節(jié)點（Virtual nodes）Istio 沒有虛擬節(jié)點的概念，可以認(rèn)為類似 Kubernetes 里的 Deployment。虛擬路由器（Virtual routers）Istio 也沒有虛擬路由器的概念。路由（Routes）Istio 中的目標(biāo)規(guī)則（DestinationRule）和路由的概念類似，為路由設(shè)置一些策略。從配置層面講，其中的子集（subset）和 App Mesh 路由里選擇的目標(biāo)即虛擬節(jié)點對應(yīng)。但 Istio 的目標(biāo)規(guī)則更加靈活，也支持更多的路由策略。

從上面的對比看出，App Mesh 目前基本上實現(xiàn)了最主要的流量控制（路由）的功能，但像超時重試、熔斷、流量復(fù)制等高級一些的功能還沒有提供，有待進(jìn)一步完善。

架構(gòu)

AWS App Mesh 是一個商業(yè)產(chǎn)品，目前還沒有找到架構(gòu)上的技術(shù)細(xì)節(jié)，不過我們依然可以從現(xiàn)有的、公開的文檔或介紹中發(fā)現(xiàn)一些有用的信息。

從這張官網(wǎng)的結(jié)構(gòu)圖中可以看出，每個服務(wù)的橙色部分就是 Sidecar 代理：Envoy。而中間的 AWS App Mesh 其實就是控制平面，用來控制服務(wù)間的交互。那么這個控制平面具體的功能是什么呢？我們可以從今年的 AWS Summit 的一篇 PPT 中看到這樣的字樣：

控制平面用來把邏輯意圖轉(zhuǎn)換成代理配置，并進(jìn)行分發(fā)。

熟悉 Istio 架構(gòu)的朋友有沒有覺得似曾相識？沒錯，這個控制平面的職責(zé)和 Pilot 基本一致。由此可見，不管什么產(chǎn)品的控制平面，也必須具備這些核心的功能。

那么在平臺的支持方面呢？下面這張圖展示了 App Mesh 可以被運行在如下的基礎(chǔ)設(shè)施中，包括 EKS、ECS、EC2 等等。當(dāng)然，這些都必須存在于 AWS 這個閉環(huán)生態(tài)中。

而 Istio 這方面就相對弱一些。盡管 Istio 宣稱是支持多平臺的，但目前來看和 Kubernetes 還是強依賴。不過它并不受限于單一的云平臺，這一點有較大的優(yōu)勢。

從可觀測性來看，App Mesh 依然發(fā)揮了自家生態(tài)的優(yōu)勢，可以方便的接入 CloudWatch、X-Ray 對服務(wù)進(jìn)行觀測。另外，App Mesh 也提供了更大的靈活性，可以在虛擬節(jié)點里配置服務(wù)后端（可以是虛擬服務(wù)或者 ARN），流量可以出站到這些配置的服務(wù)。這一點來說，和 Istio 的 Mixer 又有了異曲同工之妙。Mixer 通過插件方式為 Istio 提供了極大的可擴展性，App Mesh 在這一點上也不算落下風(fēng)。

Istio 的架構(gòu)大家都非常熟悉了，這里就不再贅述了，感興趣的同學(xué)可以直接去官網(wǎng)查看。

功能與實現(xiàn)方式部署

Istio 部署后類似一個網(wǎng)一樣附著在你的 Kubernetes 集群上，控制平面會使用你設(shè)置的資源；而 App Mesh 是一種托管方式，只會使用 Envoy 代理。完整安裝后的 Istio 需要添加 50 個左右的 CRD，而 App Mesh 只添加了 3 個 CRD：meshes.appmesh.k8s.aws，virtualnodes.appmesh.k8s.aws 和 virtualservices.appmesh.k8s.aws。這一點也反映出了功能上的區(qū)別。

流量控制

盡管兩者的數(shù)據(jù)平面都是基于 Envoy，但它們提供的流量控制能力目前還是有比較大的差距的。在路由的設(shè)置方面，App Mesh 提供了相對比較豐富的匹配策略，基本能滿足大部分使用場景。下面是 App Mesh 控制臺里的路由配置截圖，可以看出，除了基本的 URI 前綴、HTTP Method 和 Scheme 外，也支持請求頭的匹配。

Istio 的匹配策略更加完善，除了上面提到的，還包括 HTTP Authority，端口匹配，請求參數(shù)匹配等，具體信息可以從官方文檔的虛擬服務(wù)設(shè)置查看。下面兩段 yaml 分別展示了兩個產(chǎn)品在虛擬服務(wù)配置上的差異。

App Mesh 配置：

apiVersion: appmesh.k8s.aws/v1beta1
kind: VirtualService
metadata:
 name: my-svc-a
 namespace: my-namespace
spec:
 meshName: my-mesh
 routes:
 - name: route-to-svc-a
 http:
 match:
 prefix: /
 action:
 weightedTargets:
 - virtualNodeName: my-app-a
 weight: 1

Istio 配置：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: ratings-route
spec:
 hosts:
 - ratings.prod.svc.cluster.local
 http:
 - match:
 - headers:
 end-user:
 exact: jason
 uri:
 prefix:  /ratings/v2/ 
 ignoreUriCase: true
 route:
 - destination:
 host: ratings.prod.svc.cluster.local

另外一個比較大的不同是，App Mesh 需要你對不同版本的服務(wù)分開定義（即定義成不同的虛擬服務(wù)），而 Istio 是通過目標(biāo)規(guī)則 DestinationRule 里的子集 subsets 和路由配置做的關(guān)聯(lián)。本質(zhì)上它們沒有太大區(qū)別。

除了路由功能外，App Mesh 就顯得捉襟見肘了。就在筆者撰寫本文時，AWS 剛剛添加了重試功能。而 Istio 借助于強大的 Envoy，提供了全面的流量控制能力，如超時重試、故障注入、熔斷、流量鏡像等。

安全

在安全方面，兩者的實現(xiàn)方式具有較大區(qū)別。默認(rèn)情況下，一個用戶不能直接訪問 App Mesh 的資源，需要通過 AWS 的 IAM 策略給用戶授權(quán)。比如下面的配置是容許用戶用任意行為去操作網(wǎng)格內(nèi)的任意資源：

{
  Version :  2012-10-17 ,
  Statement : [
 {
  Effect :  Allow ,
  Action : [
  appmesh:* 
 ],
  Resource :  * 
 }
 ]
}

而虛擬節(jié)點間的授權(quán)方面，App Mesh 目前只有 TLS 訪問的支持，且僅僅是預(yù)覽版（Preview）并未正式發(fā)布。下面的配置展示了一個虛擬節(jié)點只容許 tls 方式的訪問：

{
  meshName  :  app1 ,
  spec  : {
  listeners  : [
 {
  portMapping  : {
  port  : 80,
  protocol  :  http 
 },
  tls  : {
  mode  :  STRICT ,
  certificate  : {
  acm  : {
  certificateArn  :  arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012 
 }
 }
 }
 }
 ],
  serviceDiscovery  : {
  dns  : {
  hostname  :  serviceBv1.mesh.local 
 }
 }
 },
  virtualNodeName  :  serviceBv1 
}

而 Istio 中端到端的認(rèn)證是支持 mTLS 的，同時還支持 JWT 的用戶身份認(rèn)證。下面的配置分別展示了這兩種認(rèn)證方式：

apiVersion:  authentication.istio.io/v1alpha1 
kind:  Policy 
metadata:
 name:  reviews 
spec:
 targets:
 - name: reviews
 peers:
 - mtls: {}
origins:
- jwt:
 issuer:  https://accounts.google.com 
 jwksUri:  https://www.googleapis.com/oauth3/v3/certs 
 trigger_rules:
 - excluded_paths:
 - exact: /health

Istio 的授權(quán)是通過 RBAC 實現(xiàn)的，可以提供基于命名空間、服務(wù)和 HTTP 方法級別的訪問控制。這里就不具體展示了，大家可以通過官網(wǎng)文檔來查看。

可觀察性

一般來說，可以通過三種方式來觀察你的應(yīng)用：指標(biāo)數(shù)據(jù)、分布式追蹤、日志。Istio 在這三個方面都有比較完整的支持。指標(biāo)方面，可以通過 Envoy 獲取請求相關(guān)的數(shù)據(jù)，同時還提供了服務(wù)級別的指標(biāo)，以及控制平面的指標(biāo)來檢測各個組件的運行情況。通過內(nèi)置的 Prometheus 來收集指標(biāo)，并使用 Grafana 展示出來。分布式追蹤也支持各種主流的 OpenTracing 工具，如 Jaeger、Zipkin 等。訪問日志一般都通過 ELK 去完成收集、分析和展示。另外，Istio 還擁有 Kiali 這樣的可視化工具，給你提供整個網(wǎng)格以及微服務(wù)應(yīng)用的拓?fù)湟晥D?？傮w來說，Istio 在可觀察方面的能力是非常強大的，這主要是因為 Mixer 組件的插件特性帶來了巨大的靈活性。

App Mesh 在這方面做的也不錯。在如下圖虛擬節(jié)點的配置中可以看到，你可以配置服務(wù)的后端基礎(chǔ)設(shè)施，這樣流量就可以出站到這些服務(wù)。同時，在日志收集方面，也可以配置到本地日志，或者是其他的日志系統(tǒng)。

另一方面，AWS 又一次發(fā)揮了自己閉環(huán)生態(tài)的優(yōu)勢，提供了 App Mesh 與自家的 CloudWatch、X-Ray 這兩個監(jiān)控工具的整合。總的來說，App Mesh 在可觀察性上也不落下風(fēng)。

“AWS App Mesh 和 Istio 怎么配置”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實用文章！