动态上游选择器是带业务语义的路由决策模块，根据用户ID、地域、设备类型、流量比例等运行时规则自动路由请求；需统一结构化上下文（如RoutingContext），采用“规则+动作”声明式模型，支持优先级匹配与表达式引擎。
动态上游选择器的核心是让请求在运行时根据业务规则（比如用户ID、地域、设备类型、流量比例等）自动路由到不同的后端服务实例或集群，而不是写死在配置里。它不是简单的负载均衡，而是“带业务语义的路由决策模块”。
明确上游选择的业务维度
先梳理清楚哪些业务因素会影响路由结果。常见维度包括：
-
用户标识类：用户ID哈希、会员等级、灰度标签（如
beta_user:true） -
环境上下文类：请求来源IP所属区域（通过GeoIP识别）、设备类型（mobile/web/iot）、HTTP Header中的
X-Env或X-Cluster - 策略控制类：A/B测试分组（按10%流量切到新版本）、熔断状态（某上游故障时自动降级）、权重配置（老集群占70%，新集群占30%）
建议用一个结构化对象（如RoutingContext）统一承载这些字段，便于后续规则引擎接入。
设计可扩展的规则匹配与执行模型
避免硬编码 if-else 判断。推荐采用“规则+动作”的声明式设计：
- 每条规则包含：条件表达式（如
ctx.userId % 100 或 <code>ctx.region == "shanghai" && ctx.isMobile）和目标上游标识（如user-service-v2） - 规则支持优先级排序，匹配第一条即终止；也可支持“兜底默认上游”
- 条件表达式建议基于轻量表达式引擎（如 Aviator、JEXL 或自研 DSL），而非直接 eval 字符串，兼顾安全与性能
示例规则片段（JSON格式）：
{
"rules": [
{ "priority": 1, "condition": "ctx.userId % 100 < 5", "upstream": "user-service-canary" },
{ "priority": 2, "condition": "ctx.region == 'beijing'", "upstream": "user-service-bj" },
{ "priority": 3, "condition": "true", "upstream": "user-service-default" }
]
}
集成上游发现与健康检查
动态选择的前提是知道有哪些上游可用、是否健康。需对接服务注册中心（如 Nacos、Consul、Eureka）并缓存节点列表，同时定期探测节点存活状态：
- 每个上游标识（如
user-service-v2）映射一组实际地址（IP:Port），支持 DNS 或服务发现动态刷新 - 健康检查失败的节点应从候选池中临时剔除，但不删除规则——规则仍生效，只是执行时跳过不可用节点
- 建议引入“软失败”机制：当所有节点异常时，是否允许回退到备用上游或返回降级响应，由业务策略决定
可观测性与热更新能力
上线后必须能快速定位问题、验证规则效果、无需重启即可调整策略：
- 记录每次路由决策的完整链路：
request_id → routing_context → matched_rule → selected_upstream → response_time - 提供 HTTP 接口或管理后台，支持实时上传/编辑规则配置，并触发内存热加载（注意线程安全与版本一致性）
- 关键指标暴露为 Prometheus metrics：规则匹配次数、各上游调用占比、未命中规则数、健康节点数等
不复杂但容易忽略。
