拓冰网站定制 
Envoy Composite Cluster 一次搞懂用重试次数锁定上游集群的完整指南【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy凌晨两点AI Gateway 的首选模型提供商宕了重试却还在朝同一个死掉的集群撞——这种“撞南墙”式重试正是Envoy Composite Cluster要解决的问题。它把重试尝试次数attempt count变成路由依据首请求走首选集群、第一次重试走备用集群、第二次重试走兜底集群一次搞定 Envoy 多集群故障切换配置。读完这篇文章你会拿到四样东西它和 Aggregate Cluster 的本质区别、一段 10 行 YAML 就能落地的最小配置、attempt 到集群下标的映射机制以及上线前的自查清单。和 Aggregate Cluster 到底差在哪先给一句话概念。Aggregate Cluster 把多个集群聚合成一个顶层按各子集群的健康状态分流——健康主机多的子集群自然分走更多流量。Composite Cluster扩展名envoy.clusters.composite则完全不按健康比例做顶层分流它只看一件事当前请求是第几次尝试。维度Aggregate ClusterComposite Cluster顶层决策输入子集群健康状态占比请求的尝试次数典型用途按可用性自动分流、故障切换重试演进路由retry progression可预测性随健康状态波动同一次尝试恒定命中同一集群尝试次数超出集群数仍按健康状态落点直接以“无可用主机”失败一句话类比Aggregate 像餐厅领位员哪个档口人少就把客人带去哪Composite 像医院分诊台只看“你是第几号”——一号看普通门诊复诊号直接转专家跟哪个科室排队短没关系。它的典型战场有三类AI Gateway 上游切换首请求打首选模型/供应商重试时切到备用供应商成本分级路由先打昂贵但快的服务失败后降级到便宜的替代普通的重试演进primary → secondary → tertiary 逐级降级。最快上手ClusterConfig 三步配好配置只需要一个消息ClusterConfig它的全部字段就是子集群名称列表。落地分三件事① 子集群先在配置里各自独立定义好——端点、健康检查、负载均衡算法都归它们自己管Composite 只引用名字 ② 新建一个集群lb_policy设为CLUSTER_PROVIDEDcluster_type指向envoy.clusters.composite ③ 在clusters列表里按“希望被尝试的先后顺序”写下集群名。name: my_ai_cluster lb_policy: CLUSTER_PROVIDED cluster_type: name: envoy.clusters.composite typed_config: type: type.googleapis.com/envoy.extensions.clusters.composite.v3.ClusterConfig clusters: - name: provider_a - name: provider_b - name: provider_c铁律列表顺序 尝试次序。按上面这份配置运行时语义是初始请求attempt 1→provider_a第一次重试attempt 2→provider_b第二次重试attempt 3→provider_c第四次尝试attempt 4 起→ 下标越界请求直接失败列表不能为空、名字不能是空串这些校验规则min_items: 1、min_len: 1定义在 api/envoy/extensions/clusters/composite/v3/cluster.proto 里配置加载阶段就会拦下错误不用等到运行时。内部如何按重试次数选集群你可以把它想象成机场备降指挥空管不关心哪趟航班人多只看你是“第几架”——第一架降 A 场第二架降 B 场第三架降 C 场第四架对不起本场没有可用跑道直接拒绝。内部流程比这更简单。它会先从请求上下文里读出当前的 attempt countEnvoy 的尝试次数从 1 开始计数如果上下文缺失或读出来是 0视为异常状态打一条 warn 日志并放弃选择。然后做最核心的一步减法下标 attempt count − 1。算出的下标落在列表长度内就锁定该位置的子集群超出列表长度重试次数多于集群数则本次尝试直接失败报“无可用主机”不会绕圈去试别的集群。锁定子集群之后Composite 自己不碰任何 host。挑具体哪台机器完全委托给子集群自带的负载均衡算法round robin、maglev 都可以。也就是说Composite 负责“进哪个门”子集群负责“门内坐哪桌”。这条选择路径还有一个性能设计值得知道它发生在每个 worker 线程本地的负载均衡器里thread-local clustering选集群时没有跨线程加锁开销子集群的增删变更通过更新回调同步到各个线程选择路径始终读的是本线程的快照。每个子集群也保持独立自己的健康检查、outlier detection 各管各的Composite 不掺和。子集群没有可用主机时会发生什么这是最容易被误解的行为。如果某次 attempt 映射到的子集群一台可用主机都拿不出来——比如 DNS 解析失败导致端点列表为空或 outlier detection 把主机全部逐出——默认情况下它不会立刻判死刑而是在同一次尝试内顺着列表往后逐个试直到某个集群交出主机如果后面全都拿不出主机请求才以no_healthy_upstream503失败。打个比方这就像 UPS 备用电源主电源断了先切第一块电池第一块也亏电就切第二块全程对用电设备无感而且切电池不会改变设备“应该由哪一路供电”的编号。两个细节要留意异步选择不被打断如果某个子集群返回的是“异步主机选择正在进行”例如异步 DNS 还没回来选择流程会立刻交棒给那个异步流程不再尝试列表里其他集群。runtime 开关上述无主机 failover 行为由envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts控制默认开启。置为false会退回旧行为——映射到的子集群无主机时立即失败不做同尝试内兜底。这个开关正是早期版本“子集群恰好没主机就误报 503”缺陷修复后留下的逃生舱。重试策略如何与集群数对齐Composite 不会替你触发重试路由层必须配一条配套的重试策略公式很简单子集群数 num_retries 1。retry_policy: retry_on: 5xx,connect-failure,refused-stream num_retries: 2 # 1 次初始 2 次重试 共 3 次尝试配num_retries: 2恰好覆盖三个子集群。两类错配的后果都很难看配多了超出的尝试下标越界请求直接失败——白烧重试预算换来的必然是一次失败响应配少了排在后面的子集群永远拿不到流量白配。还有一个容易被忽略的点failover 不移动后续尝试的映射。因为下标只由 attempt count 决定某次尝试向后兜底并不会“推动”后面的尝试。举例列表是[provider_a, provider_b, provider_c]若provider_a为空attempt 1 会落到provider_b但 attempt 2 依然映射到provider_b而不是provider_c。设计重试规模时要把这种重叠算进去。上线前检查清单 发版前逐条过一遍能省掉大量线上排障时间lb_policy已设为CLUSTER_PROVIDED——Composite 自身不承载任何 host每个子集群都在配置其他位置独立定义健康检查与负载均衡各自配齐num_retries 1恰好等于clusters列表长度理解 failover 语义同尝试内向后兜底不改变后续 attempt 的映射确认 runtime 开关...composite_cluster_skip_clusters_without_hosts的取值符合预期默认开启验证入口建议留两个一是用 admin 的/config_dump与/clusters确认集群列表与顺序已正确下发后者能直接看到各子集群端点与健康状态二是跑一遍仓库自带的测试单元测试cluster_test.cc覆盖了 attempt 提取、下标映射与 failover 边界集成测试cluster_integration_test.cc用多个 fake upstream 端到端验证空端点场景位置在 test/extensions/clusters/composite/。延伸阅读官方架构文档 composite_cluster.rst 里有完整的字段说明与 Aggregate 对比表。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Envoy Composite Cluster 一次搞懂：用重试次数锁定上游集群的完整指南
Envoy Composite Cluster 一次搞懂用重试次数锁定上游集群的完整指南【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy凌晨两点AI Gateway 的首选模型提供商宕了重试却还在朝同一个死掉的集群撞——这种“撞南墙”式重试正是Envoy Composite Cluster要解决的问题。它把重试尝试次数attempt count变成路由依据首请求走首选集群、第一次重试走备用集群、第二次重试走兜底集群一次搞定 Envoy 多集群故障切换配置。读完这篇文章你会拿到四样东西它和 Aggregate Cluster 的本质区别、一段 10 行 YAML 就能落地的最小配置、attempt 到集群下标的映射机制以及上线前的自查清单。和 Aggregate Cluster 到底差在哪先给一句话概念。Aggregate Cluster 把多个集群聚合成一个顶层按各子集群的健康状态分流——健康主机多的子集群自然分走更多流量。Composite Cluster扩展名envoy.clusters.composite则完全不按健康比例做顶层分流它只看一件事当前请求是第几次尝试。维度Aggregate ClusterComposite Cluster顶层决策输入子集群健康状态占比请求的尝试次数典型用途按可用性自动分流、故障切换重试演进路由retry progression可预测性随健康状态波动同一次尝试恒定命中同一集群尝试次数超出集群数仍按健康状态落点直接以“无可用主机”失败一句话类比Aggregate 像餐厅领位员哪个档口人少就把客人带去哪Composite 像医院分诊台只看“你是第几号”——一号看普通门诊复诊号直接转专家跟哪个科室排队短没关系。它的典型战场有三类AI Gateway 上游切换首请求打首选模型/供应商重试时切到备用供应商成本分级路由先打昂贵但快的服务失败后降级到便宜的替代普通的重试演进primary → secondary → tertiary 逐级降级。最快上手ClusterConfig 三步配好配置只需要一个消息ClusterConfig它的全部字段就是子集群名称列表。落地分三件事① 子集群先在配置里各自独立定义好——端点、健康检查、负载均衡算法都归它们自己管Composite 只引用名字 ② 新建一个集群lb_policy设为CLUSTER_PROVIDEDcluster_type指向envoy.clusters.composite ③ 在clusters列表里按“希望被尝试的先后顺序”写下集群名。name: my_ai_cluster lb_policy: CLUSTER_PROVIDED cluster_type: name: envoy.clusters.composite typed_config: type: type.googleapis.com/envoy.extensions.clusters.composite.v3.ClusterConfig clusters: - name: provider_a - name: provider_b - name: provider_c铁律列表顺序 尝试次序。按上面这份配置运行时语义是初始请求attempt 1→provider_a第一次重试attempt 2→provider_b第二次重试attempt 3→provider_c第四次尝试attempt 4 起→ 下标越界请求直接失败列表不能为空、名字不能是空串这些校验规则min_items: 1、min_len: 1定义在 api/envoy/extensions/clusters/composite/v3/cluster.proto 里配置加载阶段就会拦下错误不用等到运行时。内部如何按重试次数选集群你可以把它想象成机场备降指挥空管不关心哪趟航班人多只看你是“第几架”——第一架降 A 场第二架降 B 场第三架降 C 场第四架对不起本场没有可用跑道直接拒绝。内部流程比这更简单。它会先从请求上下文里读出当前的 attempt countEnvoy 的尝试次数从 1 开始计数如果上下文缺失或读出来是 0视为异常状态打一条 warn 日志并放弃选择。然后做最核心的一步减法下标 attempt count − 1。算出的下标落在列表长度内就锁定该位置的子集群超出列表长度重试次数多于集群数则本次尝试直接失败报“无可用主机”不会绕圈去试别的集群。锁定子集群之后Composite 自己不碰任何 host。挑具体哪台机器完全委托给子集群自带的负载均衡算法round robin、maglev 都可以。也就是说Composite 负责“进哪个门”子集群负责“门内坐哪桌”。这条选择路径还有一个性能设计值得知道它发生在每个 worker 线程本地的负载均衡器里thread-local clustering选集群时没有跨线程加锁开销子集群的增删变更通过更新回调同步到各个线程选择路径始终读的是本线程的快照。每个子集群也保持独立自己的健康检查、outlier detection 各管各的Composite 不掺和。子集群没有可用主机时会发生什么这是最容易被误解的行为。如果某次 attempt 映射到的子集群一台可用主机都拿不出来——比如 DNS 解析失败导致端点列表为空或 outlier detection 把主机全部逐出——默认情况下它不会立刻判死刑而是在同一次尝试内顺着列表往后逐个试直到某个集群交出主机如果后面全都拿不出主机请求才以no_healthy_upstream503失败。打个比方这就像 UPS 备用电源主电源断了先切第一块电池第一块也亏电就切第二块全程对用电设备无感而且切电池不会改变设备“应该由哪一路供电”的编号。两个细节要留意异步选择不被打断如果某个子集群返回的是“异步主机选择正在进行”例如异步 DNS 还没回来选择流程会立刻交棒给那个异步流程不再尝试列表里其他集群。runtime 开关上述无主机 failover 行为由envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts控制默认开启。置为false会退回旧行为——映射到的子集群无主机时立即失败不做同尝试内兜底。这个开关正是早期版本“子集群恰好没主机就误报 503”缺陷修复后留下的逃生舱。重试策略如何与集群数对齐Composite 不会替你触发重试路由层必须配一条配套的重试策略公式很简单子集群数 num_retries 1。retry_policy: retry_on: 5xx,connect-failure,refused-stream num_retries: 2 # 1 次初始 2 次重试 共 3 次尝试配num_retries: 2恰好覆盖三个子集群。两类错配的后果都很难看配多了超出的尝试下标越界请求直接失败——白烧重试预算换来的必然是一次失败响应配少了排在后面的子集群永远拿不到流量白配。还有一个容易被忽略的点failover 不移动后续尝试的映射。因为下标只由 attempt count 决定某次尝试向后兜底并不会“推动”后面的尝试。举例列表是[provider_a, provider_b, provider_c]若provider_a为空attempt 1 会落到provider_b但 attempt 2 依然映射到provider_b而不是provider_c。设计重试规模时要把这种重叠算进去。上线前检查清单 发版前逐条过一遍能省掉大量线上排障时间lb_policy已设为CLUSTER_PROVIDED——Composite 自身不承载任何 host每个子集群都在配置其他位置独立定义健康检查与负载均衡各自配齐num_retries 1恰好等于clusters列表长度理解 failover 语义同尝试内向后兜底不改变后续 attempt 的映射确认 runtime 开关...composite_cluster_skip_clusters_without_hosts的取值符合预期默认开启验证入口建议留两个一是用 admin 的/config_dump与/clusters确认集群列表与顺序已正确下发后者能直接看到各子集群端点与健康状态二是跑一遍仓库自带的测试单元测试cluster_test.cc覆盖了 attempt 提取、下标映射与 failover 边界集成测试cluster_integration_test.cc用多个 fake upstream 端到端验证空端点场景位置在 test/extensions/clusters/composite/。延伸阅读官方架构文档 composite_cluster.rst 里有完整的字段说明与 Aggregate 对比表。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考