在运行一个服务式架构的应用时,往往会面临服务间通信的挑战,服务网格技术正是为此而生。Kubernetes 和容器技术对工作负载的在大量服务器上的部署和进行提供了一个漂亮的抽象,服务网格做的也是类似的工作:他对网络进行抽象,让运维和开发人员能够通过请求路由、可观察性以及策略实施等方式对其进行控制。服务网格带来了各种可能。
唯一的问题是,就算 Kubernetes 提供了有力的 API 来对底层基础设施进行抽象,从而进行工作负载的调度,可惜的是这其中没有一点能够落地的 API 能够提供服务网格所需要的能力。
KubeCon EU 2019 上发布的服务网格接口(SMI)正试图填补这一空白。在此声明:我为 Solo.io 工作,它是 SMI 的创建者之一,并是一个原有统一服务网格产品的主导者。
SMI 规范还很稚嫩,目前正在尝试对运行在 Kubernetes 基础之上的服务网格所需的 API 和能力进行统一(这种尝试也有助于为 Kubernetes 之外运行的统一服务网格奠定一个基础)。
这一举措对服务网格社区来说,带来不少直接利益:
社区里有些家伙对这类方法的可行性表示怀疑,反对的声音至关重要。例如我非常尊重的 Tim Hockin,他提到 SMI 方法有可能成为一种最小公分母,对谁都没好处。
服务网格的能力范围还在扩张之中(目前不同的服务网格实现会有不同的特性),但是 Istio、Linkerd、Consul、App Mesh 等产品在某种程度上还是殊途同归的:
目前 Istio 的各种特性最为成熟,但是有很多其他的实现也正在跟进。事实上各种实现都很相似,关键的差异是易用性、用户体验、管理能力、集成能力等。而关键的问题:“服务网格应该有什么功能?”,各家的答案差别不大。如果 Istio、Linkerd、Consul、App Mesh 以及其它有兴趣在这一方向发展的厂商和社区能够提供支持,把这些差别不大的功能,做成一套 API 并不会难于登天。
服务网格的讨论中,还有一个很重要的情况就是通用数据平面的同化趋势。4 个著名的服务网格产品中,有 3 个使用的是 Envoy,并且还有其他服务网格供应商看起来也准备在 Envoy 的基础之上构建产品。我发现每个实现的控制面可能有些不同,但是内部的网络 API 都是继承自 Envoy,在同一个数据平面之下,一个跨服务网格的通用抽象也不算是不可思议。正如 Tim 所说,最大的麻烦来自于实现上的分歧。在这种情况下,其实这些产品并非天差地别。即使是控制平面本身,其实现也没有那么大的区别。
最后,SMI 来自于现存的服务网格产品。它不是凭空想象,也没有财团驱动,更不是由没有经验的团队造出的空中楼阁。恰恰相反,这一社区目前的贡献来自于真实存在的、在生产环境中部署的服务网格实现。从各个发起者的经验来说,做出一套脚踏实地的 API 并不会耸人听闻。
另外来自 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 来构建系统;如若不然(我认为这更有可能),我们最好一同努力,摒弃实现差异,努力找出服务网格应该提供的重要功能。