豆浆大叔

1. 大模型太吃资源了，各种计算、memory、带宽 bound，导致引擎并发能力很弱，对负载均衡依赖很高

2. 往后看，AIGW 要做的，不仅是要均衡，而是要承担时延 SLO

确实好久没写了，这一年都在 “卷” AI 网关，内部落地，业界演进，节奏都非常快，忙也是现实

今儿开个头，开启一个新阶段，后面保持节奏继续走起

负载均衡

今儿从负载均衡开始聊起，在通算时代，对于网关来说，这是经典的基础能力

Round-robin，权重轮询，最小连接数，一致性哈希，也可谓是脍炙人口

但是，在智算时代，负载均衡是 AI 网关的核心价值，已经逐步在成为行业共识了

为什么呢，小小负载均衡，有这么重要（难搞）么？

推理的计算特征

这要从大模型推理的计算特征说起了

（大模型推理的计算过程，要讲清楚了，也不容易，咱们这里只聊跟负载均衡有关系的）

计算量大

大模型推理请求的计算量都很大，相比通算的业务请求，多了好几个数量级

以 deepseek v3 为例，一个 4k token 输入的请求，纯 prefill 阶段，就需要 8 卡的 H20 计算几百毫秒

单点并发小

对于通算应用，单点几千几万的并发也很常见

而在推理场景下，单点的并发能力就弱很多了，prefill 阶段可以认为没并发（开启 dp 也算有点），decode 阶段一般也就是几十上百

波动很大

推理请求的计算量，随着输入输出长度变化，差异也非常大，不同请求的计算量，相差个几十上百倍，也很常见

尤其是输出长度，由于自回归特性，都不好提前感知

prefix 语义 KVCache

大模型的计算结果也可以缓存（KVCache），对于提升性能也很重要，但是，缓存复用需要遵守 prefix 语义

通算场景下的缓存，通常是基于某个 key 来做哈希的规则，相对来而，推理这个要复杂多了

难在哪

简单说，在推理场景，因为推理引擎抗并发小（各种 计算、memory bound），更需要负载均衡，但是，也更难做好负载均衡

那么，难在哪里呢

在通算场景下，服务的负载通常和请求数，或者并发数正相关，只需要做到请求/并发数均衡基本就够了

但是，由于上述推理的计算特征，推理服务的负载，跟请求数并不是正相关

于是，有了这三个关键的具体问题：

1. 哪些指标可以反映负载
2. 如何获取到，时效性如何
3. 什么样的负载算法来决策

具体怎么解，就留到下篇了

最后

关于推理的计算特征，看 Mooncake 论文里的这个图，可以有一些直观的体感

2024 的年度总结，比以往时候来得更晚一些，倒也不是变懒了，只是确实太“卷”了 …

今年最后几个月，公众号也断更了，也是确实没空写字了 …

趁着年关，还是先停下来，写点文字，记点流水账 …

一入 AI 深似海，从此周末是路人

今年最大的感悟是，AI 大模型太 “卷” 了

前年过年，GPT 3.5 是热议话题，去年过年被 Sora 震惊，今年过年 DeepSeek 都火到了美国

下半年有幸参与了 AI 推理业务，也是切身体会到其中的 “卷”

有一次，同事顺嘴问了一句，最近周末去哪里玩，我才意识到，好像都没有周末了 …

之前听一些分享，说国外的 AI 厂商也很卷，很多都是自愿加班开卷，完全不是以往 work-life balance 的形势

参与其中之后才深刻体会，AI 大模型就是一阵旋风，只要进来，就会自然卷了 …

记得阿里有个提法，叫 “饱和式投入 AI”，所谓饱和式，那就是多头下注，不允许错过

不只是对外多方投资，对内也是鼓励不同方向的尝试，有点重复建设也不是啥问题

如此行业级的重兵投入，不卷成麻花，那才怪了 …

自然卷

之所以会自然 “卷”，主要还是发展太快了，新东西太多了，完全学不过来

以往学习，还可以找经典的教材，而现在的学习，必须得看新材料，读论文，层出不穷的论文

因为要想参与其中，干点事情，首先就得跟上发展趋势

大约年中的时候，跟合作方聊起推理引擎的调度算法（半年前调研的材料），说网关上可以搞点事情

结果，对方说，那个都是去年的了，现在都不这么玩了…

对于网络这种 infra 的角色，需要面对多方的快速发展，对下得跟上各种硬件的发展，对上还得了解大模型，各种算法的发展

只会让人觉得脑容量不够，时间不够

单纯的求知欲，就足够驱使人停不下来了，更何况还有外部高强度的竞争

还卷得动

那么，还卷得动么？嗯，至少目前还是卷得动

那么，面对全新的领域，饱和式投入，以往十年的工作经验，还有用么？

有用，但是不多 …

对于传统的 CPU 计算应用，已经沉淀了一套成熟的微服务架构体系，每个服务的逻辑都不是那么复杂，计算量也相对较小，单个 CPU core，就足够支持不低的并发了

到了 AI 大模型，因为庞大的计算量，天然就需要并行计算，几十 B 模型的推理，就需要多卡并行计算了，更别提几千上万卡的大规模训练集群了

而并行计算，也带来了一次通信的升级，从机内的 NVLink，HCCS，到机间的 InfiniBand，RoCE 都是大模型业务带来的腾飞

虽然很多也还不懂，但是，今年卷了几个月，也算有些眉目，自我感觉还不错，至少还卷得动

更何况，这一波是划时代的升级，把时间拉长，暂时的不懂，影响也不那么大，拥抱变化，迎头赶上，赶上这波浪潮才是关键

流水账

好吧，可能确实有点卷过头了，脑子里就剩下大模型了

还是稍微回顾下，今年都干了啥

上半场

今年跟去年有一点很类似，就是上下半场风格完全不同

去年年终总结的时候，还想的是安心搞好网关，等着推理业务起来，迎来一波行业大发展，带动一波网关业务的红利

所以，上半年，主要还是在搞老本行，云原生网关

只是，更多在内部落地，需要有节奏的推进把控，也不轻松，开源搞得也相对少了

AI gateway

印象中 2023 年，蚂蚁就提了 AI First 战略，也知道公司有在训练大模型，但是感觉离得很远

到了 23 年底，原来的网关玩家，都开卷 AI gateway，做推理 API 的统一入口

