预测未来一两年内七层代理的发展趋势

预测未来最安全的做法是不要给预言加个限期。只要不停鼓吹“会有一个光明的明天”，“明日复明日，明日何其多”，到底哪一天才是光明的明天，那就要等那一天到来之际的事后诸葛亮了。所谓说，“不走的钟一天也会准两次”，为了表明我不是撞大运的不走钟，我决定给这篇文章中的预言加个限期 - 就聊未来一两年内的趋势。

一个事物发展的趋势，既受内部局内人主观的自我奋斗的推进，也受外部大环境客观的时势变化的影响。笔者就按内外两条线，聊聊自己的一些预测。

内部

Gateway API 继续推进

Gateway API 离落地还有不少的距离。比如：

1. 对于后端代理不可或缺的 Retry 功能，Gateway API 1.0 里并没有明确规定一套统一的处理方式。
2. 一些重要的实现，如 Istio，依然把 Gateway API 的支持放到 feature gate 的 experiment 范畴里面。而且现行能用 VirtualService 表达的能力，并不能完全使用 HTTPRoute + xPolicy 来代替。既然连现有需求的平替都做不到，那么迁移到 Gateway API 自然还不能提上日程。

但总体而言 Gateway API 还是一直在前进着的。不像天国中的 Service Mesh Interface，Gateway API 得到无论是 Mesh 还是网关的几大巨头的支持。这种众望所归的项目，可能发展得没那么快，终究是死不了的。所以对于 Gateway API，我依然鼓励持续持有。毕竟比起现存的实现，Gateway API 没有多少历史包袱，要清晰的多。在承受眼前的苟且的同时，想想远方的诗和田野，也便有了更多盼头。

如果用《跨越鸿沟》里的术语，在我看来，Gateway API 1.0 还处于创新者的阶段。开发者热烈地讨论并实现它，但是除非场景简单，否则（在不加一堆实现自己的或用户自己的 CRD 的前提下）没法落地。Gateway API 1.0 之后才开始处于早期采用者阶段，开发者正在严肃地讨论将现有功能都移植到 Gateway API，以促使它能够在更多的场景下能够落地。那么未来一两年内，Gateway API 是否能跨越鸿沟呢？这个就拭目以待了。

Mesh 的 node 化

抛开许多闭源实现不讲，最早在开源里落地 mesh 的 node 化的知名项目，应该是 Cillium 了。当时 Linkerd 还煞有介事地写了篇文章，陈述通过 sidecar 实现 mesh 才是唯一真理，特别强调了 node 化的爆炸半径问题。不料没过多久，mesh 界的 No.1 项目 Istio 就皈依了 node 化阵营，推出了 ambient mesh。Ambient mesh 在历经一年多的迭代后越发深入，从和 CNI 暧昧不清到走 in pod 路线，总之就是持续迭代，推陈出新。爆炸半径倒是没有什么人提了。

技术选型基本上都是 trade off。在现阶段，mesh 落地的最大挑战在于资源占用，除非有强烈诉求，比如金融行业里搞 mTLS、零信任，否则难以说服老板花更多的资源在 mesh 上。这时候，能够降本的技术方向就很重要了。而且 mesh node 化之后，mesh 团队可以把它做得更下沉，部署更新时不需要和用户强绑定，也减少了落地的阻力。在 mesh 的现阶段，一切都是怎么方便落地怎么来。毕竟如果连上 mesh 都上不了，谈爆炸半径那就是空谈。

七层大融合

