Higress 这两年在中大型公司的网关选型里出镜率很高，但大部分讨论还停留在“性能比 Nginx 好”“阿里开源”这个层面。真正把它当生产基础设施用起来之后，我发现它是非常典型的“拿服务网格的引擎做北向网关”的设计：数据面用 Envoy，控制面复用并裁剪了 Istio 的能力，然后在此基础上叠加网关场景才需要的多注册中心、插件系统和 AI 网关能力。这篇文章不打算重复官方文档，而是按我理解它的原理顺序来拆：为什么选 Envoy、控制面怎么把 CRD 变成 xDS、多注册中心接入时的内存问题怎么解决、插件系统从 Lua 到 WASM 的演进、以及最近很热的 AI 网关能力到底改了什么。适合正在选型、或者已经上了 Higress 但想搞清楚内部机制的读者。

1. 为什么选择站在 Envoy 和 Istio 的肩膀上

1.1 传统网关的瓶颈在哪里

做网关的人对 Nginx 这条技术线大多又爱又恨。Nginx 本身是个出色的 Web 服务器，但拿它当企业级 API 网关底座，限制会逐渐显现。首先是扩展机制，OpenResty 用 Lua 注入业务逻辑，这个模式确实催生了 Kong、APISIX 这一批网关，但 Lua 的调试体验和内存安全一直是个隐患。lua_shared_dict、cosocket 这些概念用好了很顺手，用不好就是线上事故，一个不经意的全局变量污染可能让所有 worker 一起遭殃。

更本质的问题是配置生效模型。Nginx 的配置变更基本依赖 reload，reload 虽然比重启轻，但会重建 worker 进程、断开存量连接，长连接场景下影响尤其明显。网关承载的往往是核心链路流量，每一次 reload 都意味着用户感受到至少一次连接重连。

Java 系的网关也好不到哪去。Spring Cloud Gateway 这类方案在中小规模下够用，但高并发下的 GC 停顿、内存占用、以及从注册中心同步路由的延迟，都让它很难成为大流量场景的首选。市面上的网关方案各有各的适用域，但都缺少一个关键东西：一套不重启、不抖动、可编程性强的数据面执行引擎。

1.2 为什么是 Envoy，而不是继续用 Nginx

Envoy 和 Nginx 虽然同为 C++ 实现的反向代理，但设计哲学完全不同。Nginx 的核心是 location 配置块和模块化的 HTTP 处理阶段，而 Envoy 把网络数据通路拆成了 L4 过滤器链和 L7 过滤器链，每个过滤器都是一段可编程的逻辑，连接管理、TLS 终止、HTTP 路由、限流、认证，全部以过滤器形式串联起来。

这个过滤器模型带来的自由度是革命性的。你想在请求进入路由之前做一次参数改写，只需插一个 filter；想对上游响应做流式处理，同样在 filter 里处理 decodeData/encodeData。这样每个业务能力都是一个边界清晰的模块，而不是在 Nginx 的某个 phase 里塞一堆难以隔离的代码。

另一个决定因素是 xDS 协议。Envoy 天生就支持通过 Listener Discovery Service、Route Discovery Service、Cluster Discovery Service、Endpoint Discovery Service 动态下发配置，这意味着数据面的路由、集群、端点可以随时变更，不需要 reload，不需要重启。配置变更对存量连接的影响被降到了最低，这正好补上了 Nginx 路线的致命短板。

1.3 和 Istio 的关系：拿网格的引擎做网关

光有 Envoy 还不够，它只是一个数据面，配置从哪来、怎么组织、怎么推送，需要一个控制面来管。Higress 的高明之处在于没有从零写一套控制面，而是直接复用了 Istio 的 Pilot/istiod 核心：配置模型、xDS 生成、推送机制、增量更新逻辑，这些都是服务网格领域打磨了很多年的产物。