虽然 API gateway 的底色很浓重，但是也确实有些推理 API 的亮点

今年初，也想在公司里搞个 AI gateway 的业务场景玩玩，只是问了一圈，也没有找到落地点

先训练再推理

不只是蚂蚁，很多国内大厂，都想卷自己的大模型，而不甘心用别人的大模型，来搞新应用

所以在资源投入上，更多在买卡先搞训练，先让自己的模型跻身业界一线，保持模型不掉队

而 AI gateway 是用在推理，搞新应用的场景 …

开卷 AI Gateway

到了下半年，又有了一些新的变化，推理被更多的提起，很幸运我们找到了合作方，可以开卷 AI gateway 了

作为专业的 Gateway 团队，我们首先卷的是性能

按照传统的网关分类划分，AI Gateway 应该属于业务网关，这类网关一般被认定为业务量不大，性能要求不高的

但是，在推理将成为大趋势的共识下，卷性能也很有意义了

好在基于过去几年的技术积累，我们的 MoE 架构，使用 Golang 来开发扩展，很快就支持了 AI Gateway 的落地

性能也比原来的 Java 实现了 10x 提升，之前折腾的 cgo 优化，也派上了用场

大模型推理

搞 AI Gateway，除了卷性能，也更多的了解了大模型推理的业务

Gateway 再卷也属于原来的舒适区，背后的推理业务，才是全新的挑战

AI Gateway 下一站

当前推理成本过高，是行业级的问题

每一层都在解决这个问题，NVIDIA 在造性价比更高的硬件，模型层也在优化，比如 MiniMax-01 的线性 Attention，还有推理引擎运行时，各种算法、架构的优化

那么，AI Gateway 作为推理流量入口，最适合的是，做全局最优调度，提升整理资源效率

推理过程微服务化

另外，大模型推理的自回归特性，也存在明显的 Prefill 和 Decode 两个阶段，对应不同的计算模式

年中，kimi 的 PD 分离架构 + 全局 KVCache 调度，将推理服务拆分推到了一个新的高度，有点类似通算业务的微服务拆分了

而对应的，中间的 KVCache 传输，就需要高速的网络传输方案，也有点类似于通算场景的 RPC 框架

最后

10 月的时候，听了老黄在印度的演讲

有一点触动很大，过去几十年，围绕 CPU 的编程生态，一直在享受摩尔定律的红利，现在摩尔定律失效了，是时候开始新的编程模式，CUDA 编程了

最后，祝大家新年快乐，在新的浪潮下都有自己的 aha moment ～

本地限流因为使用简单，执行高效，可以算是最常用的了

在 Envoy 里，local rate limit 可以用于不同的 Envoy Filter 扩展阶段，从而实现不同行为的限流：

1. HTTP Filter，限制 HTTP 请求频率
2. Network Filter，限制 TCP 建连频率
3. Listener Filter，限制TLS 握手频率

配置用法

以常用的 HTTP localrate 为例来感受一下配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

http_filters:
- name: envoy.filters.http.local_ratelimit
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
    stat_prefix: http_local_rate_limiter
    token_bucket:
      max_tokens: 1000
      tokens_per_fill: 1000
      fill_interval: 2s
    status: 429
    response_headers_to_add:
    - append_action: OVERWRITE_IF_EXISTS_OR_ADD
      header:
        key: x-local-rate-limit
        value: 'true'

Envoy local ratelimit 采用令牌桶算法，限流的核心配置是这三个：

1. max_tokens 桶的最大 token 容量，也是初始的默认值
2. tokens_per_fill 每个周期增加的 token 数量
3. fill_interval 填充 token 的时间周期

那么，上面配置的效果就是：

1. 一个最大容量为 1000 的桶，每 2s 往桶里加 1000 个 token
2. 每来一个请求，消耗桶里一个 token，如果桶里没有 token 了，就会拦截请求

对于拦截请求的响应，还可以配置：

1. 响应状态码，默认是 429
2. 和响应的请求头

细粒度限流

上面的示例是一个粗粒度的策略，针对这个 listener 端口上的所有请求。

如果想实现一个细粒度的，比如域名级，或者接口级的呢？

也是可以做到的，ratelimit 也支持 route 级别的配置：

1
2
3
4
5
6
7
8
9
10
11

routes:
- match: {prefix: "/path/with/rate/limit"}
  route: {cluster: service_protected_by_rate_limit}
  typed_per_filter_config:
    envoy.filters.http.local_ratelimit:
      "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
      stat_prefix: http_local_rate_limiter
      token_bucket:
        max_tokens: 10000
        tokens_per_fill: 1000
        fill_interval: 1s

如果是同一个路由内，还想实现更细粒度限流呢？

Envoy 还有路由级别的 descriptors，比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

- match: {prefix: "/foo"}
  route:
    cluster: service_protected_by_rate_limit
    rate_limits:
    - actions:  # any actions in here
      - request_headers:
          header_name: x-envoy-downstream-service-cluster
          descriptor_key: client_cluster
  typed_per_filter_config:
    envoy.filters.http.local_ratelimit:
      "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
      stat_prefix: test
      token_bucket:
        max_tokens: 1000
        tokens_per_fill: 1000
        fill_interval: 60s
      descriptors:
      - entries:
        - key: client_cluster
          value: foo
        token_bucket:
          max_tokens: 10
          tokens_per_fill: 10
          fill_interval: 60s

可以根据请求中的特征（上面示例是一个请求 header），实现路由内，不同的限流配置

实现机制

从配置方式理解，Envoy 的实现也不需要很复杂

1. 在配置解析阶段，配置中的每一个 token_bucket，就会生成一个 RateLimitTokenBucket 桶实例

2. 在请求处理阶段，通过 route/descriptors 匹配到 token_bucket 之后，就从对应的桶里取值即可

在 1.31.0 之前，是每个桶都有一个定时器，每 fill_interval 给桶里注入 tokens_per_fill 的令牌

在 1.31.0 里，做了个优化，不再依赖定时器

原因是，定时器运行在 main thread，而 main thread 在 Envoy 里面还有一个重要职责就是加载来自控制面的配置，当配置量很大的时候，可能会长时间的阻塞这些 timer，就影响限流了

与 NGINX 对比

在 NGINX 里，与 Envoy local rate limit 最接近的就是 limit_req 了

