云原生网关容错指南Higress 的 4 个默认机制后端抽风时请求照样通【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higressHigress 把云原生网关容错做成了默认行为请求失败自动重试、坏实例自动掉出流量、配置源中断继续按上一份好配置转发。你不需要在业务代码里再写一遍重试和降级这些活网关层先干了。 你的系统会先从哪倒聊机制之前先看新手最常踩的三个故障现场。第一个是实例挂掉的那一瞬间。三副本的部署里一个 pod 被 OOM 杀掉没有任何防护时打到这个 pod 的三分之一请求直接 502更糟的是负载均衡还认为它活着继续往里送。第二个是权重对不上账。你上金丝雀新版本权重填 10、老版本填 80剩下 10% 的流量归属就成了未定义行为——有的实现直接报错有的按意外规则分发。第三个是配置源打了个嗝。Nacos 升级重启两分钟或者集群网络抖一下你得担心网关里的服务清单会不会被清空新请求是不是直接无处可去Higress 的整体架构里控制平面和数据平面是分离的配置通过 xDS 协议下发这个分离是后面所有容错能力的前提——控制平面抖一抖数据平面手里还握着最后一次下发的快照继续转发故障被限制在配置暂时不更新而不是流量中断。上面三个故障场景正好对应下面三套机制。 机制一请求失败时自动重试重试不会把后端压垮一次瞬时的 TCP 重置、一次短暂的建连失败重试一次通常就能过去。但新手最容易犯的错是盲目重试后端已经过载你还往上压第二波流量等于把故障放大。Higress 的思路是重试面收窄、重试量封顶。在 Gateway 路由里声明 retry 后默认最多重试 2 次且默认触发条件只有四类连接级故障外加你显式指定的状态码retryOn : []string{connect-failure, refused-stream, unavailable, cancelled}上面是路由转换逻辑里的默认重试条件清单。注意它默认不会重试 500/503 这类应用层错误——这不是遗漏是刻意设计后端正在生病时不该被自动重试继续捶打。量的那头由重试预算把关重试预算的实现支持按百分比限制重试流量的占比最小重试并发数默认 10。并发低时保留一小撮重试额度流量高峰时把重试压回预算之内。一句话重试在这里是止血不是加压。上一节解决了单次请求的问题可如果某个实例持续带病重试只是反复撞它还得把它从流量池里摘出去。⚖️ 机制二坏实例自动掉出流量权重配错也能自圆其说Envoy 的主动健康检查干的就是这件事数据平面周期性探测每个 endpoint探测失败就停止向它发流量。一次请求沿 Listener、Cluster、Endpoint 三级走下去健康检查失败的实例不再进入负载均衡的轮转名单流量自然流到健康实例上这就是零停机故障转移——你不用写任何转移逻辑。算法方面一个load-balance注解就能切换轮询、最少连接、一致性哈希按请求头、cookie 或源 IP外加会话保持负载均衡注解解析把这些都覆盖了不配的话默认轮询。权重是另一个容易算错的地方。金丝雀两个版本写了 3 和 5合计 8很多实现会报错Higress 会直接归一化到合计 100把差额自动补给老版本。权重归一化与 fallback 处理里还藏着降级逻辑给路由加上 fallback 注解并指定默认后端主服务彻底不可用时请求会被内部重定向到默认后端业务拿到的是降级响应而不是 5xx。重试和摘除护住的是请求内的事最后一道防线要护配置本身——服务清单错了上面全白搭。️ 机制三配置源断了网关照着上一份好配置继续跑Higress 的配置面可以并行监听多个源Kubernetes 的 Ingress/Gateway CRD以及 Nacos/Consul/Zookeeper 里的服务注册走 MCP bridge全部用 List/Watch 模型多源的关键不是源多而是每个源的 watcher可看 registry/watcher.go只在协调成功时更新本地内存状态连接断了不清空已有状态网络恢复后重连并同步增量。某个源整体下线其他源继续推送数据平面手里始终攥着一份可用快照。再给网关自己加一层保险gateway pod 用/healthz/ready做就绪探针没就绪就不接流量——网关自己也遵守带病不接客。 十分钟自己验证以上不必只听我讲十分钟能跑一轮故障注入用 tools/hack/ 下的脚本起本地环境install-kind-metallb.sh 建集群setup_env.sh 备环境再装 helm/core 的核心 chart。先验证网关健康检查怎么配就绪探针打的是/healthz/ready参数就是 helm/core/values.yaml 里 readiness 开头的一组值默认连续失败 30 次才判未就绪、每 2 秒查一次、超时 3 秒readinessFailureThreshold: 30 readinessPeriodSeconds: 2正菜删掉一个后端 pod然后连续发请求。你会看到极少量瞬时重试但没有 5xx——这就是机制二的零停机故障转移顺带把机制一的重试也验证了。想看更系统的验证直接读 test/e2e/conformance/ 目录官方一致性测试框架在 Kind 集群里把 Ingress 应用下去对比网关实际行为与规格预期整体架构如下需要更细的容错层就叠插件控制台插件市场一键安装plugins/wasm-go/extensions/ 下的 ai-load-balancer多模型负载均衡与故障转移、ai-cache响应缓存降级、ai-quotatoken 流控都是现成的。可观测性也预置了helm/core/templates/podmonitor.yaml 已经把指标暴露给 Prometheus。 常见误用Qretry 设了 3 次是不是每个 5xx 都会重试 3 次不是。默认重试只覆盖连接级失败和你显式指定的状态码后端自己吐的 503 不在默认名单里要重试得把 503 明确加进去。Q金丝雀权重写了 3 和 5合计 8配置是不是失效了不失效也不报错会归一化成约 37.5% / 62.5%缺口自动补给老版本。想要精确比例就把合计写成 100。Qgateway pod 反复在就绪和未就绪之间抖动放宽阈值行不行先看/healthz/ready背后到底是什么没就绪再动 values.yaml 里的 readiness 参数。只把 failureThreshold 调大等于让真死的 pod 多接一段时间流量。Q重试预算是不是熔断器不是。它限制的是重试流量占比不是按 QPS 的熔断。要限 QPS 得上限流类插件两者职责不同。收尾重试、摘除坏实例、权重自洽、多源配置兜底四层各管一段叠起来的效果是单点故障发生时请求大概率还是能通。想动手抠细节的话最快的入口是去 pkg/ingress/kube/gateway/istio/conversion.go 看一眼默认重试条件和默认次数——那一行代码就是 Higress 默认容错观的边界。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 云原生网关容错指南：Higress 的 4 个默认机制，后端抽风时请求照样通
云原生网关容错指南Higress 的 4 个默认机制后端抽风时请求照样通【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higressHigress 把云原生网关容错做成了默认行为请求失败自动重试、坏实例自动掉出流量、配置源中断继续按上一份好配置转发。你不需要在业务代码里再写一遍重试和降级这些活网关层先干了。 你的系统会先从哪倒聊机制之前先看新手最常踩的三个故障现场。第一个是实例挂掉的那一瞬间。三副本的部署里一个 pod 被 OOM 杀掉没有任何防护时打到这个 pod 的三分之一请求直接 502更糟的是负载均衡还认为它活着继续往里送。第二个是权重对不上账。你上金丝雀新版本权重填 10、老版本填 80剩下 10% 的流量归属就成了未定义行为——有的实现直接报错有的按意外规则分发。第三个是配置源打了个嗝。Nacos 升级重启两分钟或者集群网络抖一下你得担心网关里的服务清单会不会被清空新请求是不是直接无处可去Higress 的整体架构里控制平面和数据平面是分离的配置通过 xDS 协议下发这个分离是后面所有容错能力的前提——控制平面抖一抖数据平面手里还握着最后一次下发的快照继续转发故障被限制在配置暂时不更新而不是流量中断。上面三个故障场景正好对应下面三套机制。 机制一请求失败时自动重试重试不会把后端压垮一次瞬时的 TCP 重置、一次短暂的建连失败重试一次通常就能过去。但新手最容易犯的错是盲目重试后端已经过载你还往上压第二波流量等于把故障放大。Higress 的思路是重试面收窄、重试量封顶。在 Gateway 路由里声明 retry 后默认最多重试 2 次且默认触发条件只有四类连接级故障外加你显式指定的状态码retryOn : []string{connect-failure, refused-stream, unavailable, cancelled}上面是路由转换逻辑里的默认重试条件清单。注意它默认不会重试 500/503 这类应用层错误——这不是遗漏是刻意设计后端正在生病时不该被自动重试继续捶打。量的那头由重试预算把关重试预算的实现支持按百分比限制重试流量的占比最小重试并发数默认 10。并发低时保留一小撮重试额度流量高峰时把重试压回预算之内。一句话重试在这里是止血不是加压。上一节解决了单次请求的问题可如果某个实例持续带病重试只是反复撞它还得把它从流量池里摘出去。⚖️ 机制二坏实例自动掉出流量权重配错也能自圆其说Envoy 的主动健康检查干的就是这件事数据平面周期性探测每个 endpoint探测失败就停止向它发流量。一次请求沿 Listener、Cluster、Endpoint 三级走下去健康检查失败的实例不再进入负载均衡的轮转名单流量自然流到健康实例上这就是零停机故障转移——你不用写任何转移逻辑。算法方面一个load-balance注解就能切换轮询、最少连接、一致性哈希按请求头、cookie 或源 IP外加会话保持负载均衡注解解析把这些都覆盖了不配的话默认轮询。权重是另一个容易算错的地方。金丝雀两个版本写了 3 和 5合计 8很多实现会报错Higress 会直接归一化到合计 100把差额自动补给老版本。权重归一化与 fallback 处理里还藏着降级逻辑给路由加上 fallback 注解并指定默认后端主服务彻底不可用时请求会被内部重定向到默认后端业务拿到的是降级响应而不是 5xx。重试和摘除护住的是请求内的事最后一道防线要护配置本身——服务清单错了上面全白搭。️ 机制三配置源断了网关照着上一份好配置继续跑Higress 的配置面可以并行监听多个源Kubernetes 的 Ingress/Gateway CRD以及 Nacos/Consul/Zookeeper 里的服务注册走 MCP bridge全部用 List/Watch 模型多源的关键不是源多而是每个源的 watcher可看 registry/watcher.go只在协调成功时更新本地内存状态连接断了不清空已有状态网络恢复后重连并同步增量。某个源整体下线其他源继续推送数据平面手里始终攥着一份可用快照。再给网关自己加一层保险gateway pod 用/healthz/ready做就绪探针没就绪就不接流量——网关自己也遵守带病不接客。 十分钟自己验证以上不必只听我讲十分钟能跑一轮故障注入用 tools/hack/ 下的脚本起本地环境install-kind-metallb.sh 建集群setup_env.sh 备环境再装 helm/core 的核心 chart。先验证网关健康检查怎么配就绪探针打的是/healthz/ready参数就是 helm/core/values.yaml 里 readiness 开头的一组值默认连续失败 30 次才判未就绪、每 2 秒查一次、超时 3 秒readinessFailureThreshold: 30 readinessPeriodSeconds: 2正菜删掉一个后端 pod然后连续发请求。你会看到极少量瞬时重试但没有 5xx——这就是机制二的零停机故障转移顺带把机制一的重试也验证了。想看更系统的验证直接读 test/e2e/conformance/ 目录官方一致性测试框架在 Kind 集群里把 Ingress 应用下去对比网关实际行为与规格预期整体架构如下需要更细的容错层就叠插件控制台插件市场一键安装plugins/wasm-go/extensions/ 下的 ai-load-balancer多模型负载均衡与故障转移、ai-cache响应缓存降级、ai-quotatoken 流控都是现成的。可观测性也预置了helm/core/templates/podmonitor.yaml 已经把指标暴露给 Prometheus。 常见误用Qretry 设了 3 次是不是每个 5xx 都会重试 3 次不是。默认重试只覆盖连接级失败和你显式指定的状态码后端自己吐的 503 不在默认名单里要重试得把 503 明确加进去。Q金丝雀权重写了 3 和 5合计 8配置是不是失效了不失效也不报错会归一化成约 37.5% / 62.5%缺口自动补给老版本。想要精确比例就把合计写成 100。Qgateway pod 反复在就绪和未就绪之间抖动放宽阈值行不行先看/healthz/ready背后到底是什么没就绪再动 values.yaml 里的 readiness 参数。只把 failureThreshold 调大等于让真死的 pod 多接一段时间流量。Q重试预算是不是熔断器不是。它限制的是重试流量占比不是按 QPS 的熔断。要限 QPS 得上限流类插件两者职责不同。收尾重试、摘除坏实例、权重自洽、多源配置兜底四层各管一段叠起来的效果是单点故障发生时请求大概率还是能通。想动手抠细节的话最快的入口是去 pkg/ingress/kube/gateway/istio/conversion.go 看一眼默认重试条件和默认次数——那一行代码就是 Higress 默认容错观的边界。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考