但 Higress 没有把 Istio 原样搬过来。Istio 是为 Sidecar 注入模式设计的，天然带着 mTLS、RBAC、证书轮换、安全命名等一批网格专属能力，这些对集中式网关来说大多用不上，反而会拖慢配置收敛速度。Higress 做的是裁剪：去掉网格专用逻辑，保留 xDS 的成熟实现，再补上 Istio 网关模式里一直欠缺的东西——多注册中心接入、插件体系、管理控制台。

所以你会看到一个很有意思的结果：Higress 原生支持 Istio 的 VirtualService、Gateway 这些 CRD。你可以用 Istio 的语义描述流量规则，同时享受 Higress 提供的网关增强能力。它既不是又一个 Nginx 壳，也不是完整版 Istio，而是取了网格的数据面稳定性和控制面成熟度，补上了网关真正需要的业务层能力。这个定位在开源网关里其实是独一份的。

2. 控制面如何把“配置”变成“流量规则”

2.1 组件构成与各自职责

Higress 部署后在 K8s 里主要是两类工作负载，外加一个可选的控制台组件。理解这三个角色的分工，基本就理解了它的运行机制。

控制器是整个配置链路的发动机。它通过 K8s Informer 监听 Ingress、Gateway API、VirtualService、DestinationRule、HigressPlugin、HigressServiceSource 等资源，任何资源变化都会触发一次内部配置模型重建和一次向数据面的推送。网关实例则是一批 Envoy Pod，它们只做一件事：接收控制器下发的配置，并按照配置处理流量。

2.2 从 Ingress 到 xDS：一条请求规则的一生

用一个最小例子走一遍链路。假设我创建了这么一条 Ingress：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: api-svc port: number: 8080

这条 Ingress 提交到集群后，控制器的 Informer 会在毫秒级收到事件，随后做四件事。

第一，解析。控制器把 Ingress 的 host、path、backend 翻译成内部统一的模型对象，这背后其实是 Istio 那套虚拟主机和路由抽象。第二，组装。内部模型会被映射成 Envoy 的资源：一个监听 80 端口的 Listener，一个 host 为 app.example.com 的 VirtualHost，一条匹配前缀 /api 的 Route，指向名为 api-svc 的 Cluster。第三，推送。控制器通过 ADS 聚合下发，把 LDS、RDS、CDS、EDS 一次性推给所有网关 Pod。第四，生效。Envoy 收到配置后，对 Route 表做原子替换，新的请求就会走进新规则。

这套流程里最值得琢磨的是“为什么能保证下发的顺序不导致流量黑洞”。Envoy 的配置依赖是：Route 引用 Cluster，Cluster 依赖 Endpoint，Listener 依赖 RouteConfiguration。如果推送顺序不对，比如 Route 先到了但 Cluster 还没到，请求就会暂时匹配不到上游。Higress 的控制器在生成配置时已经维护好这层依赖关系，并通过集群预热机制让新 Cluster 先完成 Endpoint 加载和健康检查，再开始承接流量。这也是为什么生产环境里做规则变更时，基本感受不到流量中断。

2.3 最终一致性模型与推送抖动控制

xDS 配置是最终一致的，不是事务性的。资源变化后，控制器会先聚合一小段时间内的所有变更，再一次性推送，而不是每变化一个端点就推一次。这个 debounce 机制在注册中心实例频繁上下线时特别重要，否则控制面会被 EDS 推送风暴打垮。

线上排查 Higress 问题时，我建议养成先看数据面实际配置的习惯。Envoy 的 admin 端口默认是 15000，一条命令就能看到网关当前加载的所有配置：

curl localhost:15000/config_dump?include_eds=true

输出里会完整列出 Listener、Route、Cluster、Endpoint 的当前状态。常见的问题，比如路由没生效、上游端点为空、集群抖动，在这里一眼就能定位。比对着日志猜要快得多。

3. 服务注册与发现：多注册中心适配的关键设计

3.1 各类注册中心如何接入

