Higress：把模型服务接成一个稳定入口¶

假设公司有两套 vLLM，还接了一个外部模型 API。如果每个应用都分别处理地址、密钥、限流和故障重试，很快就会出现配置各不相同、模型切换困难的问题。

Higress 放在应用与这些服务之间，提供统一入口。应用请求一个约定的模型名，网关完成身份校验、路由和策略处理，再把请求转交给实际模型服务。vLLM 负责模型推理，Higress 负责请求怎样进入和到达服务。

先看请求经过谁¶

应用 / RAG / Agent
        ↓ HTTPS
外部负载均衡入口
        ↓
Higress Gateway 多副本
        ├─ vLLM 服务 A
        ├─ vLLM 服务 B
        └─ 外部模型 API

Console → 管理配置 → Controller → 向 Gateway 下发配置

Higress 基于 Envoy 和 Istio 相关技术构建，提供 Wasm 插件扩展；AI 场景可用模型代理、限流和观测等能力。具体能力由安装版本与插件决定，不能把商业版 SLA 当成自建开源环境的保证。官方介绍

组件	可以理解成	故障后的主要影响
Gateway 数据面	真正接收和转发请求的工作人员	该实例上的连接可能断开，其他健康副本承接新流量
Controller 控制面	把路由和服务变化通知网关的调度员	配置、服务发现变化可能无法及时下发
Console	管理界面	影响管理操作；正常业务请求不需要经过它
Kubernetes API 与配置存储	声明配置的来源	影响配置读取、控制器恢复和集群调度

“高性能”从哪里来¶

Envoy 的事件驱动网络处理与连接管理适合并发代理，动态配置可减少依赖整体重载带来的连接影响。但性能仍取决于 TLS、插件、请求大小、日志量、连接数及上游速度。

大模型调用中，模型可能生成几十秒；网关转发很快，不代表模型首 token 就会变快。要区分网关开销、模型排队和模型推理时间，单看整体响应时间容易判断错。

高可用要沿着整条链路看¶

入口：不能只把一个节点 IP 给应用¶

入口可以用具有冗余能力的云负载均衡，或自建的冗余负载均衡方案。它把新连接发到健康的网关实例。Kubernetes 的 Service type=LoadBalancer 还需要实际的负载均衡实现，声明一个 Service 不会凭空生成可用的外部设备。

DNS 指向多个地址也不等于快速、可靠的故障切换，缓存和客户端行为会影响恢复时间。

数据面：多副本，并且分散放置¶

至少保留两个 Gateway 副本，分布在不同节点；需要承受可用区故障时，再跨可用区布局。两个 Pod 落在同一台主机，仍会一起失效。

Readiness 决定实例是否接收新流量。滚动发布时要留出额外容量、配置连接排空与退出宽限期，并验证长连接行为。PDB 能限制部分主动驱逐，不防止机器突然断电，也不能替代 Deployment 的滚动升级策略。

控制面：已有配置与新增变化要分开看¶

健康 Gateway 在失去控制面连接后，通常还能用内存中最后生效的配置转发。但新路由、上游地址和证书更新可能停滞；如果此时网关也重启，还要看它能否重新获取配置。

Controller 应按版本支持配置多个副本并分散部署，同时保证 Kubernetes 控制面可用。验收时既要测试“现有请求还通不通”，也要测试“新配置是否能下发”。

上游：网关后面也要有路可走¶

两台网关都指向同一个 vLLM 单实例，上游故障后仍全部失败。同模型多副本可通过服务发现和负载均衡提供冗余；使用外部提供商时，还要考虑账号额度、区域和网络是否共用同一个故障点。

Fallback 是主模型失败后尝试预先配置的备用模型。它需要明确错误条件、超时、可接受的备用能力和总预算，不能仅配一个备用名称就认为已生效。官方多模型代理说明

AI 请求最容易踩的三个坑¶

流式回答中途断开。 SSE 已输出一部分内容后，不能把另一个模型的回答直接接在后面当成同一结果。应用需要显示中断、允许重新生成，或者实现自己的恢复协议。网关通常只能为之后的新请求选择健康实例。

重试放大故障。 模型响应慢时，网关、SDK 和应用各重试几次，会把原本拥塞的 GPU 压得更满。统一设置重试次数与总超时，只对合适的错误重试；已进入工具执行或产生业务副作用时，还要有幂等控制。

备用模型能力不同。 备用模型可能不支持图片、工具调用、同样的上下文长度或输出格式。上线前用真实业务验证，还要记录最终使用的模型和降级次数。

一套 Helm 部署的起点¶

以下命令用于已有测试集群，采用官方 Chart。生产应选择并固定测试过的版本；HIGRESS_CHART_VERSION 是需要先设置的版本变量。

helm repo add higress.io https://higress.io/helm-charts
helm repo update
helm search repo higress.io/higress --versions
helm show values higress.io/higress --version "$HIGRESS_CHART_VERSION"

先在 values-ha.yaml 写入副本数量：

higress-core:
  gateway:
    replicas: 2
    autoscaling:
      enabled: false
  controller:
    replicas: 2

helm template higress higress.io/higress \
  --namespace higress-system \
  --version "$HIGRESS_CHART_VERSION" -f values-ha.yaml

helm upgrade --install higress higress.io/higress \
  --namespace higress-system --create-namespace \
  --version "$HIGRESS_CHART_VERSION" -f values-ha.yaml

这只是副本配置起点。按选定 Chart 补上反亲和或拓扑分布、资源、升级和退出策略；检查渲染出的 Deployment，确认键名生效。副本数和 HPA 同时配置时，应以实际控制副本数的机制为准。参数参考官方运维配置，安装流程见快速开始。

验证组件和请求路径¶

kubectl -n higress-system get deploy,pods,svc -o wide
kubectl -n higress-system get endpointslices
kubectl -n higress-system get events --sort-by=.lastTimestamp

先配置一个普通测试服务，验证入口、域名和路由，再接入模型服务。AI 路由中明确对外模型名、真实上游、认证以及允许的消费者；接入备用服务后，单独验证失败条件确实触发 Fallback。管理控制台无需暴露为公共业务入口。

怎样做一次有价值的故障演练¶

在测试环境持续发送普通请求和流式请求，每次只改变一个故障条件，记录错误率和恢复时间。

模拟情况	应该观察到什么
一个 Gateway 退出	新请求转向健康副本；该实例上的流可能中断
一台工作节点故障	其他节点仍有网关，入口能剔除失效路径，剩余容量够用
Controller 不可用	已生效路由继续工作的范围，以及配置更新何时恢复
一个模型副本不可用	请求避开故障副本，重试没有形成请求洪峰
主模型提供商超时/限流	按配置触发备用策略，格式和能力仍符合业务要求
滚动升级	新实例就绪后接流，旧实例排空，长流中断率在可接受范围

关注 Gateway 就绪副本、连接数、内存、5xx、上游超时，以及模型 TTFT、token 消耗、限流次数和 Fallback 次数。CPU 不高时也可能因为大量长连接或上游排队而过载，HPA 不能只靠一个 CPU 指标解决所有场景。

理解 Higress 高可用时，我会把入口、网关、配置下发和模型服务逐层走一遍，再用业务请求验证。副本数量只是其中一个条件。