AWS App Mesh vs Istio

時間  2019-11-06
標籤 aws app mesh istio 简体版
原文   原文鏈接

做者: 馬若飛，lead software engineer in FreeWheel，《Istio實戰指南》做者，ServiceMesher社區管委會成員。html

前言

近兩年隨着微服務架構的流行，服務網格（Service Mesh）技術受到了愈來愈多的人關注，並擁有了大批的擁躉。目前市面上比較成熟的開源服務網格主要有下面幾個：Linkerd，這是第一個出如今公衆視野的服務網格產品，由Twitter的finagle庫衍生而來，目前由Buoyant公司負責開發和維護；Envoy，Lyft開發而且是第一個從CNCF孵化的服務網格產品，定位於通用的數據平面或者單獨做爲Sidecar代理使用；Istio，由Google、IBM、Lyft聯合開發的所謂第二代服務網格產品，控制平面的加入使得服務網格產品的形態更加完整。node

服務網格技術做爲構建雲原生應用的重要一環，逐漸的被愈來愈多的人和廠商承認，並看好它的發展前景。在Istio大紅大紫的今天，做爲和Google在雲服務市場競爭的Amazon來講，天然不肯錯失這塊巨大的蛋糕。他們在今年4月份發佈了本身的服務網格產品：AWS App Mesh。本文會聚焦於Istio和App Mesh這兩個產品，經過橫向的對比分析讓你們對它們有一個更深刻的認識。git

概念

產品定位

從官方的介紹來看，Istio和App Mesh都比較明確的表示本身是一種服務網格產品。Istio強調了本身在鏈接、安全、控制和可視化4個方面的能力；而App Mesh主要強調了一致的可見性和流量控制這兩方面能力，固然也少不了強調做爲雲平臺下的產品的好處：託管服務，無需本身維護。github

從某種程度上講，Istio是一個相對重一點的解決方案，提供了不限於流量管理的各個方面的能力；而App Mesh是更加純粹的服務於運行在AWS之上的應用並提供流控功能。筆者認爲這和它目前的產品形態還不完善有關（後面會具體提到）。從與AWS內部開發人員的溝通中能夠感受到，App Mesh應該是一盤很大的棋，目前只是初期階段而已。後端

核心術語

和AWS裏不少產品同樣，App Mesh也不是首創，而是基於Envoy開發的。AWS這樣的閉環生態必然要對其進行改進和整合。同時，也爲了把它封裝成一個對外的服務，提供適當的API接口，在App Mesh這個產品中提出了下面幾個重要的技術術語，咱們來一一介紹一下。api

  • 服務網格（Service mesh）：服務間網絡流量的邏輯邊界。這個概念比較好理解，就是爲使用App mesh的服務圈一個虛擬的邊界。
  • 虛擬服務（Virtual services）：是真實服務的抽象。真實服務能夠是部署於抽象節點的服務，也能夠是間接的經過路由指向的服務。
  • 虛擬節點（Virtual nodes）：虛擬節點是指向特殊工做組（task group）的邏輯指針。例如AWS的ECS服務，或者Kubernetes的Deployment。能夠簡單的把它理解爲是物理節點或邏輯節點的抽象。
  • Envoy：AWS改造後的Envoy（將來會合併到Envoy的官方版本），做爲App Mesh裏的數據平面，Sidecar代理。
  • 虛擬路由器（Virtual routers）：用來處理來自虛擬服務的流量。能夠理解爲它是一組路由規則的封裝。
  • 路由（Routes）：就是路由規則，用來根據這個規則分發請求。

appmesh

上面的圖展現了這幾個概念的關係：當用戶請求一個虛擬服務時，服務配置的路由器根據路由策略將請求指向對應的虛擬節點，這些節點本質上是AWS裏的EKS或者ECS的節點。安全

那麼這些App Mesh自創的術語是否能在Istio中找到類似甚至相同的對象呢？我概括了下面的表格來作一個對比：網絡

App Mesh
 Istio
服務網格（Service mesh）
 Istio並未顯示的定義這一律念，咱們能夠認爲在一個集羣中，由Istio管理的服務集合，它們組成的網絡拓撲便是服務網格。
