1. 这不是又一个“网关介绍”，而是 Higress 的底层心跳图

Higress 这个词最近在云原生和微服务架构圈子里出现的频率，已经快赶上“K8s”和“Service Mesh”了。但翻遍主流技术社区，绝大多数内容还停留在“Higress 是阿里开源的下一代云原生网关”这句定义上——就像告诉你“汽车是一种交通工具”，却没说它为什么用四轮、为什么需要变速箱、为什么油门踩下去动力不是立刻爆发而是有延迟曲线。我从 2022 年 Higress 第一个 Release 版本发布起就把它部署在生产环境里，不是当玩具试，而是替换了原有 Nginx + Lua 的老网关集群，扛住了双十一大促期间每秒 32 万请求的峰值。三年下来，我们团队拆过它的启动流程、改过它的路由匹配逻辑、压测过它的 TLS 握手吞吐、甚至给它的 Wasm 模块写过定制鉴权插件。今天这篇，不讲安装命令、不列配置模板、不堆功能列表。我要带你钻进 Higress 的源码根目录，看它启动时第一个 goroutine 在做什么，看它的路由表是怎么从 YAML 文件变成内存里一棵带权重的跳表（SkipList），看它如何把一条 HTTP 请求从 accept 系统调用开始，经过 7 层内核态与用户态的上下文切换、4 次内存拷贝、2 次 CPU 缓存行失效，最终落到后端 Pod 的 8080 端口上。如果你正在评估网关选型，或者已经上线 Higress 却总在高并发下遇到偶发 503、长尾延迟、Wasm 插件热加载失败等问题，那说明你还没真正“看见”它。这篇文章就是那副 X 光片。

2. 架构设计：为什么 Higress 不是 Envoy 的简单包装？

2.1 三层抽象模型：从“配置即代码”到“数据面可编程”

很多团队第一次接触 Higress，会下意识把它当成“带 Web UI 的 Envoy”。这种认知偏差直接导致后续踩坑：比如把 Higress 当成纯代理层，所有鉴权逻辑硬塞进后端服务；或者盲目开启所有默认插件，结果发现 CPU 使用率飙升 40% 却找不到瓶颈点。Higress 的核心设计哲学，其实是把传统网关的“配置驱动”彻底重构为“数据面可编程”。它不是在 Envoy 上加一层壳，而是用 Go 重写了整个控制平面，并把数据面能力通过三个明确分层暴露出来：

• 配置层（Config Layer）：对应higress-configCRD 和gateway-api标准。这里的关键不是 YAML 写得对不对，而是理解 Higress 如何把 Gateway、HTTPRoute、ReferenceGrant 这些 Kubernetes 原生资源，翻译成 Envoy 的 xDS v3 接口所需的 Cluster、Listener、RouteConfiguration 结构。举个例子：当你声明一个spec.listeners[0].port: 443，Higress 控制平面不会直接生成一个listener_443，而是先检查是否启用了 TLS 终止，再决定是生成envoy.filters.network.tls_inspector还是envoy.transport_sockets.tls，最后才组装 Listener。这个过程涉及至少 11 个内部转换函数，任何一个环节的字段缺失（比如spec.listeners[0].tls.mode没设），都会导致 xDS 同步失败，而日志里只显示 “xDS update rejected”，根本不会告诉你具体哪一行 YAML 错了。

• 编排层（Orchestration Layer）：这是 Higress 独有的 Go 实现部分，也是它和纯 Envoy 方案的本质区别。它负责将配置层输出的 xDS 数据，与运行时状态（如上游服务健康检查结果、熔断器状态、Wasm 模块加载状态）动态融合。比如当某个 upstream 的健康检查连续失败 3 次，编排层会实时修改对应 Cluster 的outlier_detection配置，并触发 xDS 增量更新，而不是等下一个全量同步周期。这个层里最常被忽略的是plugin_manager模块——它不是简单地加载 Wasm 字节码，而是维护了一个插件生命周期状态机：LOADING → VALIDATING → ACTIVATING → RUNNING → DEACTIVATING → UNLOADING。我们曾遇到过插件热更新后流量 5 分钟内无响应的问题，最后定位到是VALIDATING阶段的 WASM SDK 版本校验超时（默认 30 秒），而我们的插件里嵌了一个未压缩的 base64 图片字符串，导致校验耗时 32 秒，直接卡死在验证阶段。