首先是限流算法上的区别，Envoy 是令牌桶算法，而 NGINX 是漏桶算法

漏桶算法可以实现流量整形，比如上面示例的 1000/2s 在 NGINX 会被处理为 500/s，也就是每 2ms 放行一个请求，从而让请求更均匀的转发给后端应用

而令牌桶算法的限制值，更接近人类的理解，X 时间放行 Y 个请求

动态限流 key

不过，在我看来，最大的区别还是，NGINX 可以指定动态限流 key，从而实现每个 IP 限制 10/s 这样的效果，而 Envoy 却做不到。

从实现机制上来说，NGINX 是基于 shared memory zone 来实现的，可以灵活的开辟大内存来实现很多 key 的存储，同时，基于 lru 的淘汰算法，也可以保证内存可控

shared memory zone 是 NGINX 内部的一个通用的底层组件，而 Envoy 还没有这类基建

从使用场景上来说，NGINX 主要用于南北向接入网关，防 DDOS/cc 攻击需求强烈，而基于 IP 的限流策略则是最常用的防攻击策略

而 Envoy 多用于东西向场景，流量来源多是可信的，限流策略主要是用于保护后端服务不被打爆，所以对于这种动态 key 的诉求相对没那么强烈

集群限流

Envoy 的 local ratelimit 虽然是本地限流，但是也可以配置为集群级别的限流效果

1.31.0 新增了 local_cluster_rate_limit 的配置，可以让 token 的限流值，按照 Envoy 集群数量来平均分配，并且随着 Envoy 实例数量自动调整

当前，这里有个假设前提是，流量在 Envoy 节点上是均匀的

NGINX 的 shared memory zone 是单机内共享的，不过商业版里，也增加了一个跨机同步的机制，这样也可以实现集群级别的限流

最后

个人观点，简单点评几句：

Envoy 的本地限流，好的是应用场景多，HTTP 请求，TCP 连接，TLS 握手 都可以用

NGINX 呢，优势是动态限流 key，用来防 cc，应对公网不可信的流量，确实很香

嗯，至少目前如此，后面 Envoy 加上动态限流 key，也不是太大的问题

上一篇 HTTP json 转 gRPC 中，我们提到了一起 Golang runtime panic，这篇就稍微展开介绍的

报错

单测的时候，运行倒是正常，跑压测的时候，很快就会出现 Golang runtime panic

比如：

1

runtime: marked free object in span 0x7fef96df8658, elemsize=24 freeindex=83 (bad use of unsafe.Pointer? try -d=checkptr)

这个是 Golang 的 GC 在 sweep 阶段，发现有一个内存块，标记被使用，也就是有一个指针指向这个内存块，但是，这个内存块同时也是被标记 free 的，不应该被使用的

简单说，就是有内存指针指向了 free 内存块，是个非法指针

原因

虽然 panic 的时候，会把所有 goroutine 的调用栈，都全部打印出来

但是，由于 panic 发生在 sweep 阶段，显然已经不是非法指针写入的时候了，调用栈并没有太多分析价值了

不过，好在我们是 demo 演示场景，代码本身比较简单，经过一番折腾，主要是 review 代码，发现坑在 copyHeaderMapToGo 中的这段：

1
2
3
4
5

len = value.length();
go_strs[i].n = len;
go_strs[i].p = go_buf;
memcpy(go_buf, value.data(), len); // NOLINT(safe-memcpy)
go_buf += len;

这里是将 C++ 侧保存的 header map，copy 到 Golang 提前准备好的内存中

其中涉及到两个操作：

1. 为 Golang string 的 p 指针和 n 长度赋值

2. 将字符串内容 copy 到 go_buf 内存块中

问题就出现在第一步，因为 value 有可能为空，那么 go_buf 有可能就已经是非法的了，超出了预定的总长度

刚好，我们压测的这个 grpc 场景，Golang 的 grpc server 总是会返回

1
2

grpc-status: 0
grpc-messages

grpc-message 这个 trailer 的 value 总是为空，所以，压测场景很容易就 panic 了

知道原因，修复方案也简单，当 len 为 0 时，我们直接跳过即可

这是已经合并的 PR: https://github.com/envoyproxy/envoy/pull/35930

骚操作

在 C 里面，修改 Golang 指针的值，是 Golang 不建议的玩法，可以说是实锤的骚操作

不过，我们这么玩也是理论上安全的，只是需要非常小心，玩不好就踩坑了

至于，为什么我们选择这种骚操作，主要还是在保证内存安全的前提下，还提供不错的性能，具体可以看之前的 Envoy Go 扩展之内存安全

最开始实现的时候，只考虑了 Golang string 的使用场景，因为长度为 0，那么指针地址就算是非法，也是会被忽略的

但是，到了 GC 环节，GC 是不看类型的，只看指针引用，所以就悲剧了

彩蛋

顺便在 copyHeaderMapToGo 中还发现了一处优化点：

1

auto value = std::string(header.value().getStringView());

这里的 std::string 是没有必要的，因为反正都要 copy 到 Golang 里面，C++ 侧再 copy 一次是没必要的了

于是，又有了这个 PR，简单场景压测了一把，Golang 的 header 初始化，可以有 10%+ 的提升，~400ns

当然，还有一些 Golang 侧的优化空间，后面有空再继续搞了

尽管 json 解析比较费 CPU，但是，由于 HTTP + json 简单好上手，适配成本低，深受大家喜欢，尤其是对外的场景，HTTP + json 可以说是首选。

但是，有些内部的微服务场景，因为调用方也是可控的内部服务，所以，gRPC 以及类似 RPC 协议，在内部场景被广泛的使用。

把内部的 gRPC/RPC 服务，通过 HTTP + json 暴露给外部用户，加上对应的认证鉴权，限流策略，则是 API 网关的一大应用场景。

演示场景

本文将演示基于 Envoy Golang 扩展，来实现这一协议转换需求：

1. 简单模式，转为普通的 json

2. 服务端推流模式，转为 SSE + json

这里演示的 grpc 服务，直接使用 github 上的开源项目 golang grpc demo

刚好也两个都有：

1
2
3
4
5
6
7
8
9

service Demo {
  // 简单模式。一个请求，一个响应。
  //客户端发送一个请求，包含两个数字，服务端是返回两个数字的和
  rpc Add (TwoNum) returns (Response) {}

  //服务端流模式，客户端发送一个请求，服务端返回多次。
  //请求一次，返回三次，分别是两数子和、两数之积、两数之差
  rpc GetStream (TwoNum) returns (stream Response) {}
}