Higress 支持 Kubernetes Service、Nacos、Consul、Zookeeper、静态 DNS 五种服务来源，它们通过 HigressServiceSource 这个 CRD 声明注册到控制面。每种来源的接入机制差别很大，但最终都会收敛成 Envoy 的 EDS 端点。

控制器拿到注册中心的实例列表后，会为每个服务生成对应的 Envoy Cluster，并把实例转换成 Endpoint 推给数据面。实例上的元数据（比如 Nacos 里的版本号、标签）会被保留到 Endpoint 的 metadata 中，这是后面做版本路由、灰度发布的基础。

这里有一个很多人忽略的细节：接入 Nacos 时应该尽量在 HigressServiceSource 里配置只订阅需要的服务，而不是把注册中心里几千个服务全量拉到网关。全量订阅意味着控制面要为所有服务维护配置模型，任何一个服务抖动都会触发全局推送，这个成本在网关规模大时会非常可观。我见过有团队图省事全量订阅，结果注册中心一抖，网关 P99 直接翻倍，排查了半天才定位到是订阅范围太宽。

3.2 VUH 机制：解决 Envoy 集群数爆炸

这是 Higress 在原理层面最值得讲的一个创新，理解了它才算真正理解 Higress 和裸 Envoy 网关的区别。

在原生 Envoy 里，每个 Cluster 都独立维护一份自己的端点主机列表。打个比方，一个服务的 100 个实例，会被完整拷贝到每一个引用它的 Cluster 里。如果同一个逻辑服务因为版本、路由、消费者差异被拆成多个 Cluster（比如主集群、v1 子集群、v2 子集群，或者按端口、按区域拆分），那 100 个实例就要被复制多份。

在微服务规模上来之后，这个问题会变成灾难。假设注册中心里有 500 个服务，平均每服务 100 个实例，再假设因为灰度、版本子集、多路由引用，一个服务平均拆成 3 个 Cluster，那数据面就要维护 1500 个 Cluster，每个 Cluster 里都存了一份 100 个端点的数据结构。总的端点副本数是 500×100×3，也就是 15 万个端点对象。而实际上真实存在的端点只有 5 万个，多出来的 10 万份全是重复存储。

Higress 的 VUH（Versioned Upstream Holder）机制解决的就是这个问题。它的思路非常朴素：把所有服务的真实端点集中存放在一个共享的持有器里，所有 Cluster 不再各自存端点副本，而是引用这个持有器的某个视图。端点数据只有一份，哪个 Cluster 需要，就通过持有器按版本、按元数据筛出对应的主机列表。

“Versioned”这个词也很关键。持有器里的主机不是简单的地址列表，而是带版本标识的分组，所以 Envoy 在做负载均衡时，可以从共享数据里快速筛选出 v1 子集或 v2 子集，而无需为每个子集单独保存一份完整的主机结构。

这个改造带来的收益是结构性的：端点内存占用不再随 Cluster 数线性膨胀，而只和真实服务实例数相关。EDS 推送也只需要更新持有器里的原始数据，所有引用它的 Cluster 自动感知变更，推送开销从“每次更新 N 份拷贝”变成“更新 1 份原始数据”。

3.3 内存收益的数量级测算

拿上面那个例子做个粗略估算。假设 Gateway Pod 规格是 8C16G，每个端点对象加负载均衡器的开销按 1KB 算：

• 原生方案：1500 个 Cluster × 100 个端点 × 1KB = 150MB 端点存储，这还不算 Cluster 自身的元数据和 LB 内部结构。
• VUH 方案：500 个服务 × 100 个端点 × 1KB = 50MB 端点存储，加上 1500 个 Cluster 各持一个轻量引用，额外开销几乎可以忽略。

这还只是 500 个服务的规模。当服务数到 2000 甚至 5000 时，两者差距会从“差一个量级”变成“一个能用、一个根本起不来”。我实际用下来的感受是，接入大规模 Nacos 集群时，Higress 的内存表现和原生 Envoy 网关完全不是一个水平，这也是它在微服务注册中心场景下最核心的竞争力来源。

