Higress 云原生网关架构解析：Wasm 插件与 Envoy 扩展实践

1. 从 Istio 到 Higress云原生网关的演进逻辑1.1 为什么 Envoy 是云原生网关的基石聊 Higress 之前得先把 Envoy 这个地基说清楚。Envoy 是 Lyft 开源的高性能 L4/L7 代理用 C 编写核心设计理念是基于事件驱动的多线程架构加可插拔的过滤器链。它的线程模型很讲究主线程负责配置更新和 xDS 协议交互Worker 线程各自独立处理连接每个 Worker 跑一个事件循环连接不跨线程避免了锁竞争。实测下来单核 QPS 能跑到几万级别这个性能底子在网关场景里非常关键。Envoy 的过滤器链分四层Listener Filter、Network Filter、HTTP Filter、Upstream Filter。HTTP 层的扩展点最丰富Wasm 插件就是挂在这一层。理解这个分层对后面分析 Higress 的 Wasm 扩展机制至关重要因为 Higress 的插件能力本质上是在 Envoy 的 HTTP Filter Chain 里做文章。另一个关键点是xDS 协议。Envoy 本身不存储配置所有路由、集群、监听器信息都通过 xDSDiscovery Service从控制面动态下发。这套机制让 Envoy 天然适合做数据面控制面可以独立演进。Higress 的架构选择很大程度上就是围绕如何做一个更轻、更快的控制面展开的。1.2 Istio 的架构优势与落地痛点Istio 是 Service Mesh 领域的标杆控制面用 Go 写的 Pilot 组件统一管理流量规则数据面默认用 Envoy。它的核心价值在于把服务治理能力从业务代码里剥离出来通过 Sidecar 模式实现流量管理、安全、可观测性。这套思路在微服务场景下非常优雅。但 Istio 在实际落地时有几个绕不开的痛点。第一是资源开销每个 Pod 注入一个 Sidecar内存占用动辄 50-100MB几千个 Pod 的集群光 Sidecar 就要吃掉大量资源。第二是运维复杂度Istio 的 CRD 一大堆VirtualService、DestinationRule、Gateway、ServiceEntry 之间的关系错综复杂排查问题经常要在多个 CRD 之间来回跳。第三是配置生效延迟Pilot 推送配置到 Envoy 需要时间大规模集群下这个延迟可能到秒级甚至更长。更关键的是很多团队其实并不需要完整的 Service Mesh他们只是想要一个好用的南北向入口网关。Istio 的 Gateway 虽然能干活但配置繁琐扩展能力也受限于 Envoy 原生 Filter。这就给 Higress 留出了空间。1.3 Higress 的定位站在 Istio 肩膀上的轻量网关Higress 是阿里开源的云原生网关它的定位很明确兼容 Istio 生态但专注于网关场景做得更轻、更快、扩展性更强。它复用了 Istio 的控制面能力准确说是兼容 Istio API数据面依然是 Envoy但在控制面做了大量精简和优化。Higress 的核心卖点有三个一是Wasm 插件扩展用 Wasm 替代传统的 Lua 脚本性能和安全性都更好二是配置秒级生效通过优化 xDS 推送机制配置变更几乎实时生效三是多协议支持HTTP、gRPC、Dubbo、MQTT 都能接这对国内很多用 Dubbo 的团队很友好。从架构上看Higress 的控制面叫Higress Controller它监听 K8s 的 Ingress、Gateway API、以及自定义的 WasmPlugin 等 CRD转换成 Envoy 能理解的 xDS 配置下发。数据面就是标准的 Envoy但 Higress 对 Envoy 做了一些定制比如内置了一些常用插件、优化了配置加载逻辑。2. Higress 核心架构拆解2.1 控制面与数据面的职责划分Higress 的架构可以简单理解成一个 Controller N 个 Envoy 实例。Controller 负责配置管理Envoy 负责流量转发。这个划分和 Istio 类似但 Higress 的 Controller 更轻量它不依赖 Istiod而是自己实现了一套配置转换逻辑。控制面的核心工作流是这样的用户创建 Ingress 或 Gateway API 资源Higress Controller 监听到变更把 K8s 资源转换成 Envoy 的 xDS 配置主要是 Listener、Route、Cluster、Endpoint 四类然后通过 gRPC 推送给 Envoy。Envoy 收到配置后热更新整个过程不需要重启。这里有个设计细节值得说Higress 的 Controller 用了增量推送机制。传统的 xDS 推送是全量下发配置大了之后推送慢、内存占用高。Higress 通过对比配置差异只推送变化的部分实测在几千条路由的场景下配置生效时间能控制在毫秒级。这个优化对大规模集群很关键。数据面这边Higress 对 Envoy 的定制主要在两方面一是内置插件把常用的鉴权、限流、跨域等能力做成 Wasm 插件预置进去二是配置优化比如调整了 Envoy 的线程数、连接池参数让它在网关场景下表现更好。2.2 Wasm 插件机制Higress 的扩展利器WasmWebAssembly是 Higress 最核心的扩展机制。传统的 Envoy 扩展要么改 C 代码重新编译要么用 Lua 脚本性能差。Wasm 的好处是沙箱隔离、多语言支持、热加载。你可以用 Go、Rust、C 写插件编译成 Wasm 字节码运行时动态加载不用重启 Envoy。Higress 的 Wasm 插件运行在 Envoy 的Wasm Runtime里底层用的是 V8 引擎没错就是 Chrome 那个 V8。每个插件跑在独立的沙箱里插件崩溃不会影响 Envoy 主进程。插件通过ABIApplication Binary Interface和 Envoy 交互可以访问请求头、请求体、响应头等数据也能调用外部服务。写一个 Higress Wasm 插件的基本流程是这样的用 Go 的proxy-wasm-go-sdk定义插件逻辑实现OnHttpRequestHeaders、OnHttpRequestBody等回调函数编译成.wasm文件然后通过 WasmPlugin CRD 挂载到指定路由上。整个过程不需要改 Envoy 代码也不需要重启网关。这里有个实操心得Wasm 插件虽然方便但性能不是免费的。每次请求进出插件都有序列化/反序列化开销复杂插件可能增加几毫秒延迟。我的经验是鉴权、限流这类轻量逻辑用 Wasm 没问题但如果要做复杂的请求体转换最好评估一下性能影响。2.3 多协议支持的技术实现Higress 支持 HTTP、gRPC、Dubbo、MQTT 等多种协议这在网关产品里不多见。实现方式上HTTP 和 gRPC 是 Envoy 原生支持的Dubbo 和 MQTT 则是通过协议转换插件实现的。以 Dubbo 为例Higress 的做法是在 Envoy 里挂一个 Dubbo 协议解析插件把 HTTP 请求转换成 Dubbo 协议调用后端服务。这个插件是用 Wasm 写的核心逻辑是解析 HTTP 请求的路径和参数映射成 Dubbo 的服务名和方法名然后走 Dubbo 的序列化协议发给后端。对前端来说它就是一个普通的 HTTP 接口感知不到后面是 Dubbo。MQTT 的支持类似Higress 内置了 MQTT 协议的解析能力可以把 MQTT 消息转成 HTTP 或者直接转发到 MQTT Broker。这对 IoT 场景很有用设备用 MQTT 上报数据网关统一做鉴权和限流。多协议支持的技术难点在于协议识别和转换的性能。Higress 的做法是在 Listener 层做协议嗅探根据端口或者首包特征判断协议类型然后走对应的 Filter Chain。这个设计比较巧妙避免了为每种协议单独开端口。3. 核心功能模块深度解析3.1 路由匹配从 Ingress 到 Envoy Route 的转换路由是网关最基础也最核心的功能。Higress 的路由配置来源有三种K8s Ingress、Gateway API、以及 Higress 自定义的 McpBridge多集群桥接。不管哪种来源最终都要转换成 Envoy 的 Route 配置。Envoy 的路由匹配规则很灵活支持精确匹配、前缀匹配、正则匹配还能根据 Header、Query 参数、HTTP 方法做条件路由。Higress 在转换时会把 Ingress 的path和pathType映射成 Envoy 的prefix或path匹配。比如 Ingress 里写path: /api、pathType: Prefix转换后就是 Envoy 的prefix: /api。这里有个容易踩的坑路由优先级。Envoy 的路由匹配是按顺序来的先匹配到的生效。Higress 在转换时会根据路径长度、匹配类型自动排序确保精确匹配优先于前缀匹配。但如果你手动写了多条路由最好自己确认一下顺序避免出现预期外的匹配结果。另一个细节是路由的元数据传递。Higress 支持在路由上挂 Wasm 插件这个挂载关系是通过 Route 的typed_per_filter_config字段实现的。理解这个机制对排查插件不生效的问题很有帮助。3.2 负载均衡与健康检查Higress 的负载均衡复用了 Envoy 的能力支持轮询、随机、最少连接、一致性哈希等策略。默认是轮询但实际生产环境里一致性哈希用得比较多因为它能保证同一用户的请求落到同一后端对缓存友好。健康检查分主动检查和被动检查。主动检查是 Envoy 定期发探测请求比如每 5 秒发一个 HTTP 请求到/health连续失败几次就把实例摘掉。被动检查是根据实际请求的失败率来判断比如连续 5 个请求返回 5xx就临时摘除实例。Higress 默认开启被动检查主动检查需要手动配置。配置健康检查时有几个参数需要仔细调interval检查间隔、timeout超时时间、unhealthy_threshold连续失败几次标记不健康、healthy_threshold连续成功几次标记健康。我的经验是interval不要设太短否则探测请求本身会成为负担unhealthy_threshold也不要太小避免网络抖动导致误摘。3.3 限流与熔断保护后端的最后一道防线限流和熔断是网关的保命功能。Higress 的限流支持本地限流和全局限流两种模式。本地限流是在每个 Envoy 实例上独立计数实现简单但不够精确全局限流需要一个 Redis 做集中计数精度高但有网络开销。Higress 的全局限流是基于Envoy 的 Rate Limit Service实现的底层用 Redis 做计数器。配置时需要在 WasmPlugin 里指定 Redis 地址和限流规则比如每个 IP 每分钟最多 100 次请求。实测下来Redis 限流的延迟在 1-2 毫秒左右对大部分场景可以接受。熔断这块Higress 用的是 Envoy 的Circuit Breaker机制。可以配置最大连接数、最大并发请求数、最大重试次数等阈值超过阈值就直接拒绝请求避免后端被压垮。熔断的触发和恢复是自动的Envoy 会根据后端实例的健康状态动态调整。这里分享一个实操经验限流和熔断的阈值不要拍脑袋定。最好先压测一下后端的承载能力然后按 80% 的量设置阈值。另外限流规则要留出应急通道比如给内部调用或者特定用户开白名单避免误伤。4. 实操部署与配置指南4.1 快速搭建 Higress 环境部署 Higress 最简单的方式是用 Helm。前提是你有一个 K8s 集群1.20 版本并且装了 Helm 3。下面是完整的部署步骤# 添加 Higress Helm 仓库 helm repo add higress.io https://higress.io/helm-charts helm repo update # 创建命名空间 kubectl create namespace higress-system # 安装 Higress helm install higress higress.io/higress \ --namespace higress-system \ --set global.hubhigress-registry.cn-hangzhou.cr.aliyuncs.com/higress \ --set global.taglatest安装完成后用kubectl get pods -n higress-system检查 Pod 状态。正常情况下会看到higress-controller、higress-gateway等 Pod 处于 Running 状态。接下来部署一个测试服务验证网关是否工作# 部署一个简单的 echo 服务 kubectl create deployment echo --imagehigress-registry.cn-hangzhou.cr.aliyuncs.com/higress/echo-server:latest kubectl expose deployment echo --port80 # 创建 Ingress 规则 cat EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: echo-ingress spec: ingressClassName: higress rules: - host: echo.example.com http: paths: - path: / pathType: Prefix backend: service: name: echo port: number: 80 EOF配置完成后通过网关的 LoadBalancer IP 或者 NodePort 访问echo.example.com应该能看到 echo 服务的响应。这一步验证了从 Ingress 到 Envoy 的完整链路。4.2 Wasm 插件开发实战写一个 Higress Wasm 插件需要 Go 1.18 和 TinyGo用于编译 Wasm。下面是一个简单的鉴权插件示例功能是检查请求头里有没有Authorization没有就返回 401。package main import ( github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types ) func main() { proxywasm.SetVMContext(vmContext{}) } type vmContext struct { types.DefaultVMContext } func (*vmContext) NewPluginContext(contextID uint32) types.PluginContext { return pluginContext{} } type pluginContext struct { types.DefaultPluginContext } func (*pluginContext) NewHttpContext(contextID uint32) types.HttpContext { return httpContext{} } type httpContext struct { types.DefaultHttpContext } func (*httpContext) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action { auth, err : proxywasm.GetHttpRequestHeader(Authorization) if err ! nil || auth { proxywasm.SendHttpResponse(401, nil, []byte(Unauthorized), -1) return types.ActionPause } return types.ActionContinue }编译成 Wasmtinygo build -o auth-plugin.wasm -targetwasi main.go然后通过 WasmPlugin CRD 挂载apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: auth-plugin namespace: higress-system spec: url: file:///opt/plugins/auth-plugin.wasm phase: AUTHN priority: 100 matchRules: - ingress: - echo-ingress这个插件会在请求进入时检查Authorization头没有就返回 401。phase: AUTHN表示在鉴权阶段执行priority控制多个插件的执行顺序。4.3 全局限流配置详解全局限流需要先部署 Redis然后配置 Rate Limit Service。Higress 内置了限流插件配置方式如下apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: rate-limit namespace: higress-system spec: url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/rate-limit:latest phase: AUTHZ priority: 200 config: redis: serviceName: redis-service servicePort: 6379 timeout: 1000 rules: - match: prefix: /api limit: requestsPerUnit: 100 unit: minute key: remote_address这个配置表示对/api前缀的请求按客户端 IP 限流每分钟最多 100 次。key字段支持remote_address、header、query等多种取值方式。配置生效后可以用ab或wrk压测验证wrk -t4 -c100 -d30s http://echo.example.com/api/test如果限流生效超过阈值的请求会返回 429 状态码。5. 性能调优与问题排查5.1 性能调优的关键参数Higress 的性能调优主要围绕 Envoy 的线程模型和连接池展开。下面几个参数是重点参数默认值调优建议说明concurrencyCPU 核数保持默认Envoy Worker 线程数一般等于 CPU 核数max_connections1024按需调大每个 Listener 的最大连接数max_pending_requests1024按需调大等待上游响应的最大请求数max_requests1024按需调大每个连接的最大并发请求数connect_timeout5s按后端调整连接后端服务的超时时间调优的核心思路是匹配后端能力。如果后端服务能扛 1000 并发网关的连接池就要能撑住这个量。但也不能无限调大否则网关本身会成为瓶颈。另一个优化点是Wasm 插件的执行顺序。插件是按priority顺序执行的把轻量插件如日志放前面重量插件如鉴权放后面能减少不必要的开销。实测下来合理排序能降低 10%-20% 的延迟。5.2 常见问题速查表问题现象可能原因排查方法解决方案502 Bad Gateway后端服务不可达检查 Service 和 Endpoint确认后端 Pod 状态和端口404 Not Found路由未匹配检查 Ingress 规则和 Host确认 path 和 host 配置正确插件不生效WasmPlugin 未挂载检查 matchRules 和 phase确认插件 URL 和优先级配置不生效Controller 未推送查看 Controller 日志检查 xDS 连接状态限流不准确Redis 连接异常检查 Redis 连通性确认 Redis 地址和密码延迟高插件过多或过重用 Envoy 的 stats 分析精简插件或优化逻辑排查问题的第一步永远是看日志。Higress Controller 的日志在higress-system命名空间下Envoy 的日志可以通过kubectl logs查看。Envoy 还提供了/stats接口能看到详细的请求指标对定位性能问题很有帮助。5.3 踩坑记录与经验总结说几个我实际踩过的坑。第一个是Wasm 插件的内存限制。Envoy 默认给每个 Wasm 插件分配的内存有限如果插件里做了大量数据缓存可能会触发 OOM。解决办法是在 WasmPlugin 配置里调大vmConfig的内存限制或者优化插件逻辑减少内存占用。第二个是路由匹配的顺序问题。有一次配了两条路由一条是/api/v1一条是/api结果/api/v1的请求被/api匹配走了。原因是/api的路由优先级更高。后来在 Higress 的配置里显式指定了优先级问题才解决。这个坑提醒我路由配置一定要仔细检查顺序。第三个是限流规则的粒度。一开始按 IP 限流结果发现同一个 NAT 后面的用户共享 IP容易被误伤。后来改成按用户 ID 限流从请求头里取X-User-ID精度高了很多。这个经验说明限流的 key 选择要根据实际业务场景来定。Higress 这个项目从架构设计到功能实现都体现了轻量、高效、易扩展的思路。它没有重复造轮子而是站在 Envoy 和 Istio 的肩膀上把网关场景做深做透。Wasm 插件机制是它最大的亮点让扩展变得简单又安全。如果你正在选型 API 网关或者想深入了解云原生网关的实现原理Higress 值得花时间研究。