推动服务网格社区前进

服务网格是一组重要的功能，可解决在操作服务样式体系结构时遇到的一些棘手的服务到服务通信挑战。正如Kubernetes和容器有助于为一组计算机上的部署和运行工作负载提供一组不错的抽象一样，服务网格也以一种使操作员和开发人员可以控制请求路由，可观察性和可扩展性的方式来抽象化网络。政策执行。这提供了很大的潜力。

唯一的问题是，尽管Kubernetes已经成为一种强大的API，可以抽象出用于调度工作负载的基础架构，但没有一个实用的API可以显示服务网格中所需的功能。

最近建议在KubeCon EU 2019上宣布“服务网格接口” ，以帮助解决此问题。全面披露：我为Solo.io工作，Solo.io是SMI的联合创始人之一，也是统一服务网格的最初愿景的领导者。

尽管还处于初期，但SMI规范打算统一在Kubernetes上运行的服务网格的功能和API（尽管这也可以为在k8s之外运行的服务网格奠定基础）。

这样做对服务网格社区有几个直接的好处：

服务网格的实现可能很复杂；着重于能够实现与实现无关的关键功能的API，可以提高整体的可理解性
在服务网格社区的动荡世界中，关注功能并通过标准接口采用它们可以减少对任何特定实现的依赖；刚入门时，这对最终用户来说是一个强大的位置。
服务网格提供了一组强大的旋钮和杠杆，用于操纵和定义规则（对网络进行编程）；需要一些东西来协调这些旋钮和杠杆；无论是供应商提供的扩展，还是您自己编写的扩展-将网络编程为任何一种特定的实现，其假设都将您与该实现联系在一起，并可能使实现复杂化
为较低层（如服务网格）的稳定性奠定基础，这为进一步创新打开了大门，其中整个生态系统都将获得胜利

最低共同分母

社区中有些人对此种方法的可行性存有疑问，恕我直言，他们的声音非常重要。例如，我非常敬重的蒂姆·霍金（Tim Hockin）提到了SMI方法成为“最低公分母”并可能取悦任何人的可能性。

服务网格功能仍然可以肯定地出现（如在当前服务网格实现的不同功能集中所看到的），但是Istio，LinkerD，Consul，App Mesh和其他功能似乎在以下方面收敛：

流量请求路由（加权路由，L7请求级别匹配等）可以启用诸如金丝雀释放之类的功能。这样做的目的是减小爆炸冲击半径对变化的影响。
- 请参阅Istio，目前是App Mesh；
顶级度量标准收集，例如等待时间百分位数，吞吐量，错误率
- 请参见Istio，App Mesh，Linkerd；
以服务身份为基础的策略实施
- 请参阅Istio，领事，Linkerd和App Mesh，以在不久的将来添加它

语义并没有那么大的不同

目前，Istio具有针对这些功能的成熟和开发的实现，但是还有其他几种实现也实现了这些功能并且正在不断完善。实际上，这些实现的方向非常相似，但在易用性，用户体验，管理，集成等方面存在关键差异。但是关键是，“服务网格提供了什么功能”的语义并没有什么不同。借助社区，包括Istio，linkerd，consul，App Mesh社区（包括对自己的成功感兴趣的所有供应商）中的社区，可以恕我直言围绕这些不太分散的功能的API。

特使代理正在普及

该服务网格讨论的另一个非常重要的部分是围绕通用数据平面代理的清晰融合（大部分是？）。 Envoy代理是4种出色的服务网格实现中的3种的核心代理，其他服务网格提供商也希望在Envoy的基础上进行构建。同样，我发现每个实现的控制平面可能在某些方面有所不同，但是根据网络API的基础功能集将从Envoy派生而来，跨具有相同数据平面的服务网格的通用抽象并不是那么远拿来。正如Tim所指出的，真正的麻烦在于实现的多样性。在这种情况下，它们并没有太大的分歧。关于控制平面本身，我们将看到它们在实现上也没有太大差异。

基于现有的实现

最后，SMI部分源自现有的服务网格实现。这不是梦implemented以求的，由财团主导的，由尚未实施，运营甚至未使用服务网格的人们领导的努力。相反，目前，社区是由具有实际，在生产中部署的服务网格实现的供应商和组织贡献的。从这些经验中获得实用的API的能力并非遥不可及。

SMI由供应商领导

我尊敬的社区中另一个杰出的声音是Zack Butcher，他表达了他的观点，即SMI不通过气味测试，因为它是由想要销售某种东西的供应商领导的。他特别说

“他们的动机是什么，他们是否愿意给我，用户一个更有用的网格？”

SMI Spec的创始人之一Brendan Burns 有一个有趣的观点：

“目前服务网格中必须将自己锁定在实现中的最新技术很糟糕。此外，没有人可以为所有服务网格构建共享工具，这更糟。而且没有人可以构建包括服务网格API的Helm图表，而无需选择展示。”

在我工作的Solo.io，我们有兴趣看到一个单一的服务网格接口，因为我们不断与需要解决的客户见面：

不确定选择哪个网格
想要建立在网格之上，但想要在动荡的环境中对冲他们的赌注
希望获得更友好的用户体验来管理其服务网格
需要将他们的南北交通与东西方网格决策整合起来
希望供应商帮助他们，但是…
不知道任何一个网格供应商的动机

我们的客户和潜在客户欢迎有机会对“服务网格接口”进行融合以帮助他们应对这些挑战的机会。

此外，企业在与供应商相互竞争以满足他们的最终需求中发现了很多价值（并从中发现了很多价值！）过去，我们已经在Java和Java EE等社区中看到了这种竞争（我的背景—我敢肯定还有其他例子）。标准API为企业提供了进行这些讨论的杠杆，并且其中有很多价值（只需要求一些专有供应商与竞争性开源供应商抗衡）。

赢家通吃

关于SMI的最后一个探索领域是这种想法，就像容器编排大战一样，最终将宣布单个供应商或单个网格实现。如果是这种情况，并且您希望今天使用服务网格实现，那么像SMI之类的东西就显得尤为重要，因为您不想被选择错误的东西所困扰。

我认为现实是，我们将最终实现多个服务网格实现（无论是否设计），并且需要以某种方式（无论是在功能级别还是在集成级别）统一它们与他们，或管理他们的水平或以上所有）。

例如，我们与客户和潜在客户一起看到的一个真实用例是对Istio的当前投资，用于他们在本地的部署，但其他团队则去了AWS，并全力以赴，包括使用AWS App Mesh。他们的实际情况是需要在这些网格之上构建工具，并且他们正在构建自己的抽象。如果存在社区主导的抽象，那么他们将使用并看到这样做的很多价值（至少不必自己做！）。