上代码

因为主要是工程实践，也没有太多原理好介绍，咱们直接看代码就可以

这里是完整的代码仓库：envoy-http-to-grpc-demo

接下来，针对两种场景的代码实现，做个简单的介绍

简单模式

gRPC 与普通的 http 请求区别也不大，从针对请求的处理，我们可以很清晰的看到这些差异

针对 header 的处理，简单两行就可以搞定：

1
2

header.Set("content-type", "application/grpc")
header.Del("content-length")

body 的处理需要多几行，因为 body 有一套 grpc message 的编码方式

不过，核心也就是把 json 转成 pb 编码，期中 demo.TwoNum 就来自 golang grpc demo 中使用 proto 生成的 Golang struct。

然后再套上 grpc message 的 header，因为没有 content-length，每个 grpc message 都有 4 byte 来申明长度

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

jsonBuf := buffer.Bytes()
data := &demo.TwoNum{}
if err := json.Unmarshal(jsonBuf, data); err != nil {
	return f.badRequest(err)
}

grpcHeader := make([]byte, 5, 10)
pbBuf := proto.NewBuffer(grpcHeader)
if err := pbBuf.Marshal(data); err != nil {
	return f.badRequest(err)
}

grpcBuf := pbBuf.Bytes()
size := len(grpcBuf) - 5

setGrpcHeader(grpcBuf, size)
buffer.Set(grpcBuf)

针对响应的处理，则是逆向的，这里不做表述

服务端推流模式

流式处理对于每个 grpc message 的处理逻辑是一样的，唯一不同的是，需要从数据流中切分出一个个 grpc message 出来

不过，好在 grpc message header 里有 4 byte 的长度，要实现分包也简单

核心就是先从 header 里读长度，长度够了就可以切片，解码了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

func (f *filter) transCoder() ([]byte, error) {
	if len(f.remainBuf) < 5 {
		return nil, nil
	}
	size := int(f.remainBuf[1])<<24 | int(f.remainBuf[2])<<16 | int(f.remainBuf[3])<<8 | int(f.remainBuf[4])
	if len(f.remainBuf) < size+5 {
		return nil, nil
	}
	grpcBuf := f.remainBuf[5 : size+5]
	f.remainBuf = f.remainBuf[size+5:]
	data := &demo.Response{}
	err := proto.Unmarshal(grpcBuf, data)
	if err != nil {
		return nil, err
	}
	jsonBuf, err := json.Marshal(data)
	if err != nil {
		return nil, err
	}
	return jsonBuf, nil
}

然后，再将 json 封装为 SSE 流式返回

1

msg := fmt.Sprintf("event: message\\ndata: %s\n\n", jsonBuf)

测试体验

1. 简单模式，实现加法

1
2

curl -X POST localhost:10000/demo.Demo/Add -d '{"x":100,"y":10}'
{"result":110}

2. 流式 SSE 输出

1
2
3
4
5
6

curl -X POST localhost:10000/demo.Demo/GetStream -d '{"x":100,"y":10}'
event: message\ndata: {"result":110}

event: message\ndata: {"result":1000}

event: message\ndata: {"result":90}

Envoy json to grpc

Envoy 有个 json to grpc 的 C++ filter

也可以实现 json 转 grpc，直接从 proto 生成 pb，然后在 Envoy 配置里指定 pb 就可以了

为啥还想着用 Golang 再撸一个呢

有两个原因：

1. Golang 有更强的可定制能力

   比如我们这里把服务端推流转成了 HTTP SSE 协议，如果要在 C++ 里写，开发成本至少要高上一个数量级

2. 后续可以将协议转换再抽象一层

   一来可以像 Envoy 的 json to grpc 一样，直接配置 pb 即可，简单场景代码都可以不需要写了

   另外，也可以支持 HTTP 转基于 TCP 的各种 RPC 协议，这块中国电子云的杜鑫老哥已经搞了一个 提案，PR 也在路上了

意外发现

原本开发实现还挺快的，差不多两个小时就搞定了，不过，到了压测的时候，发现了一个 Golang runtime panic，说是 GC 的时候发现有指针指向了 free 的内存对象。

还好，经过一番折腾，是 Envoy Golang 的一个 bug，header value 如果是空字符串，就有可能踩到这个坑，又搞了 PR 来修复

另外，还有一个功能 bug：trailer 里面设置 header 没有生效，以及一个优化点

细节就不展开了，后面有空的话，单独写一篇来介绍

限流是网关代理的核心能力之一，Nginx 和 Envoy 都有多种限流机制，来应对不同场景的限流需求

准备挖一个新坑，系列性的介绍 Envoy 的各种限流策略，大致按照这个思路：

1. 功能介绍
2. 核心代码实现
3. 与 Nginx 对比

本文作为开头，先水一篇，来点概览性的介绍 ^_^

限制对象

从限制的对象来说，限流分为三种：

1. 连接，包括：

   1. 新建连接频率

   2. TLS 握手频率

   3. 并发连接数量

2. 请求

   一般是请求速率

3. 带宽

   包括单连接级，和某个范围聚合的

限流生效范围

从限流策略的生效范围来说，又分为两种

1. 本地限流

   也就是网关代理的单机级别，因为不需要远程通讯，执行效率最高，是很常见的一种方式，不过依赖流量在各个网关实例上相对平均

2. 全局限流

   跨越网关单机，全局级的限流，因为依赖远程通讯，执行效率会低一些，但是限流更准确

限流用途

限流有两类用途：

1. 保护上游后端

   因为上游后端的服务能力是有上限的，保证转发给后端的请求量，在后端的服务能力之内，从而保证服务的稳定，不至于产生过载/雪崩，导致服务不可用

2. 防 CC 攻击

   在对公网服务的网关中，很常规的保护机制，因为公网的流量可以认为是不授信的，而且恶意请求也是经常会发生的事情

Envoy vs Nginx

Nginx 开源已经 20 年了，Envoy 也开源 8 年了，年头都不算小了

我的个人观点，各有优劣势，也都有不够完善的地方，具体的细节，后面我们慢慢分析

在我看来，很大的一个区别是：