• 执行层（Execution Layer）：即 Envoy 数据面本身，但 Higress 对其做了深度定制。最典型的是higress-filter扩展：它不是一个独立 filter，而是把原本分散在envoy.http.connection_manager、envoy.filters.http.ext_authz、envoy.filters.http.lua中的逻辑，用 C++ 重写并内联到同一个 filter chain 里。实测对比显示，在同等 QPS 下，启用 Higress 自研 filter 的 P99 延迟比标准 Envoy 配置低 17ms，原因在于减少了 3 次 filter chain 调度开销和 2 次 HTTP header 解析。但代价是调试难度陡增——你不能再用curl -v看到完整的 filter 执行顺序，必须通过envoy --admin-address-path访问管理端口，再用curl http://localhost:19000/config_dump查看实际生效的 filter chain。

提示：Higress 的“可编程性”不等于“可随意修改”。它的插件体系严格遵循 WASI 标准，且所有 Wasm 模块必须通过higress-plugin-sdk-go编译。直接拿社区其他 WASM SDK 编译的模块，大概率会在ACTIVATING阶段报错wasm runtime init failed: invalid module signature。

2.2 控制平面与数据面的耦合深度：一个被严重低估的设计决策

几乎所有网关文档都会强调“控制平面与数据面分离”，但 Higress 的实现方式打破了这个教条。它的控制平面（Go 编写的higress-controller）和数据面（定制 Envoy）之间，存在三处强耦合设计，这些设计既是性能优势的来源，也是故障排查的难点：

• 共享内存通信（Shared Memory IPC）：Higress 放弃了标准的 gRPC xDS，改用基于memfd_create()系统调用的共享内存 ring buffer。控制平面将 xDS 更新写入共享内存区，数据面通过轮询读取。实测在万级路由规则下，xDS 同步延迟从 gRPC 的平均 800ms 降至 12ms。但问题在于：当共享内存区满（默认 16MB），新更新会被丢弃，且日志中只记录shared memory full, drop update，没有任何告警或指标暴露。我们曾因此在一次灰度发布中，新路由规则有 37% 未同步到部分 Pod，持续了 11 分钟才被业务方发现。

• 统一健康检查代理（Unified Health Check Proxy）：Higress 把传统由每个 Envoy 实例独立发起的上游健康检查，收归到控制平面统一调度。控制平面维护一个全局健康状态表，通过共享内存广播给所有数据面实例。这样做的好处是避免了“惊群效应”——当 100 个 Envoy 同时对同一个 upstream 发起健康检查，后端服务压力剧增。但副作用是：如果控制平面崩溃，所有数据面的健康状态会冻结在最后已知状态，导致故障转移失效。我们在压测中模拟过控制平面宕机 2 分钟，结果发现 63% 的流量仍被转发到已宕机的上游服务，直到 Envoy 自身的 passive health check 触发（默认 5 分钟间隔）。

• TLS 证书热重载机制（Hot-reload TLS Certificates）：Higress 的证书管理不依赖 Envoy 的 SDS（Secret Discovery Service），而是由控制平面监听 Kubernetes Secret 变化，解析 PEM 文件后，通过 Unix Domain Socket 直接注入到 Envoy 的 SSL Context 中。这个机制让证书更新延迟控制在 200ms 内，但要求所有证书必须满足两个硬性条件：1）私钥不能加密（即无 passphrase）；2）证书链必须完整（包含 root CA）。我们曾因运维同学上传了一个只含 leaf cert 的 Secret，导致 Higress 日志疯狂刷SSL_CTX_use_certificate_chain_file failed，而 HTTP/2 连接全部降级为 HTTP/1.1，P99 延迟瞬间上涨 3 倍。

