Apache APISIX 中基于请求特征的多上游路由实现方案

在实际的 API 网关应用场景中，经常需要根据不同的请求特征（如路径、Header 等）将流量分发到不同的上游服务。本文将深入探讨在 Apache APISIX 中实现这一需求的几种技术方案。

核心需求分析

典型的业务场景包括：

• 根据请求路径分发（如 /api/v1 和 /api/v2 路由到不同服务）
• 根据 Header 值选择不同上游（如根据设备类型或用户分组）
• 实现灰度发布或 A/B 测试

解决方案对比

1. 一致性哈希（chash）方案

适用于需要保持会话粘性的场景，可通过配置 hash_on 参数实现基于 Header 的路由：

{
  "type": "chash",
  "key": "header_name",
  "nodes": [
    {"host": "upstream1", "weight": 1},
    {"host": "upstream2", "weight": 1}
  ]
}

特点：

• 保持相同 Header 的请求始终路由到同一上游
• 适合需要会话保持的场景
• 配置简单，性能损耗小

2. 流量分割插件（traffic-split）

更灵活的流量控制方案，支持基于多种条件的路由规则：

{
  "rules": [
    {
      "match": [{"vars": [["uri","==","/foo/bar"]]}],
      "weighted_upstreams": [{"upstream_id": "1", "weight": 100}]
    },
    {
      "match": [{"vars": [["uri","==","/my/home"]]}],
      "weighted_upstreams": [{"upstream_id": "2", "weight": 100}]
    }
  ]
}

高级功能：

• 支持基于 URI、Header、Cookie 等多种匹配条件
• 可设置权重实现灰度发布
• 支持百分比流量分配

3. 服务端脚本方案（serverless）

对于需要复杂路由逻辑的场景，可使用 serverless 插件编写自定义路由逻辑：

return function(conf, ctx)
    local uri = ctx.var.uri
    if uri:find("^/foo/") then
        os.setenv("upstream", "upstream1")
    elseif uri:find("^/my/") then
        os.setenv("upstream", "upstream2")
    end
end

适用场景：

• 需要复杂路由逻辑（如正则匹配）
• 需要动态计算路由目标
• 需要与其他系统交互决定路由

最佳实践建议

1. 简单路径匹配：优先使用 traffic-split 插件
2. 会话保持需求：选择 chash 方案
3. 复杂业务逻辑：采用 serverless 自定义脚本
4. 性能考虑：避免在 serverless 中实现复杂计算

实现示例

以下是一个完整的 traffic-split 配置示例，实现基于 URI 路径的路由：

{
  "uri": "/*",
  "plugins": {
    "traffic-split": {
      "rules": [
        {
          "match": [{"vars": [["uri","~~","^/foo/"]]}],
          "upstream_id": "1"
        },
        {
          "match": [{"vars": [["uri","~~","^/my/"]]}],
          "upstream_id": "2"
        }
      ]
    }
  }
}

通过合理组合这些方案，可以在 Apache APISIX 中构建灵活高效的流量路由系统，满足各种复杂的业务场景需求。