Azure APIM动态设置后端URL的策略合理性与优化问询

问题描述 #

现有Azure APIM策略如下：

<policies>
<inbound>
    <choose>
        <when condition="@(context.Request.OriginalUrl.Host.Contains("xyz.prod.abc.com"))">
            <set-backend-service base-url=https://xyz.alpha.abc.com/lead />
        </when>
        <when condition="@(context.Request.OriginalUrl.Host.Contains("xyz.uat.abc.com"))">
            <set-backend-service base-url=https://xyz.uat.alpha.abc.com/lead />
        </when>
        <when condition="@(context.Request.OriginalUrl.Host.Contains("xyz.qa.abc.com"))">
            <set-backend-service base-url=https://xyz.qa.alpha.abc.com/lead />
        </when>
        <otherwise>
            <set-backend-service base-url=https://xyz.dev.alpha.abc.com/lead/>
        </otherwise>
    </choose>
    <base />
</inbound>
<backend>
    <base />
</backend>
<outbound>
    <base />
</outbound>
<on-error>
    <base />
</on-error>

针对该策略有以下疑问：

1. 这种通过判断请求Host设置后端服务URL的实现，是否是新接入API的正确且最优方案？
2. 是否存在更优的实现方案？
3. 若为各APIM环境配置了对应的后端URI命名值（Named Values），能否实现动态调用并精简策略？

回答 #

现有实现的正确性与最优性判断 #

现有实现是能正常工作的，可以根据请求Host将流量路由到对应后端服务，但绝对算不上最优方案：

• 存在的问题：
  • 所有Host和后端URL都硬编码在策略中，后续新增环境或修改地址时，必须直接修改策略代码，维护成本高且易出错
  • 多个when分支逻辑重复，代码冗余度高
  • 依赖请求Host判断环境，若采用多APIM实例对应多环境的部署模式，完全没有利用APIM本身的环境属性，属于资源浪费

更优方案：基于APIM命名值+环境属性动态配置 #

当然可以通过APIM的命名值结合环境标识实现动态路由，既能大幅精简策略代码，又能提升可维护性。具体实现步骤如下：

1. 为各环境配置对应的命名值

在APIM实例中，为每个环境创建对应后端URL的命名值：

• 生产环境：创建命名值BackendLeadUrl，值设为https://xyz.alpha.abc.com/lead
• UAT环境：创建命名值BackendLeadUrl，值设为https://xyz.uat.alpha.abc.com/lead
• QA环境：创建命名值BackendLeadUrl，值设为https://xyz.qa.alpha.abc.com/lead
• 开发环境：创建命名值BackendLeadUrl，值设为https://xyz.dev.alpha.abc.com/lead

注意：如果是多APIM实例对应多环境的部署模式，每个APIM实例单独配置对应环境的命名值即可；如果是单APIM实例通过不同Host区分多环境，可以给命名值添加环境前缀，比如Prod_BackendLeadUrl、UAT_BackendLeadUrl。

2. 精简后的策略实现

分两种场景提供实现代码：

场景1：多APIM实例对应多环境（最推荐）

每个环境使用独立的APIM实例，直接通过命名值动态获取后端URL：

<policies>
<inbound>
    <set-backend-service base-url="{{BackendLeadUrl}}" />
    <base />
</inbound>
<backend>
    <base />
</backend>
<outbound>
    <base />
</outbound>
<on-error>
    <base />
</on-error>
</policies>

场景2：单APIM实例区分多环境（通过Host）

先从请求Host中提取环境标识，再动态匹配对应的命名值：

<policies>
<inbound>
    <set-variable name="env" value="@(
        context.Request.OriginalUrl.Host switch {
            string h when h.Contains("xyz.prod.abc.com") => "Prod",
            string h when h.Contains("xyz.uat.abc.com") => "UAT",
            string h when h.Contains("xyz.qa.abc.com") => "QA",
            _ => "Dev"
        }
    )" />
    <set-backend-service base-url="{{{{env}}_BackendLeadUrl}}" />
    <base />
</inbound>
<backend>
    <base />
</backend>
<outbound>
    <base />
</outbound>
<on-error>
    <base />
</on-error>
</policies>

这里使用了双大括号嵌套，APIM会先解析{{env}}获取环境标识，再拼接成{{Prod_BackendLeadUrl}}并解析对应的命名值。

方案优势 #

• 策略代码极度精简，无硬编码地址，可读性更强
• 后端URL的修改无需改动策略，直接在APIM命名值中更新，降低维护风险
• 符合APIM最佳实践，利用平台原生特性提升系统扩展性

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