到Istio以及以后：Azure的Service Mesh接口

至少在Azure上进行的现代，云优先的应用程序开发几乎已完全依赖Kubernetes。 Virtual Kubelets， AKS（Azure Kubernetes服务）和Azure Service Fabric Mesh等技术是使用容器部署和管理微服务在Azure上构建可扩展的分布式应用程序的关键。

通过查看Azure的Kubernetes工具，很明显，Microsoft在Cloud Native Computing Foundation中及其周围进行了大量工作，涉及开源框架的各个方面。 我们不应该感到惊讶； 微软聘请了Kubernetes项目的创始人之一，然后收购了重要的供应商Deis。 Deis团队支持Azure对Kubernetes生态系统的最新贡献之一， 即Service Mesh Interface（SMI ）。

[您准备好入侵容器了吗？ 了解如何使用Kubernetes入门 。 •到底什么是Kubernetes ？ | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

服务网格介绍

最好首先解释一下服务网格以及为什么它对任何基于Kubernetes的应用程序都很重要。

现代IT体系结构都是关于抽象的。 使用云服务，我们不再需要考虑底层硬件。 如果我们使用的是IaaS，我们将定义虚拟机来托管我们的代码。 使用PaaS，我们从硬件，使用我们选择的服务和API方面走得更远，为我们的应用程序和预算选择了适当的性能水平。 使用Kubernetes之类的基于容器的体系结构，我们处于两者之间的某个位置：使用AKS之类的服务，我们可以定义底层虚拟机，然后托管容器Pod并根据计算和内存的变化进行扩展（以及现在有了KEDA（基于Kubernetes的事件驱动的自动缩放） ，可以接收事件。

那只是抽象的一个方面。 本质上，Kubernetes微服务是无状态的。 他们使用外部存储，位于物理或虚拟网络之上。 运行Kubernetes的网络方面可能是最棘手的：随着服务的扩展和缩小，您需要修改网络以使更改与应用程序匹配。 但是，当应用程序前端和后端可能以不同的速率扩展时，如何保持服务连接？

这就是服务网格的用处。它们是一个新的抽象层，可以利用现代软件定义网络的功能将您的代码从底层网络中分离出来。 通过充当与您的代码一起部署的一组网络代理，服务网格可以管理服务到服务的通信，而您的代码不需要任何对底层网络的了解。 您可以将服务网格视为应用程序网络的自动控制平面，并在Kubernetes上下扩展代码时管理基础控制平面。

微服务的软件定义网络

也许最好的想法是作为一种与服务发现一起实现智能的，可感知延迟的，可扩展的负载平衡的方法，服务网格基本上是具有动态路由规则的分布式路由器，该规则作为Kubernetes部署的一部分进行管理。 您可以定义其他规则。 例如，将生产和测试系统分开，或者处理新版本的部署以及容器版本之间的更改。 应用程序中的每个Pod都有一个作为sidecar运行的服务网格实例，其中服务发现和其他有状态元素在您的服务之外运行。

借助服务网格，您可以将智能推入新的网络层，因此您不必将其放入微服务中。 需要加密连接吗？ 这是您的服务网格的工作。 需要授权客户吗？ 服务网格的另一项任务。

网格太多

将Kubernetes部署与服务网格相结合非常有意义。 但是，还有一个更大的问题：您使用哪一个？ 特使 ？ 伊斯蒂奥 ？ Linkerd ？ 白杨网 如果选择一个，那么阻止您业务另一部分中的开发团队选择其他对象的是什么？ 如果您的公司决定在特定平台上进行标准化，那会发生什么？

这就是Microsoft打算通过Service Mesh Interface解决的问题。 SMI不是每个服务网格都有自己的一组API， 而是一种实现可在不同服务网格上工作的通用API的方法，从而管理该新的智能网络。 无需将代码锁定在特定的服务网格及其API中，您可以编写通过通用API解决最常见用例的代码。 如果您需要换出服务网格-如果您更改了提供程序或找到了更好的服务提供商-只要服务网格实现SMI，就无需更改代码。 您所需要做的就是更改服务网格边车并重新部署代码。

SMI：通用服务网格API

Microsoft与Hashicorp和Buoyant等Kubernetes生态系统公司合作，一直在定义SMI的关键功能，以支持其客户的常见请求。 在初始版本中，它集中在三个领域： 流量策略，流量遥测和流量管理 。 这三个区域由大多数服务网格控制，目的是使它成为易于实现的规范，而无需更改基础应用程序。

通过使SMI成为一组标准API，没有什么可以阻止服务网格供应商继续提供自己的API或指定功能之外的其他功能。 另外，他们不需要进行任何更改。 第三方可以构建位于SMI API和专有服务API之间的转换层。 您也不需要新版本的Kubernetes，因为SMI API被实现为扩展API服务器和自定义资源定义。 您可以继续使用现有管理工具将它们安装在任何群集中。 这将使Azure和其他云托管的Kubernetes服务能够轻松将SMI构建到现有的托管Kubernetes服务中。

无论您是要使用Linkerd还是Aspen Mesh还是VMware的NSX Service Mesh，都可以通过SMI选择您喜欢的一种，从而提高代码的可移植性并避免锁定特定的云服务。 然后就有机会在不影响您的代码的情况下切换服务网格。 如果新的服务网格提供了更好的性能，那么您要做的就是更改构建管道以使用新的网格，然后部署更新的应用程序。

有趣的是，Microsoft领导了这样一个与Kubernetes社区广泛合作的项目。 通过采用一种明确不专注于构建服务网格的方法，Azure可以在配置AKS时提供不同的服务网格，使您无需更改任何代码即可选择所需的工具。

From: https://www.infoworld.com/article/3400116/introducing-the-service-mesh-interface.html