共计 2024 个字符，预计需要花费 6 分钟才能阅读完成。
另眼旁观 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》。
文章对立公布在公众号
云原生指北
