Service Mesh，云服务商的新战场 原创

容器技术的兴起形成了新的微服务范式。在这种全新范式中，软件将以细粒度服务的形式进行开发与部署。多项服务能够协同运作，共同为应用程序提供预期的功能。

但基于微服务架构的应用程序在开发、部署与管理方面总会带来诸多挑战。虽然Kubernetes等容器管理平台已经能够分担掉相当一部分繁重工作，但开发人员与运营人员还是希望通过更多技术管理生产环境中的微服务体系。

面对微服务部署与管理层面的现实挑战，以应用程序为中心的全新网络层Service Mesh开始生根发芽。

Service Mesh是什么?

Service Mesh是一种针对现代工作负载进行高度优化的高效、轻量化网络层。它在设计上强调语言、框架与工具包中立性，确保开发人员能够专注于处理自己最擅长的编码工作。

Service Mesh充当的是抽象层，负责为服务到服务之间的通信与网络流量提供管理支持。Service Mesh对微服务而言完全透明，无需修改代码即可将其附加至各项服务当中。

Service Mesh能够与任何协议乃至部署目标协同使用。开发人员可以将它与REST、HTTP、HTTP/2乃至其他协议轻松集成。整个网格还能够在跨虚拟机（IaaS）、平台（PaaS）乃至容器（CaaS）运行的开发、分段与生产环境中保持统一且稳定的运行状态。Service Mesh通过行业标准的双向身份验证协议（mTLS）自动保护两项微服务之间的通信内容。更重要的是，其不会对微服务本体的代码与配置产生任何影响。

借助Service Mesh，运营人员可以实施动态网络策略，借此控制部署环境中的往来流量。这些策略还可启用多种高级配置，包括蓝/绿部署以及金丝雀发布等选项。Service Mesh会拦截微服务上的每一项入站与出站调用，因此拥有无与伦比的网络流量可见性，可以借此建立起深刻的运行洞见。凭借这种特性，Service Mesh生成的遥测数据成为可观察性与监控层的宝贵输入素材。

简单来说，Service Mesh是一种标准软件，能够以透明且非侵入方式接入每项服务，进而提供三项关键功能：1) 实现服务之间的安全通信；2) 使用网络策略动态控制流量；3) 可观察性。

继Kubernetes之后，Service Mesh技术已经成为云原生堆栈中最关键的组成部分。各大平台供应商与云服务商纷纷将关注重心转移至Service Mesh身上，借此为开发人员及运营人员提供与众不同的使用体验。

有趣的是，大多数Service Mesh平台都以Envoy为基础。作为Matt Klein最初在Lyft建立的开源项目，Envoy会以代理的形式附加至每项微服务，进而拦截入站与出站流量。与之配套的集中式组件负责扮演命令与控制中心角色，持续管理环境中运行的多个Envoy代理实例。虽然拥有Envoy这一共通元素，但不同网格实现方案在集中管理平面上仍然存在不小的差异。

凭借强大的功能与难以替代的地位，Service Mesh很快成为平台大战中的又一主要战场。Amazon、谷歌、微软、IBM、Red Hat、VMware乃至众多独立软件开发商都在努力赢取开发人员与运营人员的青睐。

下面，我们一同了解Service Mesh生态系统的总体现状。

AWS AppMesh - Amazon的原研Service Mesh

首次亮相于AWS re: Invent 2018大会的AWS App Mesh，旨在将Service Mesh的优势全面引入Amazon计算与容器服务当中。可以使用EC2、ECS、Fargate、Elastic Kubernetes Service甚至是Outposts轻松配置App Mesh。

与大多数其他Service Mesh平台一样，AWS App Mesh同样以Envoy这一与微服务紧密相关的开源代理数据平面为基础。App Mesh控制平面在设计之初就充分考虑到AWS计算服务的实际需求。此外，Amazon还开发出定制化Envoy代理以支持这套控制平面。

沿袭Amazon的一贯风格，AWS工程师们接纳并拓展了开源Envoy代理，打造出一项只能与自家计算服务配套使用的商业托管服务。Amazon的目标非常明确——确保客户能够将跨虚拟机、容器乃至无服务器环境部署的各项服务集成起来。其还将可观察性功能扩展到更多第三方服务，包括Datadog、SignalFX以及SolarWinds。

谷歌倾力支持Istio

谷歌是目前最受欢迎的开源Service Mesh项目Istio的主要贡献者之一。除谷歌之外，IBM与Red Hat也积极参与到项目贡献中来。Istio基于Envoy代理，借此获得能够与Kubernetes紧密集成的强大控制平面。

从立项之初，开源与云原生社区就希望Istio能够成为云原生计算基金会（CNCF）的一部分。但最终，谷歌决定将Istio商标捐赠给由谷歌、SADA、独立开源维护者以及计算机科学学者们共同建立的新机构Open Usage Commons（OUC）。虽然此举弱化了谷歌对Istio商标的掌握能力，但搜索巨头仍对项目的发展路线图保持着重大影响力。OUC由谷歌资助机构中的前任及现任谷歌员工、合作伙伴以及学术研究人员共同组成。