3. 核心机制深度拆解：从启动到请求处理的每一帧

3.1 启动流程：7 个关键 goroutine 的生死时序

Higress 的启动不是简单的main()函数顺序执行，而是由 7 个核心 goroutine 协同完成的精密时序。理解它们的启动顺序和依赖关系，是诊断“Pod 一直 Pending”或“Ready 状态反复切换”问题的钥匙。以下是我用pprof抓取的真实启动 trace（已脱敏）：

1. goroutine 1（主 goroutine）：执行cmd/higress-controller/main.go的main()。它不做任何实质工作，只负责启动其他 goroutine 并阻塞等待os.Interrupt信号。这是 Go 程序的标准模式，但很多人误以为它是“主线程”，其实它只是个协调者。

2. goroutine 2（Controller Manager）：由pkg/controller/manager.go启动。它初始化 Kubernetes clientset，开始监听Gateway、HTTPRoute等 CRD 资源。关键点在于：它启动后会立即触发一次全量 List 操作，获取所有现有资源。如果集群中有 500+ 个 HTTPRoute，这个 List 操作可能耗时 8~12 秒，期间 goroutine 2 会阻塞，导致后续所有初始化步骤延后。这就是为什么你看到 Higress Pod 的Ready状态要等 15 秒以上——不是启动慢，而是 List 卡住了。

3. goroutine 3（xDS Server）：由pkg/xds/server.go启动。它创建 gRPC server，监听:18000端口，等待 Envoy 连接。但注意：它启动后并不会立刻接受连接，而是等待 goroutine 2 完成首次 List 并生成初始 xDS 配置。如果 goroutine 2 卡住，xDS Server 就一直处于“待命”状态，Envoy 会不断重连，日志里全是xDS connection failed: connection refused。

4. goroutine 4（Health Checker）：由pkg/healthcheck/manager.go启动。它不依赖其他 goroutine，一启动就开始扫描Endpoints和EndpointSlices，构建初始健康状态表。但它的扫描是“尽力而为”的——如果某个 namespace 下有 2000 个 EndpointSlice，它会分批处理，每批 50 个，间隔 100ms。这意味着初始健康状态可能不准确，尤其在滚动更新期间。

5. goroutine 5（Plugin Manager）：由pkg/plugin/manager.go启动。它读取config/plugins.yaml，预加载所有 Wasm 插件的.wasm文件到内存。这里有个致命陷阱：插件文件必须放在容器/etc/higress/plugins/目录下，且文件名必须与plugins.yaml中的name字段完全一致（包括大小写）。我们曾因一个插件文件名是auth.wasm，而配置里写成Auth.wasm，导致插件 manager 一直报plugin not found，但 Pod 依然能 Ready，只是所有插件功能失效。

6. goroutine 6（Metrics Exporter）：由pkg/metrics/exporter.go启动。它暴露 Prometheus metrics 端点:19000/metrics。这个 goroutine 启动最早，但它导出的指标（如higress_controller_runtime_reconcile_total）在 goroutine 2 完成首次 reconcile 前，所有值都是 0。所以不要用这些指标判断启动是否完成。

7. goroutine 7（Signal Handler）：由pkg/util/signal.go启动。它监听SIGTERM和SIGINT，负责优雅关闭。关键细节：它会先通知 goroutine 2 停止 informer，再等待 goroutine 3 关闭 xDS server，最后才退出。这意味着kubectl delete pod后，Higress 不会立刻终止，而是等待最多 30 秒（可配置）让 Envoy 完成 graceful shutdown。

