服务网格——平台战争的新战场

容器的兴起带动了微服务化的出现，在这种模式里，软件被开发和部署为细粒度（fine-grained）的服务。多个服务协同工作用以交付应用程序的功能需求。

基于微服务的应用程序在开发、部署和管理时存在着许多挑战。尽管像Kubernetes这样的容器管理平台承担了繁重的工作，然而，开发人员和运维人员还是需要部署多个技术来管理他们的微服务。

部署和管理微服务所面临的挑战带来了一种全新的、以应用程序为中心的网络层的发展，称为服务网格。

什么是服务网？

服务网格是一个高效、轻量级的网络层，高度优化了工作负载。它被设计成可以跨语言、框架和工具包，使开发人员能够专注于他们最擅长的事——敲代码。

推荐阅读：

服务网格作为一种抽象层，为服务到服务的通信和管理网络流量提供所需的管道。服务网格对微服务是透明的，无需修改代码就可以将其添加到每个服务。

服务网格适用于任何协议和任何部署。开发人员可以将其与REST、HTTP、HTTP/2和其他协议集成。网格在开发、Stage和生产环境中一致地工作，这些环境运行在VM （IaaS）、平台（PaaS）或容器（CaaS）上。

通过使用行业标准的相互身份验证协议（mTLS），服务网格可以自动确保两个微服务之间的通信安全。最利好的一点是，微服务的代码和配置可以保持不变，这样就没有变更需求。

通过使用服务网格，运维人员可以部署动态网络策略来控制部署中的通信。这些策略支持高级配置，比如蓝/绿部署和金丝雀发布。

由于服务网格拦截微服务的每个入站和出站的调用，因此它对网络流量获得了无与伦比的可见性，从而可以更深入了解微服务之间的通信。在可观测和监控层，由服务网格产生的监测数据被作为非常有价值的输入数据。

因此，简单地说，服务网格是一个标准的软件，它以透明和非侵入的机制附加到每个服务，提供三个关键功能：

1）服务之间的安全通信

2）动态控制流量的网络策略

3）可观测性

即Kubernetes之后，服务网格技术已经成为云原生技术栈中最关键的组件。平台供应商和云供应商现在正将他们的关注点转移到服务网格上，为开发和运维人员提供差异化的体验。

比较有意思的是，大部分的服务网格平台都是基于Envoy——一个最初由Matt Klein在Lyft创建的开源项目。Envoy充当一个代理，它将自己添加到每个微服务以拦截入站和出站流量。一个中央组件承担下发指令和控制中心的角色，以管理环境中被Envoy代理的多个实例。虽然Envoy保持通用的原则，然而集中化管理平台在不同的网格部署之间还是有很大的不同。