Nginx 作为成熟的南北向网关，在防 CC 攻击这块是更成熟的，Envoy 虽然也有用于南北向网关，不过，更多是在东西向网关，在防 CC 攻击这块，是明显更弱的

比如，防 CC 攻击，最常见的的策略是，针对每个 IP 限流，Envoy 还是不支持的（严谨的说，是官方还没有，第三方插件还是可以搞的）。因为在内网调用中，异常的调用来源，都是内部服务，可以追溯到应用 owner 来背锅的

如果是来自公网的异常调用，是很难找到攻击者来背锅的，这就必须依赖网关来做好基础防护了

好久没折腾 cgo，上一篇已经是去年了，cgo 内存优化无缘 golang 1.22 中提到，golang 1.23 会合并回来

眼看 golang 1.23 即将 freeze，于是提了个 PR，想着开启内存优化

还有 bug

很不幸的是，rsc 说之前 boringcrypto 使用了这个优化，导致了一个 CI 失败，需要先修复了

好吧，原来上一篇里有个乌龙，上次我们说，被 revert 的原因是，#cgo 指令的向后兼容性的问题

实际上并不只是这一个原因，而是，确实还有个 bug …

仔细看了那个 issue，是在 arm64 机器上，并且开启 boringcrypto 特性的时候，才会偶发出现的错误

心想这不会是个 arm64 上的坑吧，难道又要挨个翻 arm64 的指令了…

于是，在阿里云上搞了个 arm64 的机器，发现确实有小概率会测试失败

好吧，能复现就是好的开始，虽然是小概率随机

原因

分析过程就不展开了，有点繁琐，咱们直接说原因

首先，我们这个优化，是让编译器，将内存放到栈上，C 直接使用 Goroutine 栈上的地址，来减少 GC 的开销

然后，问题就是，Gorontine 的栈是会移动的，地址变了，导致 C 使用的地址就是非预期的了

copystack

对于栈移动这种场景，之前也是分析过的，应该是没问题的才对的

因为 runtime 移动栈的操作，也就是 copystack 这个函数，是会处理栈上指针的，让新栈上的指针指向新的地址

stackmap

具体的指针调整，涉及的点还比较多，核心的还是每个栈帧的处理，这里就涉及到 stackmap

大致可以这么理解，每个函数的栈空间是固定的，stackmap 就是描述这个栈空间上对象的信息，比如是否为指针

其中，有一个部分就是存了函数的参数信息，到底是一个 pointer 还是 scalar

这次的问题就出在这里，有些代码上看起来是 pointer 的参数，被编译器认为是 scalar

cgo wrapper

还得先回到 cgo 编译器的实现，比如这样一个 Go 调用 C 的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14

/*
int pointer3(int *a, int *b, int *c, int d) {
	return *a + *b + *c + d;
}
#cgo noescape pointer3
#cgo nocallback pointer3
*/
import "C"

//go:noinline
func testC() {
	var a, b, c, d C.int = 1, 2, 3, 4
	C.pointer3(&a, &b, &c, d)
}

cgo 编译器会生成这样的 wrapper 函数：

1
2
3
4
5
6
7

//go:cgo_unsafe_args
func _Cfunc_pointer3(p0 *_Ctype_int, p1 *_Ctype_int, p2 *_Ctype_int, p3 _Ctype_int) (r1 _Ctype_int) {
	_Cgo_no_callback(true)
	_cgo_runtime_cgocall(_cgo_cab107a710a2_Cfunc_pointer3, uintptr(unsafe.Pointer(&p0)))
	_Cgo_no_callback(false)
	return
}

重点在于，虽然参数有 4 个，但是函数体中只使用了 p0 这一个。

导致编译器 SSA 推导优化之后，后面 3 个都是 non-alive 的了，也就在 stackmap 中被标记为 scalar 了，从而在 copystack 中，后面几个指针值就没有被正确处理了

修复方案

知道了原因，其实修复也比较简单了，最早想的是直接用 runtime.Keepalive，不过生成的 cgo wrapper 包里不能用 runtime 包

最后是参考 _Cgo_use 搞了 _Cgo_keepalive，本质上也还是欺骗下 golang 编译器，让它认为后面的参数是有用的，也就不会被分析为 non-alive 了

最终效果，就是生成了这样的 wrapper 函数：

1
2
3
4
5
6
7
8
9
10
11
12
13

//go:cgo_unsafe_args
func _Cfunc_pointer3(p0 *_Ctype_int, p1 *_Ctype_int, p2 *_Ctype_int, p3 _Ctype_int) (r1 _Ctype_int) {
	_Cgo_no_callback(true)
	_cgo_runtime_cgocall(_cgo_cab107a710a2_Cfunc_pointer3, uintptr(unsafe.Pointer(&p0)))
	_Cgo_no_callback(false)
	if _Cgo_always_false {
		_Cgo_keepalive(p0)
		_Cgo_keepalive(p1)
		_Cgo_keepalive(p2)
		_Cgo_keepalive(p3)
	}
	return
}

是的，多了一些实际上不会执行的 _Cgo_keepalive 的函数调用

shrinkstack

上面分析的是扩栈时的问题，那会不会这种情况呢：

从 Go 进入 C 之后，执行 C 代码的时候，Go runtime 来了个 GC，对 Goroutine 进行缩栈操作呢？

答案是不会的，这个倒是最早在 提案 里就有讨论过的，这种场景下，Goroutine 不会执行 shrinkstack，所以也是安全的

最后

PR 是修复了一版，也请崔老师 trybot 跑了 CI 了，应该问题不大了

不过，Go 1.23 是赶不上了，估计也只能等 Go 1.24 了

不得不说，还是得多谢在 boringcrypto 中尝鲜这个特性的老哥，要不然这个 bug 确实不太好发现

可以想象一下，在 Envoy 的运行过程中，偶发的 panic，比起纯 Go 的测试环境，那查起来是要酸爽很多的了

最近 Envoy Go 扩展有一个比较大的改动：支持全双工流式处理（原来只支持半双工流式处理），趁此做些简单的介绍。

先搞清几个基本概念

什么是流式处理

与流式相对应的就是全缓冲

比如下载一个大文件，全缓冲是完整收到整个文件之后，才会转发给客户端

而流式则是收到一部分，也立即转发多少给客户端

在 nginx 里，默认是全缓冲，proxy_buffering off 就是开启流式处理