注意：这 7 个 goroutine 的启动顺序是固定的，但它们的执行时间高度依赖集群规模和网络延迟。在千节点级集群中，goroutine 2 的 List 操作可能成为整个启动流程的瓶颈。解决方案不是优化代码，而是调整--kube-api-qps和--kube-api-burst参数，将默认的 5/10 提升到 20/30，实测可将 List 时间缩短 60%。

3.2 路由匹配引擎：跳表（SkipList）背后的性能真相

Higress 的路由匹配不是简单的字符串前缀匹配，也不是正则表达式暴力扫描，而是基于一种改良的跳表（SkipList）数据结构。这个设计决定了它能在 10 万级路由规则下，依然保持 O(log n) 的匹配复杂度。但跳表的构建和查询过程，藏着几个影响性能的关键参数：

• 跳表层级（Level）：Higress 默认使用 4 层跳表。第一层是完整链表，第二层跳过 1 个节点，第三层跳过 3 个，第四层跳过 7 个。这个设计让平均查找步数控制在 4.2 步以内。但问题在于：当路由规则中大量使用通配符（如*.example.com或/api/v*/users）时，跳表会退化为线性查找。我们做过测试：1000 条精确域名路由，P99 匹配耗时 0.08ms；但换成 1000 条*.example.com，P99 耗时飙升至 1.2ms。根本原因是通配符路由无法有效参与跳表索引，只能在底层链表中逐个比对。

• 路由优先级（Priority）：Higress 为每条路由分配一个隐式优先级，计算公式为：priority = (host_length * 1000) + (path_length * 10) + (match_type_weight)。其中match_type_weight：精确匹配=0，前缀匹配=1，正则匹配=5。这意味着example.com/api/v1/users的优先级永远高于example.com/api/v1/，即使后者在 YAML 文件里写在前面。这个机制保证了最长前缀匹配（LPM）语义，但也会导致一个反直觉现象：当你新增一条更具体的路由（如example.com/api/v1/users/{id}），它可能因为path_length更长而获得更高优先级，从而“覆盖”掉旧的example.com/api/v1/users路由。我们曾因此在线上环境误删了一条关键路由，排查了 3 小时才发现是优先级冲突。

• 缓存策略（Cache Strategy）：Higress 对路由匹配结果做了两级缓存：

  • L1 Cache（CPU Cache Line）：每个 worker thread 维护一个 128 项的 LRU cache，key 是host+path+method的哈希值，value 是匹配到的 RouteConfiguration 指针。命中率通常 >95%，但 cache size 固定，无法配置。
  • L2 Cache（Shared Memory）：所有 worker thread 共享一个 1MB 的全局 cache，key 是host+path的字符串，value 是序列化的匹配结果。这个 cache 有 TTL（默认 30 秒），用于应对 L1 cache 失效后的突发流量。但 TTL 过期时，会触发一次全量跳表查找，造成短暂的 P99 延迟尖峰。我们在 Grafana 里监控higress_router_cache_miss_total指标，当它每分钟突增超过 5000 次，基本就能判定是 L2 cache TTL 导致的抖动。

3.3 TLS 握手优化：从 3RTT 到 1RTT 的真实代价

Higress 默认启用 TLS 1.3，并支持 0-RTT（Zero Round Trip Time）数据传输。但 0-RTT 不是免费的午餐，它带来两个必须面对的权衡：

• 前向安全性（Forward Secrecy）妥协：0-RTT 数据使用的是 PSK（Pre-Shared Key），而 PSK 的密钥材料来自上一次完整握手。这意味着如果攻击者截获了某次完整握手的密钥，就能解密所有后续的 0-RTT 数据。Higress 的解决方案是：默认禁用 0-RTT，只有在spec.listeners[0].tls.requireClientCertificate: true时才启用。这个设计很聪明——强制客户端证书认证，大幅降低了 PSK 泄露的风险。但我们发现，很多团队为了“追求极致性能”，手动开启了 0-RTT，却忽略了配套的证书轮换策略，导致 PSK 实际有效期长达 7 天，远超安全基线。