还有一点值得注意：端点数据共享后，负载均衡器的选择结果也变得更稳定。因为每个 Cluster 看到的是同一份主机视图，某个端点健康状态变化时，所有 Cluster 对它的感知是一致的，不会出现“这个 Cluster 认为它在线、那个 Cluster 认为它下线”的分裂状态。

4. 路由与流量治理在数据面的真实落地

4.1 Ingress 规则到 Envoy 路由的映射逻辑

Higress 同时支持 Kubernetes Ingress、Gateway API、Istio VirtualService、以及自定义的 HigressRouteRule 等多种路由来源。不管用哪种，它们在控制面都会收敛到同一个目标：Envoy 的 VirtualHost 和 Route 结构。

映射规则并不复杂。Ingress 里的 host 字段对应 VirtualHost 的域名；path 和 pathType 对应路由的匹配方式，Prefix 映射为前缀匹配，Exact 映射为精确匹配；backend 对应 Cluster 名。控制器把所有来源的路由统一排序后写入 RouteConfiguration。

路由顺序是这里最容易踩坑的地方。Envoy 是按配置顺序逐条匹配路由的，如果多条路由的匹配条件存在重叠，排在前面的会优先生效。Higress 在生成路由时有一套自己的排序逻辑，总体原则是精确域名优先于泛域名、更具体的路径优先于更宽的路径。理解这个原则之后，遇到“我配的路由为什么不生效”这类问题，先别怀疑代码，去看看是不是有更高优先级的规则把流量截走了。

4.2 灰度发布与版本权重切换

灰度发布是网关最常用的场景，Higress 提供了两套并行的语义。用 Ingress 的话，走的是 nginx 风格的 canary 注解；用 Istio CRD 的话，直接用 VirtualService 的权重路由，表达更清晰：

apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: api-canary spec: hosts: - api http: - route: - destination: host: api subset: v1 weight: 90 - destination: host: api subset: v2 weight: 10

控制面收到这个 VirtualService 后，会把它翻译成 Envoy 的 weighted_cluster 路由配置。Envoy 在每次请求进入时按权重随机选择一个 Cluster 处理，90% 流量进 v1，10% 流量进 v2。这里有个经验：如果灰度场景要求同一个用户始终访问同一个版本，需要配置基于 Header 或 Cookie 的一致性哈希，否则每次请求都可能落在不同版本上，用户会感觉“界面一会儿新一会儿旧”。

版本子集的路由能力依赖注册中心实例元数据。Nacos 里给实例打上 v1、v2 的版本标签后，Higress 的 VUH 机制会按版本维护主机分组，DestinationRule 里的 subset 就是从这些分组里筛出对应主机。整个过程不需要把不同版本部署成不同的 Service，省去了很多运维成本。

4.3 超时、重试、熔断与限流的配置语义

网关的治理能力在 Higress 里分两层：底层的超时、重试、熔断、负载均衡直接映射 Envoy 的 Cluster 和 Route 配置；上层的限流、WAF、认证则走插件系统。分清这两层，配置时就不容易混乱。

这里面有一个典型的认知误区：很多人把 Envoy 的 circuit_breakers 理解成“失败率达到阈值就熔断”，其实它是客户端连接池的保护机制，限制的是对某个上游的最大并发连接和最大请求数。想要“根据错误率动态摘除不健康实例”，应该配置的是 outlier_detection。两者都是熔断家族，但作用对象完全不同，前者保护网关自身资源，后者保护上游稳定性。

限流这块，Higress 的官方插件支持本地限流和 Redis 分布式限流两种。单实例场景用本地限流就够，多副本部署时一定要用 Redis 版本，否则每个网关副本各自计数，整体 QPS 会被放大到副本数的倍数。Token 桶算法的参数配置在插件配置里，按需设置每秒填充速率和桶容量即可。

5. 插件机制深度拆解：从 Lua 兼容到 WASM

5.1 HigressPlugin：一个插件的完整生命周期

