AWS App Mesh vs Istio

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

前言

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

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

概念

產品定位

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

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

核心術語

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

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

上面的圖展示了這幾個概念的關係：當用戶請求一個虛擬服務時，服務配置的路由器根據路由策略將請求指向對應的虛擬節點，這些節點本質上是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是一個商業產品，目前還沒有找到架構上的技術細節，不過我們依然可以從現有的、公開的文檔或介紹中發現一些有用的信息。

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

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

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

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

而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外，也支持請求頭的匹配。

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在這方面做的也不錯。在如下圖虛擬節點的配置中可以看到，你可以配置服務的後端基礎設施，這樣流量就可以出站到這些服務。同時，在日誌收集方面，也可以配置到本地日誌，或者是其他的日誌系統。

另一方面，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

AWS App Mesh vs Istio

前言

概念

產品定位

核心術語

架構

功能與實現方式

部署

流量控制

安全

可觀察性

總結

參考

關於 ServiceMesher 社區

DAPPER 事務 TRANSACTION

Istio 1.8 發佈——用戶至上的選擇

httpfs安裝指南

在CentOS 6.5上安裝OpenLDAP並配置LDAP方式用戶登錄

PuppetDB安裝指南

博客搬家到https://jimmysong.io - Cloud Native 雲原生

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結