envoy 里底层默认是流式处理，除非有 filter 插件不支持流式，必须全缓冲处理

什么是异步处理

流式处理确实也算网关标配了，不过流式加异步就不是了

还是下载一个大文件，我们可以在网关上实现 gzip 压缩，减少网络带宽。

这个 gzip 压缩也是流式处理，但是并不要求异步，因为 gzip 是纯 CPU 计算任务，且 gzip 也有流式的支持。

但是，如果想给 AI 大模型 的流式响应，加上实时的安全审查。

此时，则需要将流式的内容，实时发送给远程审查服务，审查服务返回通过之后，才发给客户端。

这个安全审查，则是需要异步处理了。

这时 Nginx 底层的流式处理机制就玩不转了，因为 nginx 不支持 body 处理阶段挂起请求。
（当然，利用 lua cososcket 来替换 proxy 还是可以玩的）

Envoy 这块的底层机制要灵活一些，body 也支持异步处理，可以随时挂起请求。

Envoy Go 提供了流式的异步处理机制，我们可以使用 golang 的网络库，调用远程的服务，从而轻松的实现上面的安全审查，这是本次修复之前，也能支持的。

什么是全双工

对于普通的 http 请求，可以当做为半双工，也就是，客户端发出请求之后，等待响应之后，才会继续发送请求。
（http pipeline 有点不一样，但是对于 web server 来说，还是一个个来处理的，本质上差异也不大）

但是，对于 websocket，HTTP connnect，GRPC bidirectional 等就不一样了，这类协议里有像 tcp 那样的全双工通信机制，随时都能双向发送数据。

这次修复的问题，就是全双工才会遇到的问题，也是之前没有考虑到位的点。

原因

之前在介绍 并发安全 的时候，提到我们有设计一个所有权机制来解决并发问题，这里的所有权依赖的是一个请求处理的状态机。

而之前没有考虑到全双工的场景，这里的状态机在 c 和 Go 的交互期间，只能有一个存在，也就是，要么在处理请求，要么在处理响应。

所以，在全双工场景，状态机就玩不转了。

修复方式，也比较简单，也就是 c 和 Go 之间，使用两个状态机，请求和响应分别一个，这样就不会冲突了。

只是，知易行难，改动量还是有点大的 …

加上最近内部业务压力有点大，断断续续搞了两个月才搞定 …

演示

这里我们以 websocket 为例，来体验一下 Envoy Golang 对于全双工流式的处理。

这里的后端服务是 gorilla/websocket 的 echo 服务，也就是简单的将客户端发送的数据，原样的返回，这是后端的演示效果：

我们在浏览器端，发送了 foo 和 bar，收到的也是 foo 和 bar。

流式修改内容

我们在中间加入一个 Envoy 的代理，并且开启我们的 Golang 插件示例

我们在 Golang 插件里，演示一下动态修改 websocket 的数据内容，在客户端发给 server 的数据里，加上 Hello, 前缀，在 server 返回给 client 的数据，加上 , World 后缀

如下图所示，我们在浏览器里发送 foo 和 bar，收到的就是 Hello, foo, World 和 Hello, bar, World 了

我们概览下 DecodeData 的核心代码：

因为 DecodeData 收到的数据，是原始数据，需要自己解析 websocket frame 的封包协议；也就是代码里的 readFrame，我们参考 gorilla/websocket 做了些小调整，就实现了一个简单的 frame 协议处理

1
2
3
4
5
6
7
8
9
10
11
12
13

bytes := data.Bytes()
f.reqBuffer = append(f.reqBuffer, bytes...)
var fr *frame
f.reqBuffer, fr = readFrame(f.reqBuffer)
if fr == nil {
  // already cache into Golang side
  data.Reset()
  return api.Continue
}

newData := append([]byte("Hello, "), fr.GetData()...)
fr.SetData(newData)
data.Set(fr.Bytes())

调用远程检查服务

这个示例里，我们只是针对上行数据，也就是客户端发给服务端的数据，将每个包先发给一个远程的服务，示例里是 httpbin.org，如果返回了 200，我们将内容修改为 Authorized，否则就修改为 Unauthorized

所以，也就有了如下的演示效果：

同样，概览下 DecodeData 的核心代码：

这里的主要区别是，我们启动了一个新的启程，来做异步的任务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

bytes := data.Bytes()
f.reqBuffer = append(f.reqBuffer, bytes...)
var fr *frame
f.reqBuffer, fr = readFrame(f.reqBuffer)
if fr == nil {
  // already cache into Golang side
  data.Reset()
  return api.Continue
}
go func() {
  bytes := fr.GetData()
  ok := checkData(bytes)
  if !ok {
    bytes = []byte("Unauthorized")
  } else {
    bytes = []byte("Authorized")
  }
  fr.SetData(bytes)
  data.Set(fr.Bytes())
  f.callback.DecoderFilterCallbacks().Continue(api.Continue)
}()
return api.Running

再看看 checkData 的实现，因为 Envoy Go 支持全功能的 Golang，我们可以直接使用 Golang 的网络库来发请求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Just a demo to request a remote server
func checkData(data []byte) bool {
  req, err := http.NewRequest("POST", "https://httpbin.org/post", bytes.NewBuffer(data))
  if err != nil {
    api.LogDebugf("new request error: %v", err)
    return false
  }

  httpc := &http.Client{}
  resp, err := httpc.Do(req)
  if err != nil {
    api.LogDebugf("query request error: %v", err)
    return false
  }
  resp.Body.Close()

  return resp.StatusCode == 200
}

完整的示例代码可见：https://github.com/doujiang24/envoy-go-websocket-example

最后

网关的流式处理确实也不是什么新鲜的事了，大文件处理场景就已经是刚需了。

只是在 AI 大模型 的生成速度比较慢，又多了一个刚需的场景。

最后，支持全功能的 Golang 语言，优势还是很明显的，现成有的 Golang 库，都能直接使用，没有 tinygo 的限制，哈哈

前两天，在 envoy-wasm Slack 群里看到，有个 Google 大佬 Yan，又在提把 Rust 搞到 Envoy 里来

这次他提到了 Google 的 crubit，这个 C++ Rust 双向互操作工具，看着还蛮有意思的样子，简单记录下的

用 Rust 开发 Envoy

我印象中，这个在 Envoy 社区其实一直有讨论，包括 Envoy 的创始大佬 Matt 也是 Rust 的粉丝

