从服务C向两个微服务按TPS百分比分配流量 求可行方案

核心问题本质对齐 #

当前需求和传统负载均衡场景存在本质差异：

• 目标是在两个独立部署、独立注册的微服务A、B之间拆分流量，不是对同一个微服务的多实例做负载调度，这也是原生Ribbon和预期不匹配的核心原因——它默认的工作逻辑就是拉取同一个服务ID下的所有实例做轮询/随机调度，原生能力完全不覆盖跨独立服务的路由场景
• 必须落地的两个硬需求：能够基于实时TPS统计校准分流比例、能够稳定在两个独立服务间按固定权重分配来自C的调用流量

具体可落地方案 #

1. 服务网格层分流（精度优先场景） #

该方案可完全绕开Ribbon的能力限制：

• 跨服务路由能力：网格的流量调度逻辑不依赖客户端的负载组件，直接通过sidecar拦截所有出站流量，支持配置任意两个独立服务之间的权重分流规则，不存在Ribbon那种绑定同服务实例列表的限制
• 实时TPS能力：网格内置全链路流量采集组件，可实时统计服务C发出的、分别流向A和B的TPS数值，支持按配置的比例动态校准分流逻辑，当实际流量占比和配置阈值偏差超过5%时自动调整调度权重，保证长周期下的分流精度
• 落地成本：只需要在网格控制面配置对应路由规则，不需要改动服务C的业务代码，也不需要额外维护Ribbon的自定义规则

2. 自定义客户端负载规则（无额外组件引入场景） #

如果不想引入服务网格、希望基于现有Spring Cloud生态快速落地，可以通过改造现有Ribbon/Spring Cloud LoadBalancer的逻辑实现：

• 打破跨服务路由限制：重写负载均衡器的服务实例获取逻辑，替换默认逻辑里“从注册中心拉取同一个服务ID下所有实例”的流程，直接把返回的实例列表固定映射为A、B两个服务的可访问地址
• 实时TPS分流逻辑：在自定义的规则里内置滑动窗口计数器，每处理一次C发出的调用请求，就根据已统计的累计分流TPS计算路由方向：当累计流向A的流量占总流量的比例低于10%时，优先把请求路由到A；当A的累计流量占比达到10%的阈值后，后续请求全部路由到B；计数器按固定窗口重置，保证长时间运行下的比例精度
• 注意：Netflix Ribbon已经进入维护停更阶段，长期维护建议替换为Spring Cloud官方推荐的Spring Cloud LoadBalancer，上述自定义规则的实现逻辑和Ribbon完全兼容

3. API网关统一分流（流量已收敛场景） #

如果现有架构已经有统一部署的API网关，且服务C对A、B的调用流量可以统一经过网关转发：

• 直接在网关层配置两个路由目标的权重映射，按10%、90%的比例拆分来自C的请求
• 网关内置的流量统计组件可以直接采集每个路由目标的实时TPS，自动按权重分配流量，不需要在每个客户端服务里重复实现分流逻辑

方案选型参考 #

• 对分流精度要求高、团队有服务网格运维能力的场景，优先选服务网格方案，长期维护成本最低
• 不想引入新组件、现有栈深度绑定Spring Cloud的场景，优先选自定义负载规则的方案，改造成本最小
• 已经有成熟API网关部署的场景，优先选网关分流方案，不需要额外开发自定义逻辑

内容的提问来源于stack exchange，提问作者swati mishra