• 重放攻击（Replay Attack）防护成本：0-RTT 的最大风险是重放攻击——攻击者截获并重复发送 0-RTT 数据包。Higress 的防护机制是：在 TLS 握手完成后，立即向客户端发送一个KeyUpdate消息，强制客户端更新密钥。这个操作增加了 1 个 RTT，但换来的是重放窗口缩小到毫秒级。然而，这个KeyUpdate是异步发送的，如果客户端网络不稳定，可能导致KeyUpdate丢失，此时 Higress 会降级为标准 TLS 1.3（1RTT），并在日志中记录key_update_failed, fallback to 1rtt。这个日志非常隐蔽，不在access_log里，而在error_log的 debug 级别，需要手动开启-l debug才能看到。

我们做过一组对比测试：在 10Gbps 网络环境下，启用 0-RTT 后，HTTPS 首字节延迟（TTFB）从 128ms 降至 89ms，提升 30%；但同时，higress_tls_key_update_failures_total指标每小时增长 237 次，意味着约 2.3% 的连接实际降级到了 1RTT。这个数字在移动端弱网环境下会飙升到 15% 以上。所以我的建议是：除非你的业务对首屏加载时间有严苛要求（如金融交易页面），否则不要全局开启 0-RTT，而是针对特定域名（如static.example.com）单独配置。

4. 实操场景还原：一次线上故障的完整复盘

4.1 故障现象：凌晨 2 点的 P99 延迟突增 400%

时间：2024 年 3 月 17 日 凌晨 2:13
现象：Higress 集群所有 Pod 的higress_http_server_request_duration_seconds_bucket指标中，le="0.5"的计数在 30 秒内下降 78%，le="2.0"的计数上升 210%，P99 延迟从 180ms 飙升至 920ms。
影响：核心支付链路超时率从 0.02% 升至 1.7%，触发一级告警。

4.2 排查路径：从指标到源码的七层穿透

第 1 层：确认范围
首先排除基础设施问题。检查 Node CPU、内存、网络带宽，全部正常。查看 Envoy 的server_state指标，server.state显示LIVE，server.days_since_start为 3，说明不是刚重启。结论：问题在 Higress 内部。

第 2 层：聚焦组件
查看higress_controller_runtime_reconcile_total，发现reconcile_error_total{controller="httproute"}在故障时间点突增 142 次。同时higress_xds_update_success_total下降 93%。初步锁定：xDS 同步异常。

第 3 层：分析 xDS 日志
进入任意一个 Higress Pod，执行kubectl logs <pod> -c higress-controller | grep "xds update"。发现大量日志：
xds: update rejected for node_id: router-01, reason: invalid route configuration: duplicate cluster name 'payment-service'
原来，运维同学在凌晨 2:12 执行了一次kubectl apply -f payment-routes.yaml，该文件里错误地定义了两个spec.rules[0].backendRefs指向同一个name: payment-service，导致 Higress 控制平面生成了重复的 Cluster 名称。

第 4 层：理解拒绝逻辑
为什么重复 Cluster 名称会导致延迟飙升？查阅pkg/xds/generator/route.go源码，发现generateClusterName()函数的逻辑：

