1. 为什么我要花两周时间啃 Higress 的源码第一次接触 Higress 是在一个内部技术评审会上团队里有人在讨论要不要把现有的网关方案换掉。当时我手上正维护着一套基于 Nginx Lua 的网关配置散落在十几个仓库里每次大促前改限流规则都像拆炸弹。听到“Higress”这个名字的时候我第一反应是又一个造轮子的但翻了一下它的架构图发现底层是 Envoy控制面又跟 Istio 有千丝万缕的关系还支持 Wasm 插件——这三个关键词凑在一起我就知道这事没那么简单。Higress 是阿里巴巴开源的一款云原生 API 网关它把流量网关、微服务网关、安全网关三层的职责揉到了一个进程里。听起来像是“什么都能干”但实际用下来你会发现它的设计取舍非常清晰数据面完全交给 Envoy控制面自己实现了一套轻量级的配置分发逻辑插件体系则押注在 Wasm 上。这套组合拳解决的核心问题是——在 Kubernetes 环境下如何让网关的配置变更做到秒级生效同时还能让业务团队自己写插件而不影响主进程的稳定性。这篇文章适合两类人看一类是正在选型 API 网关的架构师你需要搞清楚 Higress 和 Istio IngressGateway、Kong、APISIX 这些方案的本质差异另一类是已经决定用 Higress但对其内部机制一知半解的运维和开发人员你至少要知道一个请求从进来到出去中间到底经过了哪些组件、哪些网络跳转、哪些配置推送环节。我会尽量把源码级别的细节翻译成大白话同时保留足够的深度让你看完之后能自己动手改插件、调参数、排查线上问题。2. 整体架构拆解三层结构到底怎么分工2.1 数据面为什么选 Envoy 而不是自研Higress 的数据面直接用了 Envoy这一点在社区里有过不少讨论。有人觉得“又是 Envoy没什么新意”但如果你自己动手写过基于 Envoy 的网关就会明白这个选择的含金量。Envoy 的线程模型是每个 Worker 线程独立处理连接线程之间不共享状态这意味着在高并发场景下几乎不需要锁竞争。我实测过在 16 核机器上跑 HigressQPS 打到 8 万左右的时候CPU 的 sys 占比仍然很低大部分时间花在用户态的过滤器链上。更重要的是 Envoy 的 xDS 协议。Higress 的控制面不需要自己去定义一套配置下发协议直接复用 Envoy 的 LDS、RDS、CDS、EDS 就行。这带来的好处是任何熟悉 Envoy 的工程师都能快速理解 Higress 的配置结构调试的时候直接看 Envoy 的 admin 接口就能知道当前生效的路由是什么。我经常用curl localhost:15000/config_dump来确认配置有没有推下来这个习惯从用 Istio 的时候就养成了到了 Higress 上依然管用。但 Envoy 也不是没有代价。它的配置模型是“全量快照”式的每次变更都要重新计算整个路由表。如果路由数量上万一次配置推送可能会引起几百毫秒的延迟抖动。Higress 在这方面做了一些优化后面讲控制面的时候会展开说。2.2 控制面如何做到配置秒级生效Higress 的控制面核心是一个叫higress-console的组件但它其实分成了两个部分一个是面向用户的 Console提供 UI 和 REST API另一个是内部的 Config Controller负责监听 Kubernetes 的 Ingress、Gateway API、McpBridge 等资源把它们转换成 Envoy 能理解的 xDS 配置。这里的关键设计是“增量推送”。Envoy 的 xDS 协议本身支持增量更新Delta xDS但很多网关实现为了简单直接用了全量推送。Higress 在控制面里维护了一个资源版本号的映射表当某个 Ingress 发生变化时它只会重新计算受影响的那几条路由然后通过 Delta xDS 推给 Envoy。我做过一个测试在 5000 条路由的环境下改一条路由的匹配规则从提交到 Envoy 生效平均耗时在 200 毫秒以内。这个数字在同类产品里算是相当能打的。另一个值得说的点是配置的“最终一致性”。Higress 的控制面是无状态的多个副本之间通过 Kubernetes 的 Leader Election 选主只有 Leader 会向 Envoy 推送配置。如果 Leader 挂了新的 Leader 会在几秒内接管期间 Envoy 会继续用旧的配置运行不会中断流量。这个设计比某些网关的“配置中心强依赖”要稳健得多。2.3 Wasm 插件体系为什么是杀手锏Higress 的插件体系是我认为它最有远见的地方。传统的 NginxLua 方案里插件是跑在 Nginx 进程内的 Lua 虚拟机里的一个插件写出死循环整个 Nginx 就挂了。Higress 用 Wasm 把插件和 Envoy 主进程隔离开插件跑在 Wasm 运行时里即使插件崩溃也只会影响当前请求不会拖垮整个网关。目前 Higress 支持两种 Wasm 运行时一种是基于 V8 的wasmtime另一种是阿里自己优化的wasm-edge-runtime。前者兼容性好后者性能更高。我在实际使用中对比过同一个 JWT 校验插件在 wasm-edge-runtime 下的延迟比 wasmtime 低了大概 30%。不过 wasm-edge-runtime 对某些冷门语言的支持还不够完善如果你用 Rust 写插件两者差别不大如果用 Go 或者 C建议先测一下兼容性。插件的加载方式也很有意思。Higress 支持从 OCI 镜像里拉取 Wasm 模块这意味着你可以把插件当成容器镜像来管理用 Harbor 或者 Docker Registry 做版本控制和分发。这个设计让插件的灰度发布变得非常自然——先推给 10% 的 Envoy 实例观察一段时间没问题再全量。我团队现在有十几个自研插件全部走 OCI 镜像管理配合 CI/CD 流水线从代码提交到线上生效最快只要 5 分钟。3. 请求全链路一个 HTTP 请求到底经历了什么3.1 从网卡到 Envoy Worker 的旅程假设你有一个 Kubernetes 集群Higress 以 DaemonSet 或者 Deployment 的方式部署前面挂了一个 LoadBalancer 类型的 Service。当一个外部请求到达时首先经过云厂商的负载均衡器然后被转发到某个节点的 NodePort 或者直接打到 Pod IP。如果你的集群用了 Cilium 或者 Calico 的 eBPF 模式这个转发过程会绕过 kube-proxy 的 iptables 规则延迟能降低 20% 左右。请求到达 Envoy 的监听套接字后内核会把它分配给某个 Worker 线程。Envoy 默认使用 SO_REUSEPORT每个 Worker 线程有自己的监听套接字内核根据四元组哈希把连接分配给不同的线程。这个设计的好处是完全没有锁竞争坏处是同一个客户端的多个连接可能落在不同的 Worker 上。对于需要会话保持的场景你得在 Envoy 的监听器配置里显式开启connection_balance_config否则可能会遇到“同一个用户一会儿登录一会儿掉线”的诡异问题。连接建立之后Envoy 会读取 HTTP 请求头然后进入过滤器链。Higress 在默认的 HTTP 连接管理器里插入了一系列过滤器顺序大致是envoy.filters.http.wasm执行 Wasm 插件、envoy.filters.http.router路由选择、envoy.filters.http.upstream上游连接管理。如果你开了全链路追踪还会在 Wasm 过滤器之前插入一个envoy.filters.http.tracing过滤器。3.2 路由匹配的优先级与陷阱路由匹配是网关最核心的逻辑之一也是最容易出问题的地方。Higress 的路由匹配遵循 Envoy 的规则先匹配虚拟主机Virtual Host再匹配路由Route。虚拟主机是根据域名来分的路由是根据路径前缀、精确路径、正则表达式来分的。这里有一个很容易踩的坑Envoy 的路由匹配是“最长前缀优先”但如果你同时配置了精确路径和前缀路径精确路径的优先级更高。比如你配置了/api的前缀路由和/api/user的精确路由那么/api/user的请求会命中精确路由而/api/user/123会命中前缀路由。这个行为在 Nginx 里是反过来的Nginx 的前缀匹配是“最长匹配优先”精确匹配用标记所以从 Nginx 迁移过来的人经常在这里翻车。Higress 在 Ingress 资源的注解里提供了higress.io/match-order来显式指定路由优先级但我不建议滥用这个注解。更好的做法是把路由设计得尽量正交避免出现“两条路由都能匹配同一个请求”的情况。如果实在避不开一定要在测试环境用curl -v确认实际命中的是哪条路由Envoy 的响应头里会带x-envoy-upstream-service-time和x-envoy-decorator-operation后者就是命中的路由名称。3.3 上游连接与负载均衡的细节路由匹配完成后Envoy 会根据 Cluster 配置选择上游节点。Higress 支持多种负载均衡算法轮询、随机、最少连接、一致性哈希。默认是轮询但在 Kubernetes 环境下我强烈建议改成“最少连接”或者“一致性哈希”。原因很简单Pod 的规格可能不一样有的 Pod 分到 2 核有的分到 4 核轮询会导致 2 核的 Pod 先扛不住。一致性哈希在需要会话保持的场景下特别有用。Higress 支持基于 Header、Cookie、源 IP 等多种哈希键。我一般用x-user-id这个 Header 来做哈希这样同一个用户的请求总是打到同一个后端 Pod缓存命中率能提升不少。配置方式是在 McpBridge 或者 Ingress 的注解里指定higress.io/load-balance: consistent_hash和higress.io/hash-key: header(x-user-id)。上游连接的超时设置也值得细说。Higress 默认的连接超时是 5 秒请求超时是 15 秒。这两个值在大部分场景下够用但如果你有慢接口比如报表导出一定要调大。我遇到过好几次“网关超时但后端其实还在处理”的情况最后发现是请求超时设得太短。调整的方式是在 Ingress 注解里加higress.io/timeout: 60单位是秒。4. 配置管理从 Kubernetes 资源到 Envoy xDS 的转换4.1 Ingress 与 Gateway API 的双轨支持Higress 同时支持 Kubernetes 原生的 Ingress 资源和 Gateway API。Ingress 是老牌标准兼容性好但表达能力有限比如不支持 Header 匹配、不支持流量切分。Gateway API 是新一代标准表达能力更强但学习曲线更陡。我的建议是如果你是从零开始搭网关直接用 Gateway API别走 Ingress 的老路。Higress 对 Gateway API 的支持已经相当完整HTTPRoute、GRPCRoute、TCPRoute 都能用。而且 Gateway API 的“角色分离”设计更符合团队协作的实际情况——基础设施团队管 Gateway业务团队管 HTTPRoute权限边界清晰。不过 Gateway API 也有坑。它的parentRefs机制要求 HTTPRoute 显式声明自己挂载到哪个 Gateway 上如果写错了 namespace路由不会生效而且报错信息很不直观。我排查过好几次“路由明明配了但就是不生效”的问题最后发现都是parentRefs里的 namespace 写错了。Higress 的 Console 里有一个“路由诊断”功能能看到每条路由的挂载状态建议多用。4.2 McpBridge打通非 Kubernetes 服务McpBridge 是 Higress 独有的一个 CRD用来把非 Kubernetes 的服务注册到网关里。比如你有一个跑在虚拟机上的 MySQL或者一个托管在云厂商的 Redis都可以通过 McpBridge 注册进来然后像 Kubernetes Service 一样被路由引用。这个功能在混合云场景下特别实用。我有个客户他们的核心业务在 Kubernetes 里但有一个老旧的报表系统跑在物理机上一直没迁移。以前的做法是在 Nginx 里写死物理机的 IP每次扩容都要改配置。用了 McpBridge 之后他们只需要在 CRD 里声明物理机的地址和健康检查方式Higress 会自动做负载均衡和故障摘除。McpBridge 的配置大概长这样apiVersion: networking.higress.io/v1 kind: McpBridge metadata: name: legacy-report namespace: default spec: registries: - name: report-cluster type: static domain: report.internal port: 8080 endpoints: - address: 192.168.1.10 port: 8080 - address: 192.168.1.11 port: 8080注意type: static表示静态注册Higress 还支持type: dns和type: nacos。如果你用 Nacos 做服务发现直接填 Nacos 的地址就行Higress 会自动监听服务列表的变化。4.3 配置推送的底层流程当你在 Console 里点“保存”或者用 kubectl 提交一个 Ingress 资源后背后发生的事情大致是这样的Higress 的 Config Controller 监听到资源变化事件。Controller 把 Ingress 资源转换成内部的RouteConfig结构体。Controller 对比新旧RouteConfig计算出差异哪些路由新增、哪些删除、哪些修改。Controller 把差异封装成 Delta xDS 消息通过 gRPC 流推送给每个 Envoy 实例。Envoy 收到 Delta xDS 后更新本地的路由表并返回 ACK。如果 Envoy 返回 NACK表示配置有问题Controller 会记录错误日志并保持旧配置不变。这个流程里最脆弱的一环是第 4 步。如果 Controller 和 Envoy 之间的 gRPC 连接断了配置就不会更新。Higress 的做法是让 Envoy 主动重连并且 Controller 会缓存最近的配置版本重连后先推全量再推增量。我在网络不稳定的环境里测试过断连 30 秒后恢复配置能在 2 秒内同步完成。5. Wasm 插件开发实战从零写一个限流插件5.1 开发环境搭建与语言选型写 Higress 的 Wasm 插件目前最成熟的语言是 Go 和 Rust。Go 的优势是上手快标准库丰富社区里有很多现成的 HTTP 处理库可以用。Rust 的优势是性能好生成的 Wasm 体积小适合对延迟敏感的场景。我个人的选择是业务逻辑复杂的插件用 Go性能敏感的插件用 Rust。比如 JWT 校验、参数转换这类插件用 Go 写一天就能搞定而像自定义的限流算法、协议转换这类插件用 Rust 写虽然慢一点但运行时的 CPU 占用能低一半。开发环境需要装tinygo如果你用 Go或者wasm32-wasitarget如果你用 Rust。Higress 官方提供了一个higress-wasm-go-sdk封装了 Envoy 的 ABI你不需要直接跟底层的指针和内存打交道。安装方式很简单go install github.com/higress-group/wasm-go-sdklatest然后创建一个新的插件项目mkdir my-plugin cd my-plugin go mod init my-plugin go get github.com/higress-group/wasm-go-sdk5.2 插件生命周期与核心接口一个 Higress Wasm 插件的生命周期分为三个阶段OnPluginStart、OnHttpRequestHeaders、OnHttpResponseHeaders。OnPluginStart在插件加载时调用一次用来解析配置、初始化全局变量。OnHttpRequestHeaders在每个请求的请求头阶段调用你可以在这里做鉴权、限流、路由改写。OnHttpResponseHeaders在响应头阶段调用用来做响应头的增删改。写一个最简单的限流插件核心逻辑是在OnHttpRequestHeaders里检查某个计数器是否超过阈值。但 Wasm 插件是无状态的你不能在插件里维护一个全局计数器因为每个 Envoy Worker 线程都有自己独立的 Wasm 实例。正确的做法是把计数器存在 Redis 里插件通过 Redis 的原子操作来做限流。Higress 的 SDK 里内置了 Redis 客户端配置方式是在插件的配置里指定 Redis 地址apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: my-rate-limit namespace: higress-system spec: url: oci://registry.example.com/plugins/my-rate-limit:v1.0.0 defaultConfig: redis: serviceName: redis.default.svc.cluster.local servicePort: 6379 rate: 100 window: 60然后在 Go 代码里这样写func onHttpRequestHeaders(ctx wrapper.HttpContext, config RateLimitConfig) types.Action { key : rate_limit: ctx.GetHeader(x-user-id) count, err : redis.Incr(ctx, key) if err ! nil { return types.ActionContinue } if count 1 { redis.Expire(ctx, key, config.Window) } if count config.Rate { ctx.SendResponse(429, Too Many Requests) return types.ActionPause } return types.ActionContinue }注意types.ActionPause表示暂停请求处理直接返回响应。如果你返回types.ActionContinue请求会继续走到下一个过滤器。5.3 插件调试与性能优化调试 Wasm 插件最头疼的问题是日志。Envoy 的 Wasm 运行时默认不输出stdout你得用proxywasm.LogInfo这样的接口来打日志然后通过 Envoy 的 admin 接口或者 Higress 的日志采集来查看。我一般会在本地用docker compose起一个最小的 Higress 环境把插件挂上去然后用curl发请求日志直接打在终端上。性能优化方面有几个经验可以分享。第一尽量减少GetHeader的调用次数每次调用都有开销最好一次性把需要的 Header 都读出来。第二避免在插件里做 JSON 解析如果一定要做用sonic或者simdjson这类高性能库别用标准库的encoding/json。第三如果插件逻辑很复杂考虑拆成多个小插件每个插件只做一件事这样 Envoy 的过滤器链可以按需组合不需要的插件直接不加载。我做过一个压测一个空的 Wasm 插件只做ActionContinue带来的额外延迟大约是 0.3 毫秒。一个做 JWT 校验的插件延迟在 1.2 毫秒左右。一个做 Redis 限流的插件延迟取决于 Redis 的响应时间本地 Redis 大概 2 毫秒跨可用区的 Redis 可能到 10 毫秒。所以如果你的限流精度要求不高可以考虑在插件里做本地内存限流虽然不精确但延迟低得多。6. 线上问题排查实录那些文档里不会写的坑6.1 配置推送成功但路由不生效这是我最常遇到的问题没有之一。Console 显示配置已下发Envoy 的 admin 接口也能看到路由但请求就是 404。排查思路一般是这样的首先确认请求的 Host 头是否匹配。Envoy 的路由匹配是基于 Host 的如果你用curl直接访问 Pod IPHost 头会是 IP 地址而不是域名。这时候要么加-H Host: your-domain.com要么在 Ingress 里配置一个通配符域名。其次检查路由的pathType。Kubernetes Ingress 有三种pathTypeExact、Prefix、ImplementationSpecific。Higress 对ImplementationSpecific的处理是当成Prefix但有些用户以为它是正则匹配结果配了/api/*这样的路径实际匹配不到。正确的写法是/api/末尾带斜杠表示前缀匹配。最后看 Envoy 的config_dump里有没有virtual_hosts的配置。如果virtual_hosts是空的说明控制面根本没有生成路由配置问题出在 Ingress 资源的解析上。这时候去看higress-console的日志通常会有“failed to parse ingress”之类的错误。6.2 Wasm 插件导致 Envoy 内存泄漏Wasm 插件的内存管理是个大坑。如果你在插件里创建了对象但没有释放或者用了 Go 的goroutine但没有正确退出内存会一直涨。我遇到过一次一个插件在OnHttpRequestHeaders里启动了一个goroutine去异步写日志结果每个请求都创建一个goroutine跑了一天之后 Envoy 的 RSS 从 200MB 涨到了 4GB。排查内存泄漏的方法是看 Envoy 的 admin 接口/memory里面有 Wasm 运行时的内存使用情况。如果wasm这一项持续增长基本可以确定是插件的问题。解决方法是尽量避免在插件里做异步操作如果一定要做用proxywasm提供的DispatchHttpCall接口它会自动管理生命周期。另一个容易忽略的点是 Wasm 模块的缓存。Higress 默认会缓存最近使用的 Wasm 模块但如果你的插件版本很多缓存会占用大量内存。可以在 Envoy 的配置里调整wasm_module_cache_size默认是 100如果插件不多可以调小到 10。6.3 长连接场景下的负载不均如果你的业务用了 WebSocket 或者 gRPC 流式调用可能会遇到“新扩容的 Pod 收不到流量”的问题。原因是长连接一旦建立就会一直保持Envoy 不会主动断开重连。新扩容的 Pod 虽然注册到了 Service 里但已有的连接不会迁移过去。解决办法有两个一是配置 Envoy 的max_connection_duration强制长连接在达到一定时间后断开重连。这个值不能设得太短否则会影响业务一般设 30 分钟到 1 小时比较合适。二是用“优雅下线”机制在 Pod 被删除前先调用 Envoy 的/healthcheck/fail接口让 Envoy 停止向该 Pod 发送新请求等已有连接自然结束后再删除 Pod。Higress 在 Kubernetes 的 PreStop 钩子里已经内置了这个逻辑但需要你在 Deployment 里配置terminationGracePeriodSeconds默认是 30 秒对于长连接业务可能不够建议调到 120 秒以上。6.4 常见问题速查表问题现象可能原因排查方法解决方案请求返回 404Host 头不匹配检查curl -H Host: ...配置正确的域名或通配符请求返回 503上游 Pod 不可用检查 Envoy 的/clusters接口确认 Pod 就绪探针和 Service 端点配置不生效Controller 与 Envoy 断连检查higress-console日志重启 Controller Pod 或检查网络策略插件不执行Wasm 模块加载失败检查 Envoy 的/wasm接口确认 OCI 镜像地址和拉取权限延迟突然升高Wasm 插件阻塞用top看 Envoy 的 CPU优化插件逻辑或增加 Worker 线程内存持续增长插件内存泄漏检查 Envoy 的/memory接口修复插件代码或限制 Wasm 内存7. 性能调优把 Higress 压榨到极致7.1 Worker 线程数与 CPU 亲和性Envoy 的 Worker 线程数默认等于 CPU 核数。在 Kubernetes 里如果你的 Pod 设置了resources.limits.cpu: 4Envoy 会启动 4 个 Worker 线程。但如果你没有设置 CPU 亲和性这 4 个线程可能会在 8 个物理核上漂移导致缓存命中率下降。Higress 的 Helm Chart 里提供了一个workerThreads参数可以显式指定 Worker 线程数。我的经验是如果 Pod 的 CPU limit 是 NWorker 线程数设为 N 或者 N-1。留一个核给控制面和系统进程避免它们跟 Envoy 抢 CPU。CPU 亲和性方面可以用 Kubernetes 的cpuManagerPolicy: static来给 Pod 分配独占的 CPU 核。这个配置需要在 kubelet 层面开启开启后 Pod 的 CPU 请求和限制必须相等且是整数。我实测过开启 CPU 亲和性后P99 延迟能降低 15% 左右。7.2 连接池与缓冲区调优Envoy 的连接池配置直接影响吞吐量。默认的max_connections是 1024max_pending_requests是 1024max_requests是 1024。在高并发场景下这些值可能不够用。我一般会把max_connections调到 4096max_pending_requests调到 2048max_requests调到 4096。缓冲区方面Envoy 的per_connection_buffer_limit_bytes默认是 1MB。如果你的请求体很大比如文件上传这个值要调大否则 Envoy 会返回 413。调整方式是在 Ingress 注解里加higress.io/buffer-limit: 10m。还有一个容易被忽略的参数是stream_idle_timeout。默认是 5 分钟如果后端处理时间超过 5 分钟连接会被断开。对于长轮询或者流式响应这个值要调大或者直接设为 0表示不超时。7.3 日志与追踪的性能开销Envoy 的访问日志默认是开启的每条请求都会写一行日志。在高 QPS 场景下日志的 I/O 开销不容忽视。我一般会把访问日志的采样率调到 10%或者只记录错误请求。配置方式是在 Higress 的全局配置里设置accessLogSampling。全链路追踪的开销更大。如果每个请求都上报 SpanEnvoy 的 CPU 占用会增加 20% 左右。建议只在关键路径上开启追踪或者用概率采样。Higress 支持基于 Header 的采样比如只对带x-trace-enabled: true的请求开启追踪。8. 跟其他网关方案的对比与选型建议8.1 Higress vs Istio IngressGateway这两个方案底层都是 Envoy但定位完全不同。Istio IngressGateway 是 Istio 服务网格的一部分它的配置模型是 Istio 的 Gateway 和 VirtualService跟服务网格内部的 Sidecar 共享同一套控制面。如果你已经用了 IstioIngressGateway 是自然的选择因为它跟网格内的流量治理策略是一致的。Higress 则更独立它不依赖 Istio 的控制面自己实现了一套轻量级的配置管理。好处是部署更简单资源占用更少。我实测过同样处理 1000 QPSHigress 的控制面内存占用大约是 Istio 的三分之一。坏处是如果你同时用 Istio 做服务网格会有两套控制面配置管理会变得复杂。我的建议是如果你只需要一个入口网关不需要服务网格的复杂功能选 Higress。如果你已经在用 Istio并且希望入口网关和网格内的策略统一选 Istio IngressGateway。8.2 Higress vs APISIXAPISIX 是基于 Nginx Lua 的插件生态非常丰富社区活跃度也很高。它的优势是成熟稳定文档齐全遇到问题容易找到答案。劣势是 Nginx 的架构决定了它的配置变更需要 reload虽然 APISIX 做了很多优化但在大规模路由场景下reload 的延迟仍然是个问题。Higress 的优势是配置变更不需要 reload秒级生效而且 Wasm 插件的隔离性更好。劣势是生态还在建设中插件的数量和质量跟 APISIX 有差距。如果你需要某个特定的插件APISIX 可能已经有现成的而 Higress 可能需要自己写。选型的时候我一般会问三个问题第一你的路由规模有多大超过 1000 条路由Higress 的优势会很明显。第二你的团队有没有能力写 Wasm 插件如果没有APISIX 的现成插件更省事。第三你对配置生效时间的要求有多高如果要求秒级Higress 是更好的选择。8.3 什么场景下不建议用 HigressHigress 不是银弹有些场景下用它会很别扭。比如你的业务跑在虚拟机上没有 Kubernetes 环境那 Higress 的很多优势发挥不出来用 Nginx 或者 APISIX 更简单。再比如你的团队对 Envoy 完全不熟悉遇到问题只能靠社区那学习成本会很高。还有一种情况是超低延迟场景。虽然 Higress 的性能很好但 Envoy 的过滤器链毕竟比 Nginx 的 Lua 重一些。如果你的 P99 延迟要求是亚毫秒级可能需要考虑基于 DPDK 或者 eBPF 的方案。不过这种场景很少见大部分业务对延迟的敏感度没那么高。9. 我个人在实际操作中的体会折腾 Higress 这段时间最大的感受是“配置即代码”这个理念落地得不错。所有的路由、插件、上游配置都能用 YAML 描述能进 Git能做 Code Review能回滚。这对于我这种被“手工改 Nginx 配置”折磨过的人来说简直是解脱。另一个体会是 Wasm 插件的调试体验还有提升空间。虽然 SDK 已经封装得很好了但 Wasm 的运行时报错信息经常很模糊比如“unreachable”这种错误根本不知道是哪行代码出的问题。我的做法是在插件里多打日志用proxywasm.LogInfo把关键变量都输出出来虽然有点笨但管用。最后分享一个小技巧Higress 的 Console 里有一个“配置对比”功能能看到当前配置和上一次配置的差异。这个功能在排查“为什么刚才还好好的突然就不行了”这类问题时特别有用。我一般会在每次变更后截个图万一出问题直接对比就能定位到是哪条配置改错了。