有两个方向，一个是用 Rust 来写 Envoy 核心，另一个则是写扩展

前者是很激进的，我还没看到有人在尝试，后者则相对容易一些，至少可以看到 snowp 大佬尝试的 PR：用 Rust 来写了个 echo 的 demo，https://github.com/envoyproxy/envoy/pull/25409

哈哈，有点类似于，当年春哥给 Nginx 写的 echo-nginx-module：https://github.com/openresty/echo-nginx-module

不过，这个尝试已经弃坑了，Rust 与 Envoy 这种大型 C++ 交互，并不那么简单

Why not Wasm

Rust 可以编译为 Wasm，并且 Wasm 在 Envoy 也已经有集成，为什么还有人想折腾 Rust 原生扩展呢

群里大佬们也说了不少，结合我的理解聊聊：

1. Wasm 需要拷贝内存

   Wasm 也有内存安全机制，字节码读写 VM 内的线性内存地址，所以拷贝是少不了的，现实的实现中，一次读取可能会有多次拷贝

2. API 能力有限

   必须 proxy-wasm-cpp-sdk 包一层 API，Wasm 才能调用，封装链路很长

3. Rust 语言特性支持不完善

   比如异步函数支持就不够好，需要 Wasm Vm 对异步运行时有支持

Crubit 解决什么

Crubit：C++/Rust 双向互操作工具，这是来自官方的定义：https://github.com/google/crubit

具体来说，包括两个点：

1. 函数互相调用

   C++ 和 Rust 之间的函数可以互相调用

2. 内存互相访问

   C++ 和 Rust 之间的数据结构，可以互相访问

理想的期望效果就是，Rust 可以像现在 C++ 一样方便来开发扩展

对比来说，可以简化的是：

1. 不需要包一层 FFI API 来做跨语言调用，这是现有的非 C++ 扩展都面临的问题
2. 不需要手写内存 Struct 的映射，甚至可以直接跨语言读写内存

工作机制

简单说，就是分析源码，自动生成 FFI Wrapper 代码

以 struct 为例，从这个 C++ struct：

1
2
3
4

struct Position {
  int x;
  int y;
};

会自动生成如下的 Rust struct：

1
2
3
4

pub struct Position {
    pub x: ::core::ffi::c_int,
    pub y: ::core::ffi::c_int,
}

这样，写 Rust 代码的时候，就可以像 Rust 一样来操作 C++ Struct 了，还是挺方便的

尤其是，像 Envoy 这种大型 C++ 工程，有很多的 Struct 嵌套，手写是个不小的工程，且维护成本也不小的

前景如何

首先 Crubit 这个项目目前还是初始 “MVP” 版本，看文档貌似还有不少的限制

并且，Yan 大佬也还只是一个想法，也还没有玩起来，估计任重而道远

如果真搞成了的话，应该用起来会方便很多了，估计会有新扩展用 Rust 来实现了

并且，如果走出去了这一步，以后没准越来越多的 Envoy 核心代码，也会由 Rust 来写了

那就让我们拭目以待吧~

还有硬骨头

不过，即使搞定了 C++ 和 Rust 的互相操作，还有一个硬骨头在前面等着，也就是异步调度

因为，Envoy 有一套基于单线程的异步并发模型，Rust 也有自己的异步抽象，这两个如何顺利的配合呢

简单说，前面解决的都是 Rust 的同步函数在 Envoy 上运行的问题

现在要解决的是，Rust 的异步函数如何在 Envoy 上运行的问题

tokio 可以么

直接用 tokio 这种异步运行时可以么？答案是不太好搞

tokio 是一个多线程的运行时，有自己的调度机制，我们可以简单类比为 Golang 的 runtime 调度

一个异步函数，有可能会被调度到不同的线程上来执行，这个就会打破 Envoy 的单线程并发模型的约定

(当然，理论上也是可以解决，每个 Envoy 线程，绑定一个单线程的 tokio 运行时)

并且，tokio 需要有自己的主循环来触发 epoll_wait，这个与 Envoy 自己的 epoll_wait 会有冲突的

除非将两者合并，或者 Envoy 自己撸一个 Rust 的异步运行时

这其中的工作量嘛，想想都头大

跟 MoE 有啥区别

哈哈，我的主业是搞 MoE 的，自然是需要拿出对比一番的

MoE 是把 Golang 嵌入到了 Envoy，跟这里聊的 Rust 嵌入到 Envoy 是同一个领域的不同方案

首先，我们碰到的问题是一样的

1. 跨语言的函数调用，内存操作，需要一些 Wrapper 胶水代码
2. Envoy 有单线程并发模型约定

但是，解题思路不太一样

互操作

MoE 是老老实实自己写 Wrapper 代码，因为定性是扩展开发，其实需要用的 API 并不会太多，总量也比较有限

Rust 方案，其实后续有进入 Envoy Core 代码的可能性，所以这块期望会更高

如果有了更通用的方案，以后 Envoy Core 中的 C++ 代码，慢慢被 Rust 替换掉，也未可知

单线程约束

MoE 比较取巧的绕过了单线程的约束，保留 Goroutine 自由的被调度到其他线程，也就是不需要 Golang runtime 加额外的限制

这样我们可以支持标准的 Golang runtime，现有的 Golang 库直接拿过来就可以用，而不需要改造

但是，我们自己写的 Wrapper 框架代码，又会同时保证 Envoy 的单线程并发约定，所以，也不会有并发问题

而 Rust 的异步机制，并不像 Golang 的 Goroutine 这种完善的重封装，本质上有点类似的 Lua 的协作式协程

甚至，异步运行时都交给第三方库来实现了（好歹 Lua 还是内置提供了 resume 和 yield 这样的调度 API）

所以，Rust 是有机会像 OpenResty 一样，将语言的异步调度和宿主的事件循环结合起来的

最终效果

MoE 一大亮点就是支持原生的 Golang，现有的 Golang 库直接拿来就可以用，而不需要改造

Rust 方案，如果真搞成的话，普世性会比 OpenResty 嵌入 Lua 的效果更好一些

因为 OpenResty 中 Lua 非阻塞库，需要依赖 Nginx 的 event loop 重写一次，比如网络库需要基于 cosocket 重写

而 Rust 的异步运行时，如果与 Envoy 的事件循环结合起来了话，应该现有的异步实现，也可以跑起来的

