Smi：推动服务网格社区举步前行
原文：Moving the Service-mesh Community Forward
在运行一个服务式架构的应用时，往往会面临服务间通信的挑战，服务网格技术正是为此而生。Kubernetes 和容器技术对工作负载的在大量服务器上的部署和进行提供了一个漂亮的抽象，服务网格做的也是类似的工作：他对网络进行抽象，让运维和开发人员能够通过请求路由、可观察性以及策略实施等方式对其进行控制。服务网格带来了各种可能。
唯一的问题是，就算 Kubernetes 提供了有力的 API 来对底层基础设施进行抽象，从而进行工作负载的调度，可惜的是这其中没有一点能够落地的 API 能够提供服务网格所需要的能力。
KubeCon EU 2019 上发布的服务网格接口（SMI）正试图填补这一空白。在此声明：我为 Solo.io 工作，它是 SMI 的创建者之一，并是一个原有统一服务网格产品的主导者。
SMI 规范还很稚嫩，目前正在尝试对运行在 Kubernetes 基础之上的服务网格所需的 API 和能力进行统一（这种尝试也有助于为 Kubernetes 之外运行的统一服务网格奠定一个基础）。
这一举措对服务网格社区来说，带来不少直接利益：
服务网格的实现可能很复杂；将独立于实现的 API 暴露出来，让系统整体更易理解。
这一社区充满变化，专注于能力，并通过标准接口来使用服务网格，降低了对特定实现的依赖；对最终用户来说，这是一个很好的启动方式。
服务网格提供了一组强大的功能用来定义和处理规则（对网络进行编程）；需要有些东西来对这些能力进行编排。不管是厂商提供还是自行实现，将网络编程为特定的实现，这会将你绑定到这一实现，某种程度上也让你的实现变得更加复杂。
在底层（像服务网格这样）为稳定性奠定基础，给未来的创新打开了新的可能，也给整个生态带来了新的机会。
最小公分母
社区里有些家伙对这类方法的可行性表示怀疑，反对的声音至关重要。例如我非常尊重的 Tim Hockin，他提到 SMI 方法有可能成为一种最小公分母，对谁都没好处。
服务网格的能力范围还在扩张之中（目前不同的服务网格实现会有不同的特性），但是 Istio、Linkerd、Consul、App Mesh 等产品在某种程度上还是殊途同归的：
流量路由功能（路由权重、在七层上提供请求级匹配等）满足了金丝雀发布等功能需求。这项能力的诉求是减小变更的影响范围
- 目前版本的 Istio 和 App Mesh 都已经提供这一功能，Consule 和 Consul 也会很快跟进。
顶端指标收集，例如延迟分布、吞吐量、出错率等
- Istio、App Mesh 和 Linkerd 都提供这一能力，Consul 会在近期提供易于配置的（指标收集）功能。
基于服务身份的策略功能
- Istio 和 Consol 已有这部分功能，Linkerd 和 App Mesh 会在近期加入。
语义差别不大
目前 Istio 的各种特性最为成熟，但是有很多其他的实现也正在跟进。事实上各种实现都很相似，关键的差异是易用性、用户体验、管理能力、集成能力等。而关键的问题：“服务网格应该有什么功能？”，各家的答案差别不大。如果 Istio、Linkerd、Consul、App Mesh 以及其它有兴趣在这一方向发展的厂商和社区能够提供支持，把这些差别不大的功能，做成一套 API 并不会难于登天。
无处不在的 Envoy proxy
服务网格的讨论中，还有一个很重要的情况就是通用数据平面的同化趋势。4 个著名的服务网格产品中，有 3 个使用的是 Envoy，并且还有其他服务网格供应商看起来也准备在 Envoy 的基础之上构建产品。我发现每个实现的控制面可能有些不同，但是内部的网络 API 都是继承自 Envoy，在同一个数据平面之下，一个跨服务网格的通用抽象也不算是不可思议。正如 Tim 所说，最大的麻烦来自于实现上的分歧。在这种情况下，其实这些产品并非天差地别。即使是控制平面本身，其实现也没有那么大的区别。
基于已有实现
最后，SMI 来自于现存的服务网格产品。它不是凭空想象，也没有财团驱动，更不是由没有经验的团队造出的空中楼阁。恰恰相反，这一社区目前的贡献来自于真实存在的、在生产环境中部署的服务网格实现。从各个发起者的经验来说，做出一套脚踏实地的 API 并不会耸人听闻。
厂商主导的 SMI
另外来自 Zack Butcher 的意见也很醒目：SMI 由卖东西的厂商领导，调性不好。他特别提出：
他们的动机是什么？是给我——一个用户，一个更可用的服务网格？
SMI 规范的发起者之一，Brendan Burns 有个有趣的回应：
从目前服务网格的情况看来，把自己锁定在单一实现上是不好的。更进一步，没有人能够为所有服务网格构建共享工具。除非选择一个实现，否则没有人能构建一个包含服务网格 API 的 Helm Chart。
我所在的 Solo.io，我们乐于看到单一的服务网格界面的出现，这是因为我们始终尝试为客户解决：
不确定选择哪个网格
想要在网格之上构建产品，但是希望在这一动荡的领域中保护投入
希望服务网格的管理能有更好的用户体验
希望将南北流量和东西向的网格进行集成
希望得到厂商的帮助，但是...
无法确信任何网格厂商的动机
我们的客户和潜在和客户对于 SMI 的聚合是持肯定态度的，这一新生事物能够帮助他们应对上述这些问题。
另外企业们发现，在满足其最终需求的情况下，存在竞争的多个公益炕上是很有价值的。正如我熟悉的 Java 和 Java EE 一样。标准化的 API 让企业能够参与并在这些讨论中获益。
胜者为王
关于 SMI，最后一个要探讨的想法是：类似容器编排战争的结果，单一厂商或者单一网格产品会成为唯一的赢家。如果预期是这种结局，又希望现在就用上服务网格，SMI 就成为一种有效的防御措施，防止踏入错误阵营无法回头。
在我看来，真实情况是我们会面对多网格产品并存的情况，我们需要以某种方式进行统一（能力层次、集成方式或者管理方式，或者几个方法的结合）。
例如我们的客户中的真实用例，他们在自有部署中使用 Istio 提供开发支持，但是其他团队使用的是 AWS，也使用了 AWS 的 App Mesh。他们有切实的需求，想要在这些网格的基础之上进行抽象并构建工具。如果出现了一个社区领导的抽象，他们就会使用并从中获得价值（至少是不用自己做了）。
推动服务网格社区举步前行
目前来说，社区中的健康争论是必要的，以此可以发现问题、机遇和目标，从而帮助我们进一步的探索，为最终用户和平台构建者提供服务网格的强大功能。服务网格展现了有力的应用网络能力，但今时今日，终点还遥遥无期。
类比容器和编排系统，Kubernetes 让容器变无聊了，服务网格最终也会让应用网络变得无聊。服务网格在加高堆栈的同时，会给用户、社区以及相关厂商带来价值。如果服务网格生态系统进入了寡头局面，这也很棒，我们会面向单一 API 来构建系统；如若不然（我认为这更有可能），我们最好一同努力，摒弃实现差异，努力找出服务网格应该提供的重要功能。