服务网络正迅速成为平台战争的战场。亚马逊（Amazon）、Google、微软（Microsoft）、IBM、红帽(（ed Hat）、VMware和许多其他ISV都在争相赢取开发和运维人员的青睐。

下面是现阶段Service Mesh生态的小结。

AWS AppMesh——亚马逊自有的服务网格

AWS App Mesh于2018年发布，旨在为亚马逊的计算和容器服务增加服务网格所具备的优势。它可以轻松地配置在EC2、ECS、Fargate、EKS服务上，甚至是Outposts。

像大多数的Service Mesh平台一样，AWS App Mesh也依赖于与微服务相关的开源Envoy平台。App Mesh控制平台是基于AWS计算服务构建的。亚马逊还定制了Envoy代理来支持这个控制。

按照典型的亚马逊风格，AWS的工程师们依托并扩展了开源的Envoy代理，提供了一种商业的、可管理的服务，并且被设计用于与亚马逊的计算服务一起工作。它的构建主要是为了让客户能够集成部署在VM、容器和无服务器环境中的服务。它的观测特性也被扩展到第三方服务，如Datadog、SignalFX和Solarwinds。

Googl在Istio上下了大赌注

Google是目前最流行的Open Service Mesh —— Istio的关键贡献者之一。除了Google之外，IBM和Red Hat也是积极的贡献者。Istio是基于Envoy代理与Kubernetes紧密集成的控制平台。

从Istio诞生之日起，开源和云原生社区就希望它成为云原生计算基金会（CNCF）的一部分。但是，Google却最终将Istio捐赠给一个新成立的组织：Open Usage Commons，这个组织由Google、SADA、独立的开源维护者和计算机科学学者创建。虽然这意味着Istio商标将不再属于Google，但它仍然对项目的路线图和发展具有影响力。OUC由Google的现任和前任雇员、合伙人和来自Google资助机构的学者组成。

OUC的成立并不意味着Istio正在变成一个闭源项目。它在Apache 2.0许可下仍然可用，这意味着任何人都可以复制、使用、分发和为项目做出贡献。在Istio转让给OUC后，公司不能以一种会迷惑消费者的方式使用Istio这个名字或它的标识。

Google的这一举动引起了许多人的惊讶，尤其是IBM，后者一直是Istio的关键贡献者。一些行业分析人士认为，这是为了保持Google对Istio项目的控制和影响力。

在Kubernetes之后，Istio成为了Google技术栈的核心模块。Knative是一个建立在Kubernetes上的无服务器平台，它的根基是Istio。Google扩展了Knative以增强Kubernetes的开发体验。Cloud Run是一个商业的、专有的Google云服务，它就是基于Knative。Google的现代化应用平台Anthos依赖于Istio。Google扩展了Istio，通过Anthos服务网格部署在混合云和多云。展望未来，Istio和Anthos服务网格将在Google基于5G的移动边缘云和多云场景中发挥关键作用。

下了这么多赌注，然而Google并不希望它的竞争对手过于拥抱和扩展Istio，这样会削弱其独特性和差异化的实施方式。

微软SMI和OSM的标准定义

作为对AWS App Mesh和Anthos Service Mesh的回应，微软预计会宣布自己在Azure上的Service Mesh。但有趣的是，微软先是制定一个标准，从服务网格的可互操作性上先下手。

随着Google在Istio上的大量投入和AWS推出的App Mesh作为一项专有的管理服务，微软看到了标准化服务网格技术的机会。微软没有构建自己的技术与Azure计算服务集成，而是与行业合作伙伴一起发布了一个名为Service Mesh Interface的开放规范。

服务网格接口（SMI）定义了一个可以由各种贡献者实施的通用标准。它通过一组定义良好的标准化API实现应用程序的解耦。任何服务网格的实施都可以遵循SMI标准，而开发人员可以在不知道实施细节的情况下使用SMI API。

在很多方面，SMI带来了与其他云原生标准，如容器运行时接口（Container Runtime Interface）、容器存储接口（Container Storage Interface）和容器网络接口（Container Network Interface）相同的抽象级别。这些接口提供了阅读友好的、文档化的API，它可以在不改变代码的情况下实现各种交互部署。对于SMI，开发人员不需要直接使用Istio或Linkerd API，而是使用标准API，这些API被转换为底层的服务网格来进行部署。

SMI的努力受到了云原生生态系统的好评。一些著名的供应商，如HashiCorp，Buoyant，Solo.io。Aspen Mesh要么使他们的部署与SMI兼容，一壶水为他们的技术构建适配器。SMI已经找到了迈进CNCF的途径，当前处于Sandbox状态。

在Google宣布将Istio商标转让给OCU几天后，微软推出了一个开源的SMI，称为Open Service Mesh。OSM定位为SMI的参考实例，是一个成熟的基于Envoy代理的服务网络。OSM进入了拥挤的服务网生态系统，作为另一个基于Envoy的实现。

经过一个月的公告，OSM被提交给CNCF成为一个沙箱项目。看看微软是如何发展OSM的，以及它是如何与Azure集成的，这将是很有趣的。

充满活力的服务网络生态系统

服务网状生态系统并不局限于亚马逊、Google和微软。这是一个充满活力的社区，有许多已建立的平台供应商和处于早期阶段的初创公司在积极推动技术的演进。

IBM/Red Hat是Istio的主要倡导者之一。IBM Cloud Kubernetes Service（IKS）上的Istio是作为托管的附加组件提供的，它直接集成了Istio和托管的Kubernetes集群。客户可以单击复选框，在IKS集群中部署一个调优的、可用于生产的Istio实例。在Google之后，IBM是唯一提供托管Istio服务的云提供商。

Red Hat通过OperatorHub提供的服务网格操作器集成了Istio和OpenShift。Red Hat也同时参与在SMI项目，以推动其服务网格技术在OpenShift上运行的互操作性。

VMware已经将其软件定义网络NSX扩展到服务网格领域。该服务被命名为VMware Tanzu Service Mesh，与VMware的Kubernetes平台Tanzu Enterprise Grid紧密结合。Tanzu Service Mesh运行在多个应用平台、公有云和运行时环境上，包括Kubernetes集群。

现在，可以为客户提供服务网格的产品有：Aspen mesh，Envoy，Grey Matter, Kuma, Linkerd, Maesh, SuperGloo和Tetrate。

原文链接： https://www.forbes.com/sites/j ... 13021