OUC的成立诉求并不是将Istio转变成闭源项目。相反，Istio仍然采用Apache 2.0许可证，任何人皆可复制、使用、发布项目并为其做出贡献。在将Istio商标与徽标移交给OUC之后，任何企业不得继续使用Istio名称或其徽标，避免给用户造成不必要的误解。当然，谷歌的这一举动也引发了多方关注，特别是同样身为Istio主要贡献者的IBM。部分行业分析师甚至认为，谷歌的这招欲擒故纵其实是为了更好地保持对Istio项目的控制与影响能力。

继Kubernetes之后，Istio同样成为谷歌技术堆栈中的核心组成部分。以Kubernetes为基础构建而成的无服务器平台Knative，其源头就可以追溯至Istio。谷歌扩展了Knative以增强Kubernetes的开发者使用体验。商业专有谷歌云服务Cloud Run就以Knative为基础，此外谷歌的应用程序现代化平台Anthos也高度依赖于Istio。谷歌扩展了Istio，借此通过Anthos Service Mesh实现多云与混合功能。展望未来，Istio与Anthos Service Mesh都将在5G网络支持下的谷歌边缘云及多云场景中发挥关键作用。

而且面对竞争风险，谷歌也明显不希望竞争对手的加入削弱Istio的独特性与差异性。

微软通过SMI与OSM定义新标准

为了正面对抗AWS App Mesh与Anthos Service Mesh，微软照理说肯定要在自家云平台Azure上公布相应的Service Mesh实现方案。但有趣的是，微软决定另辟蹊径，着力在不同Service Mesh之间建立起互操作标准。

面对谷歌对Istio的倾力投入，以及AWS以专有托管服务的形式发布App Mesh，微软看到了为Service Mesh技术制定行业标准的重大机遇。与其建立与Azure计算服务相集成的自有技术，微软决定与行业合作伙伴共同发布名为Service Mesh Interface的开放规范。

Service Mesh Interface (SMI)负责定义面向各类供应商的通用标准。SMI通过一组经过明确定义的标准化API，将Service Mesh实现与应用程序区分开来。任何Service Mesh实现都可以遵循SMI标准，确保开发人员能够在不涉及实现细节的前提下使用SMI API。

大体来讲，SMI带来了与其他云原生标准——包括容器运行时接口（CRI）、容器存储接口（CSI）、容器网络接口（CNI）等——相同的抽象层级。这些接口负责提供广泛接受且拥有明确标定的API，允许用户在不更改代码的情况下切入/切出各类实现方法。使用SMI，开发人员不再需要直面Istio或者Linkerd API，而可以通过标准API将自己的操作转换为相应的底层Service Mesh实现。

云原生生态系统对SMI表达出了应有的热情。包括HashiCorp、Buoyant、Solo.io以及Aspen Mesh在内的一系列著名供应商要么推出了SMI兼容功能，要么构建了相应的适配器。目前，SMI已经以沙箱孵化项目的形式加入CNCF。

就在谷歌宣布将Istio商标转让给OUC的几天之后，微软就发布了SMI的开源实现，名为Open Service Mesh (OSM)。OSM属于SMI的参考实现方案，属于一套基于Envoy代理的成熟Service Mesh。本就拥挤的Service Mesh生态系统如今又挤进一位基于Envoy的新成员。

在发布一个月后，LSM被提交给CNCF成为沙箱孵化项目。我们期待微软后续会如何规划OSM的发展、又会怎样将其与Azure云体系集成起来。

背后活力满满的生态系统

Service Mesh生态系统绝对不仅仅限于亚马逊、谷歌与微软等巨头。这是个充满活力的社区，吸引到众多知名的平台供应商与早期创业公司，各参与方在这里共同推动着技术的发展与应用。

IBM/Red Hat就是Istio的主要倡导者之一。IBM Cloud Kubernetes Service（IKS）就将Istio以托管附件的形式交付，允许用户直接将Istio与托管Kubernetes集成相集成。客户只需勾选相应复选框，就能在IKS集群当中部署经过调优且适合生产应用的Istio实例。除谷歌之后，IBM也是唯一提供托管Istio服务的云服务商。

Red Hat则通过OperatorHub提供的Service Mesh操作程序将Istio与OpenShift集成起来。Red Hat同样是SMI项目成员，努力改善其Service Mesh技术与OpenShift的互操作性。

VMware也将自家软件定义网络NSX扩展至Service Mesh领域。此项服务被命名为VMware Tanzu Service Mesh，能够与VMware的Kubernetes平台Tanzu Enterprise Grid紧密集成。Tanzu Service Mesh能够在多种应用平台、公有云以及运行时环境（包括Kubernetes集群）上运行。

此外，Aspen Mesh、Consul、Grey Matter、Kuma、Linkerd、Maesh、SuperGloo以及Tetrate等Service Mesh实现方案也为用户们带来丰富的差异化选项。