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等），竞争也会逐渐激烈。将来是三分天下仍是一统山河，让咱们拭目以待。

参考

• what is app mesh
• aws app mesh roadmap
• Redefining application communications with AWS App Mesh
• istio offical

关于 ServiceMesher 社区

ServiceMesher 社区是由一群拥有相同价值观和理念的志愿者们共同发起，于 2018 年 4 月正式成立。

社区关注领域有：容器、微服务、Service Mesh、Serverless，拥抱开源和云原生，致力于推进 Service Mesh 在中国的蓬勃发展。

社区官网：https://www.servicemesher.com