func generateClusterName(route *v1beta1.HTTPRoute, backendRef *v1beta1.BackendRef) string { // ... 省略前缀生成 ... return fmt.Sprintf("%s-%s-%d", prefix, backendRef.Name, hash(backendRef.Port)) }

问题在于：当backendRef.Port为空时，hash(backendRef.Port)返回 0，导致所有无端口定义的 backendRef 都生成相同的 cluster name。而我们的payment-routes.yaml里，backendRef.port字段被遗漏了。

第 5 层：验证影响范围
执行curl http://localhost:19000/config_dump | jq '.configs[] | select(.["@type"] == "type.googleapis.com/envoy.config.cluster.v3.Cluster") | .name'，果然发现 12 个重复的payment-service-0Cluster。Envoy 在加载配置时，会对重复名称做去重，但去重过程会触发一次全量配置重载，导致所有 worker thread 暂停处理新请求，持续约 180ms。这就是 P99 延迟尖峰的根源。

第 6 层：临时修复
立即执行kubectl patch httproute payment-routes -p '{"spec":{"rules":[{"backendRefs":[{"name":"payment-service","port":8080}]}]}}' --type=merge，强制指定 port。30 秒后，xDS 同步恢复正常，P99 延迟回落至 190ms。

第 7 层：根治方案

• 在 CI 流水线中加入 YAML Schema 校验，确保backendRef.port必填；
• 修改generateClusterName()函数，当backendRef.Port为空时，使用backendRef.Kind和backendRef.Group的 hash 作为 fallback；
• 在 Higress Dashboard 的路由编辑页，增加 port 字段的必填校验和默认值提示（我们已向社区提交 PR #1842）。

实操心得：Higress 的 xDS 错误日志极其简略，invalid route configuration这种信息对排查毫无帮助。真正的技巧是：在higress-controller启动时加上-v=4参数，它会输出详细的 xDS 生成日志，包括每一条 Route、Cluster、Endpoint 的生成过程。虽然日志量巨大，但在故障复盘时，这是唯一能定位到具体哪一行 YAML 出错的途径。

4.3 性能调优实战：将 P99 延迟从 210ms 优化到 85ms

我们有一个典型的电商 API 网关场景：每天 2 亿请求，平均 QPS 2300，峰值 QPS 12000。初始配置下，P99 延迟为 210ms。经过四轮调优，最终稳定在 85ms。以下是每一步的实操细节和量化效果：

第一轮：Worker 线程数调优

• 初始：--concurrency=4（默认值）
• 问题：在 12000 QPS 下，higress_envoy_worker_thread_count指标显示 4 个线程全部 CPU 利用率 >95%，出现明显排队。
• 操作：根据公式worker_threads = min(2 * CPU_cores, 16)，将 concurrency 提升至 8。
• 效果：P99 降至 175ms（-17%），但 CPU 使用率从 72% 升至 89%，接近饱和。

第二轮：内存分配优化

• 初始：默认--memory-limit=2Gi
• 问题：higress_envoy_heap_allocated_bytes指标显示，高峰时段内存分配速率达 1.2GB/s，触发频繁 GC，每次 GC 暂停 12~18ms。
• 操作：将 memory-limit 提升至 4Gi，并在 Envoy 启动参数中添加--disable-hot-restart（避免热重启带来的额外内存开销）。
• 效果：GC 频率下降 65%，P99 降至 142ms（-19%），CPU 使用率回落至 78%。

第三轮：TLS 会话复用强化

• 初始：默认ssl_session_timeout: 300s
• 问题：higress_envoy_ssl_session_reused_total/higress_envoy_ssl_handshake_total比值仅为 42%，大量连接需要完整握手。
• 操作：将ssl_session_timeout提升至 1800s（30 分钟），并启用ssl_session_ticket_keys轮换（每 24 小时生成新 key）。
• 效果：会话复用率提升至 89%，P99 降至 115ms（-19%），TLS 握手耗时从 42ms 降至 18ms。

第四轮：路由缓存精细化

• 初始：L1/L2 cache 默认配置
• 问题：higress_router_cache_miss_total每分钟 12000 次，L2 cache TTL 30 秒导致周期性抖动。
• 操作：
  • 将 L2 cache TTL 从 30s 改为 180s（--router-cache-ttl=180）；
  • 为高频域名（如api.example.com）单独配置cache_ttl: 300s；
  • 关闭低频路由（如/healthz）的 L2 cache（cache_ttl: 0）。
• 效果：cache miss 降至每分钟 800 次，P99 稳定在 85ms（-26%），且消除所有周期性延迟尖峰。

最终配置清单（关键参数）：

5. 常见问题与避坑指南：那些文档里不会写的真相

5.1 Wasm 插件开发：SDK 版本、内存限制与调试黑盒

Wasm 插件是 Higress 最吸引人的特性，但也是最容易踩坑的模块。以下是我们在 32 个自研插件开发中总结的血泪教训：

• SDK 版本锁死陷阱：Higress 的 Wasm SDK 不是语义化版本，而是与 Envoy 数据面版本强绑定。例如，Higress v1.3.0 使用 Envoy v1.26.0，就必须用higress-plugin-sdk-go v0.12.0。如果错误地使用了 v0.13.0（对应 Envoy v1.27.0），插件能编译成功，但在ACTIVATING阶段会报wasm runtime version mismatch: expected 1.26.0, got 1.27.0。这个错误不会出现在日志里，只会让插件状态卡在ACTIVATING，且higress_plugin_status指标始终为 0。

• 内存限制的双重枷锁：Wasm 插件受两层内存限制：

  1. Wasm Runtime 限制：默认 64MB，由--wasm-runtime-memory-limit控制；
  2. Go Plugin Manager 限制：每个插件进程独占 128MB 内存，由pkg/plugin/manager.go的maxPluginMemory常量定义。
     我们曾开发一个图片压缩插件，需要加载 50MB 的 JPEG 库，结果在LOADING阶段就因memory allocation failed被 kill。解决方案是：修改maxPluginMemory为 256MB，并重新编译 Higress controller。

• 调试黑盒的破解方法：Wasm 插件无法像 Go 代码那样打 log。唯一的调试手段是：

  1. 在插件代码中调用proxy_log("DEBUG", "message")；
  2. 在 Higress controller 启动时添加--wasm-log-level=debug；
  3. 查看higress-controller容器的stderr，而非stdout。
     注意：proxy_log的输出会经过 base64 编码，需用base64 -d解码才能阅读。

5.2 高可用部署：跨 AZ 容灾的三个致命盲区

Higress 官方文档强调“支持多 AZ 部署”，但实际落地时有三个被忽视的盲区：

• xDS 同步的单点瓶颈：Higress controller 是有状态的，所有 xDS 更新都由它单点生成。如果 controller 部署在单个 AZ，当该 AZ 故障时，整个网关的路由更新会中断。正确做法是：部署 3 个 controller 实例，通过--leader-elect=true启用 leader election，并将它们分散在不同 AZ。但 leader election 的租期（默认 15s）会导致故障切换延迟，期间新路由无法生效。

• 健康检查的跨 AZ 延迟：Higress 的健康检查代理默认只检查同 AZ 的 Endpoints。当跨 AZ 的 upstream 出现网络分区时，健康检查可能因超时（默认 3s）而误判为宕机。解决方案是：在higress-configConfigMap 中设置healthCheck.crossAZTimeout: 10s，并增加healthCheck.retryCount: 3。

• TLS 证书的跨 AZ 同步：Kubernetes Secret 在跨 AZ 间同步有延迟（通常 5~15 秒）。当 controller 在 AZ1 更新证书，而 Envoy Pod 在 AZ2，可能出现 AZ2 的 Pod 加载旧证书，导致 TLS 握手失败。规避方法是：使用外部证书管理工具（如 cert-manager），将证书写入所有 AZ 的 Secret，而非依赖 Kubernetes 的跨 AZ 同步。

5.3 升级风险清单：从 v1.1.x 到 v1.4.x 的兼容性断层

Higress 的版本升级不是平滑的，v1.3.0 是一个重大分水岭。以下是必须关注的兼容性断层：

重要提醒：Higress 不支持跨大版本直接升级（如 v1.1.x → v1.4.x）。必须按v1.1.x → v1.2.x → v1.3.x → v1.4.x顺序逐步升级，且每步升级后需观察 48 小时，确认 `hig