虛擬服務（Virtual services）
 Istio中也存在虛擬服務的概念。它的主要功能是定義路由規則，使請求能夠根據這些規則被分發到對應的服務。從這一點來講，它和App Mesh的虛擬服務的概念基本上是一致的。
虛擬節點（Virtual nodes）
 Istio沒有虛擬節點的概念，能夠認爲相似Kubernetes裏的Deployment。
虛擬路由器（Virtual routers） Istio也沒有虛擬路由器的概念。
路由（Routes）
 Istio中的目標規則（DestinationRule）和路由的概念相似，爲路由設置一些策略。從配置層面講，其中的子集（subset）和App Mesh路由裏選擇的目標即虛擬節點對應。但Istio的目標規則更加靈活，也支持更多的路由策略。

從上面的對比看出，App Mesh目前基本上實現了最主要的流量控制（路由）的功能，但像超時重試、熔斷、流量複製等高級一些的功能尚未提供，有待進一步完善。架構

架構

AWS App Mesh是一個商業產品，目前尚未找到架構上的技術細節，不過咱們依然能夠從現有的、公開的文檔或介紹中發現一些有用的信息。app

arch1

從這張官網的結構圖中能夠看出，每一個服務的橙色部分就是Sidecar代理：Envoy。而中間的AWS App Mesh其實就是控制平面，用來控制服務間的交互。那麼這個控制平面具體的功能是什麼呢？咱們能夠從今年的AWS Summit的一篇PPT中看到這樣的字樣：

控制平面用來把邏輯意圖轉換成代理配置，並進行分發。

arch2

熟悉Istio架構的朋友有沒有以爲似曾相識？沒錯，這個控制平面的職責和Pilot基本一致。因而可知，無論什麼產品的控制平面，也必須具有這些核心的功能。

那麼在平臺的支持方面呢？下面這張圖展現了App Mesh能夠被運行在以下的基礎設施中，包括EKS、ECS、EC2等等。固然，這些都必須存在於AWS這個閉環生態中。

arch3

而Istio這方面就相對弱一些。儘管Istio宣稱是支持多平臺的，但目前來看和Kubernetes仍是強依賴。不過它並不受限於單一的雲平臺，這一點有較大的優點。

從可觀測性來看，App Mesh依然發揮了自家生態的優點，能夠方便的接入CloudWatch、X-Ray對服務進行觀測。另外，App Mesh也提供了更大的靈活性，能夠在虛擬節點裏配置服務後端（能夠是虛擬服務或者ARN），流量能夠出站到這些配置的服務。這一點來講，和Istio的Mixer又有了殊途同歸之妙。Mixer經過插件方式爲Istio提供了極大的可擴展性，App Mesh在這一點上也不算落下風。

Istio的架構你們都很是熟悉了，這裏就再也不贅述了，感興趣的同窗能夠直接去官網查看。

功能與實現方式

部署

Istio部署後相似一個網同樣附着在你的Kubernetes集羣上， 控制平面會使用你設置的資源；而App Mesh是一種託管方式，只會使用Envoy代理。完整安裝後的Istio須要添加50個左右的CRD，而App Mesh只添加了3個CRD：meshes.appmesh.k8s.aws，virtualnodes.appmesh.k8s.aws和virtualservices.appmesh.k8s.aws。這一點也反映出了功能上的區別。

流量控制

儘管二者的數據平面都是基於Envoy，但它們提供的流量控制能力目前仍是有比較大的差距的。在路由的設置方面，App Mesh提供了相對比較豐富的匹配策略，基本能知足大部分使用場景。下面是App Mesh控制檯裏的路由配置截圖，能夠看出，除了基本的URI前綴、HTTP Method和Scheme外，也支持請求頭的匹配。

appmesh-route

Istio的匹配策略更加完善，除了上面提到的，還包括HTTP Authority，端口匹配，請求參數匹配等，具體信息能夠從官方文檔的虛擬服務設置查看。下面兩段yaml分別展現了兩個產品在虛擬服務配置上的差別。

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須要你對不一樣版本的服務分開定義（即定義成不一樣的虛擬服務），而Istio是經過目標規則 DestinationRule 裏的子集 subsets 和路由配置作的關聯。本質上它們沒有太大區別。

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

安全

