另眼旁观 Linkerd 2.12 的发布：服务网格标准的曙光？

另眼旁观 Linkerd 2.12 的发布：服务网格标准的曙光？

8 月 24 日，发明服务网格的公司 Buoyant 发布了 Linkerd 2.12，这是时隔近一年的版本发布。不知道大家的对新版本期待如何，在我来看新版本中的功能对于一年的时间来说确实不算多，但是我想说的是 Linkerd 还是那个 Linkerd，还是秉持着一贯的 “Keep it simple” 的设计理念。

新版本的内容不一一介绍，其中最主要的功能：per-route 策略，相比上个版本基于端口的策略，扩展到了 per-route。

而我想说的特别之处也就是在 per-route 和策略上。

per-route 和策略有何特别之处？

在《SMI 与 Gateway API 的 GAMMA 倡议意味着什么？》 层有过猜想：未来服务网格的标准有可能全部或者部分以 Kubernetes 原生 API 的方式存在。

“网关 API，之于集群是入口/出口网关，之于 Pod 是 inbound/outbound sidecar。”

现在来看，Linkerd 先迈出了这一步。

per-route

路由（routing）是通过网络将流量从源地址传输到目的地的操作。不同的流量有不同的操作（路由），流量路由的前提是流量的识别，通俗来讲就是请求的匹配。对服务网格中常见的 TCP 流量，有源地址、源端口、目的地址、目的端口等标识；对于 HTTP 流量，标识则更多：路径、报头、参数等等。

Linkerd 通过一个 CRD ServiceProfile 提供了 per-route 的 指标、重试和超时设置，该 CRD 中可以配置匹配规则来进行流量的识别。在新的 per-route 策略中，则又引入了新的流量识别机制 HTTPRoute 。这个 HTTPRoute 实际上是来自 Kubernetes Gateway API，以镜像的方式维护在 policy.linkerd.io/v1alpha1 包中。

至于为何要自己维护 HTTPRoute，在 Buoyant 的另一篇博客《Linkerd and the Gateway API》 中也给出了答案：目前的 Gateway API 虽易展现出成为标准的设计，但还不足以满足目前的需求。

为何无法满足目前的需求，让我们继续来看策略。

策略

2.12 带来的 per-route 策略是授权策略（Authorization Policy），通过 AuthorizationPolicy 及其他几个 CRD 来进行配置，与 HTTPRoute 一起维护在 policy.linkerd.io/v1alpha1 包中。从包名来看，policy.linkerd.io/v1alpha1 是考虑到了 Kubernetes Gateway API Policy Attachment的设计。

图片来自 Kubernetes Gateway API 文档

在服务网格的功能中有很多的策略：路由、认证/授权、超时、重试、熔断、限流、故障注入等等。而目前 Policy Attachment 还只是提供了概念设计，对这些策略没有任何具体的定义。因此 Linkerd 将其维护在 policy.linkerd.io/v1alpha1 包中，并乐观地相信有一天其可以被 Kubernetes 原生的 CRD 替代，且切换的成本微不足道。

在此我也猜想，原本 ServiceProfile 中的策略也会被废弃，并转移到新的包中。因为 ServiceProfile 的设计本就不够优雅，将流量的标识与策略耦合（估计这也是 Linkerd 的 Keep it simple 执念，尽量少定义 CRD）。

无独有偶

架构设计总是伴随着取舍，在结构化和可扩展性间进行着平衡。Linkerd 秉持 Keep it simple 的设计理念，尽量避免定义过多的 CRD，降低复杂度。不只是这次的 HTTPRoute，其流量拆分上使用了Service Mesh Interface（SMI）的 TrafficSplit API（Linkerd 支持 v1alpha2，最新为 v1alpha4）。

简化设计，降低学习和维护的成本；降低资源需求，降低使用成本；提供最小功能集，“够用就好”，减少冗余功能带来的成本提升。

服务网格面世 5 年来，用户逐渐意识到“轻、快、易用”对于服务网格的重要性。这条路上 Linkerd 并不是孤独的，国产的服务网格产品 Flomesh 开源的 osm-edge 也是同样的简化设计，轻量级高性能的 sidecar 代理，此外还有着：

• 开放的控制平面设计，通过扩展支持更多的服务发现。
• 可编程的sidecar 代理 Pipy，功能扩展更容易；除了作为服务网格代理，还可以独立使用。
• 基于 SMI 的实现。SMI 与 Gateway API 都是同样的流量标识与策略分离的设计，简单的对比可以看这篇。

总结

这篇文章是 Linkerd 2.12 发表之际的一些启发和感想，版本发布只是表面，更要探寻表面之外的深意。利用周末的时间来挖掘一下，写下这篇。

写作的同时，有一个词浮出脑海：返璞归真。下一篇，目前只想到了标题《服务网格：少即是多，Less is more》。

文章统一发布在公众号云原生指北