Higress 的插件系统通过 HigressPlugin CRD 管理，一个典型的认证插件配置长这样：

apiVersion: extensions.higress.io/v1alpha1 kind: HigressPlugin metadata: name: key-auth spec: defaultConfig: consumers: - name: app1 key: app1-key phase: AFTER_ROUTE rules: - match: domains: - api.example.com paths: - /v1/* config: consumers: - name: app1 key: app1-key

这个 CRD 的几个字段值得逐一拆解。defaultConfig 是全局默认配置；rules 是路由级配置，按域名和路径匹配，命中的请求会拿到这份独立配置；phase 控制插件在路由匹配之前还是之后执行。

控制器在 watch 到这个 CRD 时会做两件事：把插件的 WASM 二进制或其 OCI 镜像引用通过 ECDS 下发给数据面，同时把插件配置转换成 Envoy HTTP 过滤器链里的具体参数。Envoy 拿到新配置后会为后续新建的流创建对应的过滤器上下文，整个过程不需要重启网关进程。这个“配置即热更新”的体验，对比 Nginx 时代的 reload，差别是代际级的。

5.2 WASM 插件在 Envoy 里的执行链路

从执行链路看，WASM 插件本质上是 Envoy HTTP 过滤器链里的一环。请求进入网关后，会依次经过解码阶段的 decodeHeaders、decodeData、decodeTrailers；响应返回时则走编码阶段的 encodeHeaders、encodeData、encodeTrailers。WASM 插件就是通过 proxy-wasm ABI 在这几个阶段注册自己的处理逻辑。

插件二进制是沙箱运行的。Envoy 的 WASM 运行时把它加载进独立的虚拟机，插件不能直接访问宿主机内存，不能直接发起网络请求，所有能力都必须通过宿主提供的 ABI 函数完成，比如读取 Header、追加响应体、发起异步 HTTP 调用等。这种隔离性是传统 Lua 插件给不了的：插件写崩了，最多是这个工作线程上的相关请求失败，不会把整个网关进程带崩。

这里有一个必须强调的坑：Envoy 的每个 worker 线程会加载一份独立的 WASM 虚拟机实例，插件里的全局变量是在各自线程内独立的。如果你在插件里写了一个计数器想统计总请求量，多线程并发下数据会各自累加，根本对不上。需要跨线程共享状态时，必须借助外部存储，通常是 Redis。我见过不止一次有人把计数器写在插件全局变量里，看监控数据时怎么都对不上，最后才发现是线程模型的问题。

插件的执行阶段设置也有讲究。phase 设为 BEFORE_ROUTE 的插件在路由匹配前执行，此时还没选出后端，所以拿不到路由级配置；AFTER_ROUTE 的插件则在匹配后执行，可以通过上下文拿到路由的配置信息。如果你的插件逻辑依赖具体路由的配置，记得用 AFTER_ROUTE，否则永远读到的都是默认值。

5.3 为什么路由级插件配置比全局配置更实用

网关最典型的场景是多个业务方共用一条入口，不同域名、不同路径需要不同的认证和限流策略。Higress 的 rules 机制在 Envoy 层面本质上是把插件配置写进了路由的 typed_per_filter_config，让每个路由携带自己的插件参数。这样同一个插件可以根据请求命中的路由加载不同配置，实现租户级别的隔离。

举个例子，电商平台可以给 /v1/order 和 /v1/pay 两个路径配置不同的认证插件和限流阈值，给 /v1/public 放行。这些控制都发生在一条网关链路上，不需要为每个业务方单独部署一套网关。

Higress 的 consumer 概念也是基于这个机制实现的。插件先将请求识别为某个消费者，后续的限流、审计、计费都可以按消费者维度精细化控制。这比传统网关“一个监听一套配置”的粗粒度模型灵活得多，也是 Higress 能承接大规模多团队流量治理需求的原因。Lua 插件在 Higress 早期承担了兼容 Nginx 生态的过渡职能，但随着 WASM 生态成熟，官方推荐的新插件都走 WASM 路线，新增能力也集中在 WASM 插件的形态上。

6. 向 AI 网关演进：协议透传与 Token 限流

6.1 AI 网关要解决的新问题

大模型应用爆发后，网关面临的需求和传统 API 网关完全不是一回事。业务方往往要同时接入 OpenAI、Anthropic、国内多家大模型厂商的接口，每家的 API 格式不同，鉴权方式不同，流式响应协议也不同。如果让每个业务团队各自对接这些厂商，不仅重复劳动，密钥管理也是灾难。

AI 网关要解决的核心问题有三个：统一协议接入、成本精细化控制、密钥安全托管。Higress 这代版本最大的变化就是把 Envoy 从“转发 HTTP 请求的管道”变成了“理解 LLM 协议的中间层”。它不是转发字节流，而是能解析请求和响应内容、识别模型、计量 Token 的协议网关。

6.2 协议转换、请求改写与 Token 计量

Higress 的 AI 能力核心是 ai-proxy 这类插件，它在 Envoy 过滤器链上承担协议转换和内容感知的职责。客户端只需要按 OpenAI 兼容的格式把请求发给网关，插件会根据路由配置把请求重新编排成对应厂商协议要求的格式。比如客户端发的是 chat/completions 结构，而目标上游是 Anthropic 的 messages 接口，插件需要在请求路径上完成字段映射、格式改写、鉴权头注入。

流式响应处理是 AI 网关和传统网关最大的分水岭。LLM 的响应普遍走 SSE 流式传输，第一个 token 的延迟直接决定用户体验。插件不能把整个响应缓存下来再处理，必须在流式数据经过时逐帧解析，保留 SSE 事件边界，提取增量文本用于 Token 计量，再把数据原样透传给客户端。

Token 限流也和 QPS 限流完全不同，这里有几个工程细节值得展开。非流式响应里，模型会返回 usage 字段，Token 数可以直接取；流式响应则没有 usage，只能由网关自己累计每个 SSE 事件的文本增量，再按算法估算 Token。估算方案常见的是按字符数乘系数，中文大致一个汉字对应一个 Token 上下，但实际因分词器而异，所以生产上通常会把估算值乘以一个安全系数，宁可略高也不放量。输入 Token 可以在请求进入时预扣，输出 Token 要等流结束才知道，所以需要“先预扣、后结算”，把上一个请求的实际消耗合并到下一个请求的额度里。

密钥轮换和故障转移也是 AI 场景刚需。网关在收到上游 401 或 429 时，可以自动切换到密钥池里的下一个 Key 并重试。这里要注意的是，流式请求已经开始后不能做重发，所以这类逻辑通常只作用于请求路径上，也就是在连接上游之前完成 Key 选择。

6.3 落地 AI 网关时容易踩的坑

AI 网关这类功能跑起来之后，最常见的坑集中在流式处理和分布式计数上。

第一个坑是 SSE 解析的边界问题。网络层分片并不等于 SSE 事件的分隔，一个事件可能横跨多个 TCP chunk，或者一个 chunk 里包含多个事件。如果插件按 chunk 而不是按完整的事件边界解析，Token 计数就会错乱。正确的做法是在字节层面做流式缓冲，以空行作为事件结束标记，保证解析的是完整事件。

第二个坑是不要用“缓冲全部响应”的方式做处理。有人图省事，在 encode 阶段先把整个响应体读进内存再处理，这在流式场景下等于彻底摧毁了首 token 延迟体验，用户会明显感觉到回答变“顿”。正确的方式是增量处理，只保留必要状态。

第三个坑是分布式限流的计数一致性。Token 限流如果只在单 worker 的内存里计数，多副本多线程一放大，限流就是摆设。生产环境必须用 Redis 令牌桶，而且要注意把限流的 key 设计成“消费者 + 模型”的维度组合，否则一个业务方调用一个便宜模型时占用了另一个模型的配额。

7. 部署选型与线上调优经验

7.1 三种形态的取舍

Higress 部署方式大概分三条路：K8s Helm 自建、非 K8s 轻量模式、以及公有云托管版本。选型依据不是“哪个更好”，而是团队有没有能力运维一个控制面。

我自己的观点是，生产环境尽量用 Helm 自建或托管，轻量模式适合做功能验证。控制面虽然复杂，但 Higress 的控制器、数据面分离架构让升级路径相对可控，运维成本主要落在监控和变更管理上。挖个坑说一句：网关 Pod 滚动升级时一定要给足 drain time，否则存量长连接会被硬断，业务方会收到大量连接重置的报错。实际操作中我会在 Pod 的 preStop hook 里先调用健康检查失败接口，让流量调度先把网关摘掉，等 drain 窗口结束再真正退出。

7.2 关键参数调优清单

数据面调优，有几项是我每次上生产环境必调的：

• 并发模型：Envoy 默认按 CPU 核数创建 worker 线程，网关 Pod 规格不要盲目给大核，8 核以下通常足够，每个 worker 独占一个 CPU 才能保证事件循环稳定。
• 请求体缓冲区：默认的下游连接 buffer 对普通 API 够用，但 AI 场景的提示词可能很大，需要按路由把 buffer 调大，否则请求体会被提前截断返回 413。
• 上游长连接：给上游配置 HTTP/2 keepalive，能明显降低后端服务的连接建立开销，高并发下对延迟毛刺的改善非常明显。
• EDS 推送防抖：注册中心实例上下线频繁时，控制面会触发频繁推送，确认控制器版本支持 debounce 配置并开启。
• WASM 插件数量：每个 worker 会加载一份 WASM 实例，插件越多内存占用越高，别把一个 8C 的 Pod 全塞满重量级插件。
• 访问日志：全量 access log 在高峰期会消耗大量 CPU，改成抽样或者只记录错误请求，能省下可观资源。

流量治理侧的默认参数也建议过一遍。比如默认的超时时间、重试次数、熔断阈值，每个团队的上下游能力不同，直接套默认值容易出问题。重试策略尤其要谨慎，网关层重试如果配合幂等性差的下游，会把重复订单这种事故放大。

7.3 线上稳定性经验

最后分享几条我实际维护 Higress 之后的体会，不一定对每个环境都适用，但思路是可以复用的。

第一，排障先看数据面，再谈控制面。遇到路由不生效、流量分发不对，先 curl 网关 admin 端口的 config_dump，确认数据面当前到底加载了什么配置，比盯着控制面的日志猜测高效得多。配置下发链路长，问题可能出在 CRD 解析、配置生成、推送、数据面应用的任何一环，config_dump 能直接告诉你数据面已经走到了哪一步。

第二，关注注册中心抖动的影响面。无论是 Nacos 还是 Consul，实例上下线本身是常态，但大规模抖动会引发 EDS 批量推送，把网关的 CPU 打上去。我遇到过一次 Nacos 客户端和注册中心之间网络分区，所有实例被批量标记为不健康，网关瞬间收到大量端点移除事件。这种场景下，VUH 的共享存储模型优势很明显，但控制面的推送压力依然存在，所以订阅范围一定要收敛，只在必要的服务集合上做监听。

第三，插件的灰度发布比网关版本升级更常发生，也更危险。WASM 插件虽然是沙箱，无法直接弄崩网关，但一个写得很糟糕的插件可以把 worker 的 CPU 吃满。插件上线前先跑性能基准，确保单 worker 下的延迟增量在可接受范围，再按域名小流量灰度，最后全量。

Higress 这套架构里最值得借鉴的思路，不是某个具体功能，而是它在“稳定成熟的数据面”和“快速迭代的业务能力”之间找到了平衡点。控制面把 Envoy 的复杂配置消化成简单的 CRD，插件系统提供业务扩展的沙箱，而 VUH 这类机制解决的是真正制约规模的问题。把这几层原理理清楚，无论是日常排障、容量规划还是二次开发，都会从容很多。