在安全方面，二者的實現方式具備較大區別。默認狀況下，一個用戶不能直接訪問App Mesh的資源，須要經過AWS的IAM策略給用戶受權。好比下面的配置是允許用戶用任意行爲去操做網格內的任意資源：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "appmesh:*"
            ],
            "Resource": "*"
        }
    ]
}複製代碼

而虛擬節點間的受權方面，App Mesh目前只有TLS訪問的支持，且僅僅是預覽版（Preview）並未正式發佈。下面的配置展現了一個虛擬節點只允許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中端到端的認證是支持mTLS的，同時還支持JWT的用戶身份認證。下面的配置分別展現了這兩種認證方式：

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/oauth2/v3/certs"
    trigger_rules:
    - excluded_paths:
      - exact: /health複製代碼

Istio的受權是經過RBAC實現的，能夠提供基於命名空間、服務和HTTP方法級別的訪問控制。這裏就不具體展現了，你們能夠經過官網文檔來查看。

可觀察性

通常來講，能夠經過三種方式來觀察你的應用：指標數據、分佈式追蹤、日誌。Istio在這三個方面都有比較完整的支持。指標方面，能夠經過Envoy獲取請求相關的數據，同時還提供了服務級別的指標，以及控制平面的指標來檢測各個組件的運行狀況。經過內置的Prometheus來收集指標，並使用Grafana展現出來。分佈式追蹤也支持各類主流的OpenTracing工具，如Jaeger、Zipkin等。訪問日誌通常都經過ELK去完成收集、分析和展現。另外，Istio還擁有Kiali這樣的可視化工具，給你提供整個網格以及微服務應用的拓撲視圖。整體來講，Istio在可觀察方面的能力是很是強大的，這主要是由於Mixer組件的插件特性帶來了巨大的靈活性。

App Mesh在這方面作的也不錯。在以下圖虛擬節點的配置中能夠看到，你能夠配置服務的後端基礎設施，這樣流量就能夠出站到這些服務。同時，在日誌收集方面，也能夠配置到本地日誌，或者是其餘的日誌系統。

amob

另外一方面，AWS又一次發揮了本身閉環生態的優點，提供了App Mesh與自家的CloudWatch、X-Ray這兩個監控工具的整合。總的來講，App Mesh在可觀察性上也不落下風。

總結

AWS App Mesh做爲一個今年4月份才發佈的產品，在功能的完整性上和Istio有差距也是情有可原的。從App Mesh的Roadmap能夠看出，不少重要的功能，好比熔斷已經在開發計劃中。以筆者與AWS的開發人員瞭解的信息來看，他們仍是至關重視這個產品，優先級很高，進度也比較快，以前還在預覽階段的重試功能在上個月也正式發佈了。另外，App Mesh是能夠無償使用的，用戶只須要對其中的實例資源付費便可，沒有額外費用。App Mesh一部分的開發重點是和現有產品的整合，好比Roadmap列出的使用AWS Gateway做爲App Mesh的Ingress。藉助着本身的生態優點，這種整合即方便快捷的完善了App Mesh，同時又讓生態內的產品結合的更緊密，使得閉環更加的牢固，不得不說是一步好棋。

和App Mesh目前只強調流控能力不一樣，Istio更多的是把本身打形成一個更加完善的、全面的服務網格系統。架構優雅，功能強大，但性能上受到質疑。在產品的更迭上貌似也作的不盡如人意（不過近期接連發布了1.3到1.3.3版本，讓咱們對它的將來發展又有了期待）。Istio的優點在於3大頂級技術公司加持的強大資源，加上開源社區的反哺，控制好的話容易造成可持續發展的局面，併成爲下一個明星級產品。但目前各大廠商都意識到了網格的重要性並推出本身的產品（AWS App Mesh，Kong的Kuma等），競爭也會逐漸激烈。將來是三分天下仍是一統山河，讓咱們拭目以待。

參考

關於 ServiceMesher 社區

ServiceMesher 社區是由一羣擁有相同價值觀和理念的志願者們共同發起，於 2018 年 4 月正式成立。

社區關注領域有：容器、微服務、Service Mesh、Serverless，擁抱開源和雲原生，致力於推進 Service Mesh 在中國的蓬勃發展。

社區官網：https://www.servicemesher.com

ServiceMesher 社區

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程