或许也不需要改造？估计还得取决于具体的实现

不过，虽然我对 Rust 并不熟，不过依然可以笃定这个坑小不了，没那么快到的

最后

还是很期待 Rust 进入 Envoy 的，虽然如果成了的话，会多了一个 Rust 扩展机制，跟 Golang 扩展机制竞争

不过，以我对 Rust 和 Golang 浅显的理解，这两个发展的路线并不太相同，Rust 更偏向于系统编程，Golang 更偏向于业务编程

也就是 Rust 更适合做 Envoy 核心，Golang 更适合做 Envoy 扩展

当然啦，纯粹个人 YY，欢迎大家技术交流~

一句话省流版：API spec 管理方式 + Consumer 类业务网关能力

说来惭愧，作为一个从事网关十来年的老炮，对于 API gateway 的认知却很迷糊，一直不得其要领

初次结缘

关于 API gateway 最初的印象，还是 2015 年的 OpenResty Con，来自 Adobe 张帅的一个分享。他们实现了一个统一的 API 管理平台，把来自内部多个团队的对客 API，给统一管理起来了

当时的大致印象是，哦，一个基于 OpenResty 的网关，用 Lua 来实现认证鉴权之类。但是，对于他提及的 API gateway 却并没有什么认知，只是停留在 OpenResty 数据面的实现机制

妥妥的局限在一个 OpenResty 数据面开发人员的思维，汗…

算是认识

对于 API gateway 作为一个产品的认知，始于 2019 年，那会在春哥公司，搞 OpenResty Edge，有个客户点名想要 Azure APIM 那样的 API 网关

于是，适用体验了一番 Azure APIM，当时两个体会：

1. 基础能力也没啥特别的，也就是网关标准的那些能力，OpenResty Edge 都能支持
2. 主要区别是转发策略的管理方式不同，基于现有的底层能力，包一层皮也是可以实现的

现在看来，其实还是没看懂，局限在接入网关的思路，并且还是开发人员底色。完全没有意识到，管理方式不同，对用户意味着什么

很可惜，后来考虑到 ROI，这个客户没有继续下去，我对 API gateway 的认知也就停留在这里了

用户视角

直到去年，因为项目上线，我们一个服务需要对客提供接口，需要经过统一的 API 网关

于是，作为用户，使用了内部 API 网关之后，给了我很强的冲击，第一次完整的从用户视角，从产品的角度来思考 API gateway

这才有了今天这篇文章，也就是，以我入坑接入网关太深的视角，谈谈 API gateway 到底有什么差异

从我的视角（误区）来看，主要是两个差异

1. 管理方式

表面上看，产品提供给用户的管理方式不同，实际上对应的是，用户群体的不同

1. 接入网关，更多的还是系统运维的视角，更加全局一些
2. API gateway，侧重的是应用开发者的视角

作为应用开发者，最直观的概念还得是 API（路由这种概念，本质上来自网关自身的实现）

在应用开发者的工作流里，一直是围绕着 API 进行的，设计评审，质量验收，安全验收，都是基于 API 进行的

并且，对于 API 的描述，业界也有了一些通用的标准，比如 OpenAPI Specification

那么开发完成之后的发布环节，最自然的也还是继续使用 API 这个概念，通过 API spec，就把 API 发布出去了，这个体验才自然

另外，对于域名，证书什么的，网关最好直接托管了，用户可以不需要操心。对用户来说，有的用，符合公司统一管控规则就行，具体是什么，其实并不太关心

体验了完整的应用开发流程，当了一回用户之后，管理方式的不同，对用户意味着什么，给我的冲击是最大的

本质上来说，软件架构发展，分工细化的演进结果。服务之间通讯是基于 API 的，不同角色之间沟通也是基于 API 的，网关没道理不是基于 API 的

2. 业务网关

上面是基于产品对客，最直观的管理方式，接下来是网关产品能力的了

接入网关侧重于流量接入，更多承载的是公司级的统一管控策略，看重是性能，稳定性

API gateway 侧重于业务网关，为业务服务的角色，承载的业务级别的通用能力

Consumer

举一个常见的例子，API 发布之后，就会有人来调用，对调用方就需要进行认证鉴权

以接入网关的思路，提供一个认证鉴权的插件能力，已经算到头了

API gateway 则是更近一步，抽象了 Consumer 的概念来进行管理

本质上来说，一个 Consumer 就是一个认证鉴权后的身份 ID，初步看起来也没啥差异。但是，我们还可以基于 Consumer 来进行不同的配置，比如根据 Consumer 的等级，配置不同的限流值

对于业务系统来说，已经算是通用的逻辑了，就可以放到 API gateway 上来承载，但是，对于全站级别的接入网关而言，或许就算不上那么通用了

业务插件能力

除了 Consumer 这种绝大部分 API gateway 都会抽象出来的产品能力，还有很多垂类的业务场景的产品能力

比如，眼下很火的 AI 大模型，对客提供的也是 API，那么，API gateway 也是可以承载一些通用的插件能力的

例如：

1. 统一的 API 协议，屏蔽各家大模型提供商的接口差异
2. 统一的 token 二次管理，调用方一个 token 调遍所有大模型
3. 以及，各种调用 metrics
4. 甚至，token 的计量

这种对于接入网关来说，这种属于业务逻辑了，太偏业务了，但是对于 API gateway 这种业务网关来说，那就很合适了

极端点说，有两个业务方需要的通用能力，就可以放到 API 网关来承载…

MoE 硬广时间

由此可见，对于 API gateway 来说，插件扩展能力，会是一个刚需，易用且强大的扩展能力，将是 API gateway 的核心卖点之一

嗯，就这么丝滑，到了 MoE 硬广时间了

MoE 将 Golang 嵌入了 Envoy，我们可以通过 Golang 来实现网关插件，这是研发性能和性能的双赢组合

还不了解的，可以看看去年的几篇旧闻，感兴趣的欢迎技术交流~

今年，我们除了继续完善优化，还会继续往上走，提供一个更高阶的产品出来，让我们拭目以待 😄

最后

其实 API gateway 也很好理解，就是一个以 API 为核心的业务网关，就像它的名字那么简单

上面掰扯这么多的差异分析，基本来自我多年作为网关 developer 的偏见…

看不见、看不起、看不懂、不知道现在补上，来不来得及，哈哈~