如果你看到周围许多人装备了锤子，那么钉子就会热销。随着各大网关创业公司纷纷推出自己的南北网关和东西 mesh，“东西南北七层大融合”就是这么一个钉子。Kong 有 Kong 和 Kuma，Tetrate 投身于 Envoy Gateway 和 Istio，solo.io 则是 Gloo 和 Istio。很难想象，他们不会去挖掘东西南北打通的需求。一个现实的例子是 Gateway API 的 GAMMA 规范，便是用同一套模型来表达南北向和东西向的流量管理。国内的云厂商喜欢宣传自己的 API 网关是“三合一”的（本质上是描述一个功能更丰富的网关），受限于部门墙，可能不会去踩隔壁团队的地盘。但在 mesh 团队看来，mesh 的场景里天生就需要有一个 Ingress，如果能把这个 Ingress 做厚，那么实际上也就是在做南北网关的事情。所以我猜测一旦部门墙出现松动，mesh 团队会很乐意去扩大自己的边界，吃掉一部分原本南北层的业务。

外部

大模型推动流式应用

任何预言未来一两年内的尝试都不可能忽略 AI （准确来说，大模型）。许多人认为，未来大模型应用将会成为主流。所以哪个七层代理能更好地服务大模型应用，就能拿下这个巨大的增量市场。网络就像管道一样，它的性质很大程度来由所承载的“货物”决定。大模型应用有个特点，就是他们都是使用流式协议来通讯。大模型应用的需求，比如输入输出的安全过滤、基于 token 数的限流等，都有一个共同的特点，就是基于流式的请求体、响应体来做处理。这就要求运行在期间的七层代理能够很好处理诸如 SSE、websocket、GRPC 等流式协议。

按照对流式协议的支持，我们可以这么给七层代理分类：

1. 不支持流式
2. 不完全支持流式
3. 完全支持流式

不支持流式的代理在大模式时代里只能瞪眼干着急，基本已经出局。

市面上的网关，大部分是属于“不完全支持流式”的。其中的“不完全”体现在对 body 的处理上。许多网关之前在设计和 body 交互的接口时，只支持对 body 的独占或全缓冲的操作。比如基于 OpenResty 的许多网关，除非用 raw socket 实现对请求的直接读，否则获取请求体时只能一次获取全部请求。而且即使有办法直接流式读请求，在改写请求时（set body）也不能流式地修改，只能一次性设置一个大 body。我这么说并不是专门针对基于 OpenResty 的网关，其实基于 Go 的许多网关，在实现访问 Body 的接口时也是这么做的。一个插件往往会直接读完 body，然后再将读到的内容包装成一个 []byte，留给下一个访问 body 的插件。在这种设计下，其实还是要求这个请求不能是流式的，不然后续流程走不通。如果在流式处理上不能补齐短板，势必因自身能力的有限导致在市场竞争下落伍。

FaaS 下对网关更新效能的要求提升

当然，除了大模型，还有一个（不久前还是）炙手可热的新趋势，那就是 FaaS 的兴起。主打按需消费的 FaaS “货物”，要求对接的代理具有更好的动态性。这里的动态性体现在三个方面：

1. 更快地接入新的 FaaS 实例
2. 更好地透出各项监控指标
3. 更省地进行数据面的弹性伸缩

我们前面聊过一下 mesh 的 node 化趋势。如果 FaaS 实例想要接入 mesh，在 sidecar mesh 时每个 FaaS 实例都需要启动一个对应的 container（这里假设实例是一个 pod，而不是一个 Wasm VM 之类的东西），无形中相当于把负载翻倍，对朝生暮死的实例来说代价很大。但在 node 架构下，接入另外的一个实例，会轻量得多，也许几个 syscall 就能把事情都办完了。

扯远了，让我们回到正题上来。许多网关在宣传自己的指标时，往往不会细说自己的动态性，要么一点不提，要么简单说个秒级生效了事。但在实际使用中，变更的生效时间、大规模场景下对数据面指标的采集和上报，以及网关自己的弹性能力，都是重要的特性。在 FaaS 场景下，上述的几项能力都会经历严肃的考验。我相信随着未来一两年内，越来越多的应用开发开始以 FaaS 的模型重构自己的部署形态，对网关动态性的要求将会逐渐提升，甚至会迫使网关厂家像现在使用各种图表来宣传自己的单实例 QPS 一样，使用各种数据来强调自己更好的动态性。