Higress 高可用实践降级、重试与多源配置如何让 API 流量始终可用【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higressHigress 是阿里开源的云原生 API 网关基于 Envoy 和 Istio 定制主打控制面与数据面分离的架构。对很多团队来说网关最核心的价值不是转发本身而是故障发生时流量还能怎么走。读完这篇文章你能理解 Higress 在高可用上的三层设计配置层、流量层、降级层知道接入后优先检查哪些配置以及出问题时如何快速定位是路由、重试还是降级环节出了问题。从一个 502 故障说起假设你正在做金丝雀发布新版本实例已上线路由权重切了 20% 过去但新版本频繁 502。此时你面临三个连续的问题故障实例上的流量会不会被自动摘掉失败请求要不要重试重试会不会把故障实例打得更狠如果整个后端都不可用用户看到的应该是什么Higress 对这三个问题的回答分别藏在 Envoy 端点健康检查、重试与预算RetryBudget机制、以及 fallback 路由里。下面按配置怎么下发—流量怎么走—坏了怎么兜底的顺序拆开讲。机制一控制面与数据面分离配置从哪来问题如果网关强依赖某个配置中心配置中心抖动时网关会不会跟着不可用关键组件Higress Controller控制面和 Higress Gateway数据面核心是 Envoy。控制面负责服务发现和配置管理通过 xDS 协议一种 Envoy 定义的配置下发协议把路由、集群、端点等信息推送给数据面。整体工作流可以参见 docs/architecture.md。系统行为配置源不单一。除了 Kubernetes 资源Ingress、Gateway API 等Higress 还内置了 McpBridge 机制把 Nacos、Eureka、Consul、Zookeeper 等外部注册中心的服务信息转换成内部可用的 ServiceEntry相关实现见 registry/ 目录。某个注册中心暂时连不上时其他源的配置仍然有效已下发的路由不受影响。数据面有本地缓存。xDS 推送到达后Envoy 持有完整的本地配置副本。即使控制面短暂重启或网络抖动存量流量按缓存配置继续转发恢复后增量变更再同步。配置变更是增量推送而非全量重载。这是 Higress 当年相对传统 Tengine reload 模式的关键改进——reload 会断开长连接xDS 增量更新不会。用户收益你不需要为控制面配置复杂的高可用容灾来保业务真正要保的是控制面的变更正确性改错路由比控制面宕机更常见。机制二重试与流量预算失败请求怎么处理问题后端偶发超时或连接失败是让用户直接看到 5xx还是悄悄重试一次关键组件Gateway API 的 HTTPRoute retry 配置由 pkg/ingress/kube/gateway/istio/conversion.go 转换成 Envoy 的重试策略。系统行为当你在 HTTPRoute 上配置 retry 时Higress 默认覆盖四类传输层错误connect-failure连接建立失败、refused-stream流被拒绝、unavailable、cancelled再叠加你自定义的 HTTP 状态码retryOn : []string{connect-failure, refused-stream, unavailable, cancelled}重试次数未显式指定时默认是2 次也可以配置 backoff重试间隔控制重试节奏。仅靠重试不够。故障实例在收到 5xx 的同时被重试持续命中可能雪上加霜。因此 Gateway API 的 backendTrafficPolicy 还支持RetryBudget重试预算实现在 pkg/ingress/kube/gateway/istio/backend_policies.go它限制允许走重试路径的流量占比和最小并发数相当于给重试流量加了一个总量闸防止故障扩散成整体过载。用户收益你可以把重试理解为对瞬时抖动免疫对持续故障止损。判断依据很简单——重试只应覆盖幂等接口GET、PUT 这类POST 类写接口开启重试前需先确认业务侧有幂等设计。机制三流量分割归一化与降级路由问题灰度比例写错了比如加起来 90% 或 110%会怎样主服务整体不可用时用户看到什么系统行为流量分割自动归一化。在 pkg/ingress/config/kingress_config.go 中多版本权重之和如果不是 100Higress 会按比例归一化并把剩余权重兜底到默认路由而不是直接报错丢弃整条路由。这意味着权重写错是降级配置而不是配置失败上线后实际比例可能和你的直觉有偏差验证时要以实际转发为准。负载均衡策略可路由级配置。通过load-balance注解可以指定轮询、最小连接、一致性哈希等算法还支持按 header、query 参数做会话保持upstream-hash-by、affinity系列注解解析逻辑在 pkg/ingress/kube/annotations/loadbalance.go。选择依据有状态会话用一致性哈希纯 CPU 密集型用最小连接默认场景轮询即可。Fallback 降级路由。Ingress 上配置default-backend注解指定兜底服务和custom-http-errors哪些状态码触发降级后主后端对指定错误码响应时请求会被自动改投到兜底服务。这是整个后端都不健康场景下保住用户体验的最后一层。用户收益三层机制叠加后故障从个别实例到整个后端都有对应的兜底路径你可以按故障范围选择开启哪一层不必全开。接入后优先检查的三处配置就绪探针。网关自身要能被 K8s 正确判定可用探针配置在 helm/core/templates/_pod.tpl 中路径是/healthz/ready15020 端口。如果集群反复重建网关 Pod先查这里periodSeconds太小会放大抖动误判failureThreshold太大会延迟摘除。重试与预算。确认 retry 只加在幂等路由上对写接口、AI 生成类非幂等且耗时长接口建议不开重试或只保留传输层默认项并配置 RetryBudget 限制重试流量占比。兜底后端。给关键路由配default-backend并明确custom-http-errors范围。一个常见误判是把 4xx 也加进降级条件——4xx 通常是请求本身的问题降级到备用服务只会换个地方再失败一次。如何确认流量切换生效变更后用带特征 header 的测试请求分别打到新旧版本核对响应里的实例标识确认比例与归一化后的预期一致。手动杀掉一个后端实例或把它权重调为 0观察请求是否在重试后落到健康实例若 5xx 比例没有收敛检查该集群是否配置了主动健康检查。触发主后端返回你配置的降级状态码确认 fallback 服务实际接到流量看兜底服务的访问日志而不是只看网关侧状态码。网关自身排障时先区分控制面没下发新配置未生效和数据面转发异常配置已生效但行为不符前者查 Controller 日志与 xDS 同步状态后者查 Envoy 的 admin 接口和访问日志。适用边界适合Kubernetes 环境内的多服务统一入口需要对接 Nacos 等非 K8s 注册中心的混合环境有灰度发布和 AI 流量治理需求plugins/wasm-go/extensions/下有ai-load-balancer、ai-cache、ai-quota等 WASM 插件可做模型级负载与 Token 限流。不适合或需注意非 K8s 单机场景下控制面组件较多运维成本要算进去重试和降级会改变请求的幂等假设金融、扣费类接口需逐一评估流量比例经过归一化后可能与字面配置不同验收必须基于实测流量而非配置值。常见误判把重试后成功率上升当成故障已恢复——它只说明瞬时抖动被吸收了根因如实例内存泄漏、依赖超时仍需单独排查。收尾一份可执行的检查清单控制面配置源是否至少覆盖一个主源外部注册中心故障时已有路由是否仍能工作幂等路由是否开启重试非幂等路由是否明确关闭关键路由是否配置了default-backend与合理的custom-http-errors就绪探针阈值是否与实际发布窗口匹配灰度比例是否做过实测流量核对而非只看配置如果你的环境正在从传统 reload 式网关迁移建议先用一条非核心路由完整跑通重试→健康检查摘除→fallback 降级这条链路再逐步扩大流量范围。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考