Backend routing

Updated at:

A backend routing plug-in (also called a plug-in of the Routing type in the console) evaluates request attributes, such as caller identity, environment, client IP, and custom parameters, and routes each request to the appropriate backend service. You can use this plug-in for multi-tenant routing, blue-green deployments, and environment-based traffic splitting.

How it works

API Gateway evaluates routing rules in order. The first rule whose condition matches the request determines the backend. If no rule matches, the request goes to the default backend defined in the API.

Each routing rule specifies:

  • A condition that the request must match

  • A backend to route matching requests to

  • (Optional) A weight for distributing traffic across multiple matching backends

  • (Optional) Constant parameters to attach to the request before forwarding

Use cases

Scenario

How it works

Configuration approach

Multi-tenant routing

Route VIP callers to dedicated server clusters

Match $CaAppId to route to a VPC backend

Environment-based routing

Direct test-stage requests to a test server

Match $CaStage to override the backend URL

Blue-green deployment

Split traffic between stable and new versions

Assign weights to multiple routes with 1 = 1 conditions

Consistent hashing

Pin requests from the same IP or with the same parameter to one backend

Set routeByHash with a hash factor

Configuration format

Plug-ins accept JSON or YAML. Both formats share the same schema and convert between each other.

The following YAML template shows the basic structure:

---
routes:
  # Route VIP callers to a dedicated VPC backend
  - name: Vip
    condition: "$CaAppId = 123456"
    backend:
      type: "HTTP-VPC"
      vpcAccessName: "slbAccessForVip"

  # Return a mock response for outdated clients
  - name: MockForOldClient
    condition: "$ClientVersion < '2.0.5'"
    backend:
      type: "MOCK"
      statusCode: 400
      body: "This version is not supported!!!"

Route object

Field

Required

Description

name

Yes

Unique name within the plug-in. Letters and digits only. When a request matches this rule, API Gateway adds an X-Ca-Routing-Name header with this value.

condition

Yes

A conditional expression that determines whether a request matches this rule. Rules are evaluated in order; the first match wins.

backend

Yes

Backend configuration that overrides the API's default backend. Must conform to the API Gateway OpenAPI specification. Incomplete configuration returns X-Ca-Error-Code: I504RB.

constant-parameters

No

Custom constant parameters attached to the request before forwarding. Each parameter requires name, location (header or query), and value.

weight

No

Traffic weight for this route. Used when multiple routes match.

Conditional expressions

Syntax

Conditional expressions use SQL-like syntax:

$ParamName = 'value' and $AnotherParam = 'value'

Rules:

  • Prefix each parameter with $. Reference any request parameter defined in the API (MAPPING or PASSTHROUGH mode).

  • Combine expressions with and and or. Use parentheses () to control precedence.

  • A non-existent parameter in a condition evaluates to false.

Supported data types:

Type

Description

Example

STRING

Enclose in single or double quotes

'Hello', "Hello"

INTEGER

Integer values

1001, -1

NUMBER

Floating-point values

0.1, 100.0

BOOLEAN

Boolean values

true, false

System parameters

You can reference these built-in parameters without defining them in the API. If an API defines a parameter with the same name, the API parameter value takes precedence.

Parameter

Description

Example values

$CaStage

Deployment stage of the API

RELEASE, PRE, TEST

$CaDomain

Domain name of the API group

-

$CaRequestHandleTime

Time the request was received (UTC)

-

$CaAppId

AppId of the caller

10098

$CaAppKey

AppKey of the caller

-

$CaClientIp

Client IP address

47.47.XX.XX

$CaApiName

Name of the requested API

-

$CaHttpScheme

Request protocol

HTTP, HTTPS

$CaClientUa

Client UserAgent string

-

Expression examples

Route requests for APIs published to the test stage:

$CaStage = 'TEST'

Match a specific user from a specific IP address:

$UserName = 'Admin' and $CaClientIp = '47.47.XX.XX'

Match multiple AppIds over HTTPS:

$CaHttpScheme = 'HTTPS' and ($CaAppId = 1001 or $CaAppId = 1098 or $CaAppId = 2011)

Backend types

The backend configuration in a routing rule overrides the default backend of the bound API. To change only specific fields without switching backend types, specify only the fields to override. Backend configurations must be consistent with the Swagger files imported to API Gateway. For more information, see Import Swagger files to create APIs with API Gateway extensions.

Important

To distribute requests by weight, specify all backend parameters. For Host header priority details, see Configure the Host header. The minimum configurable timeout is 300 ms. Values below this threshold default to 300 ms.

Backend parameter reference

Backend type

Parameter

Description

HTTP

address

Backend URL, e.g. http://10.10.100.2:8000

httpTargetHostName

Host header override (highest priority)

path

Request path, e.g. /users/{userId}

method

HTTP method, e.g. GET

timeout

Timeout in milliseconds (minimum 300 ms)

HTTP-VPC

vpcAccessName

VPC access authorization name

vpcTargetHostName

Host header override (highest priority)

vpcScheme

Protocol for the VPC backend, e.g. https

path

Request path

method

HTTP method

timeout

Timeout in milliseconds (minimum 300 ms)

FC

fcRegion

Function Compute region, e.g. cn-shanghai

fcType

Trigger type: FCEvent or HttpTrigger

serviceName

FC service name (FCEvent)

functionName

FC function name (FCEvent)

fcUrl

Function URL (HttpTrigger)

roleArn

RAM role ARN for API Gateway to access FC

method

HTTP method (HttpTrigger only)

OSS

ossRegionId

Object Storage Service (OSS) region, e.g. cn-hangzhou

bucketName

OSS bucket name

key

Object key, e.g. /objectName

timeout

Timeout in milliseconds (minimum 300 ms)

action

OSS operation, e.g. putObject

MOCK

mockResult

Mock response body

mockStatusCode

HTTP status code for the mock response

mockHeaders

Array of response headers (each with name and value)

Configuration examples

HTTP

---
backend:
  type: HTTP
  address: "http://10.10.100.2:8000"
  httpTargetHostName: "a.b.com"
  path: "/users/{userId}"
  method: GET
  timeout: 7000

HTTP-VPC

---
backend:
  type: HTTP-VPC
  vpcAccessName: vpcAccess1
  vpcTargetHostName: "a.b.com"
  vpcScheme: "https"
  path: "/users/{userId}"
  method: GET
  timeout: 10000

Function Compute (FCEvent)

---
backend:
  type: FC
  fcRegion: cn-shanghai
  fcType: FCEvent
  serviceName: fcService
  functionName: fcFunction
  roleArn: "acs:ram::111111111:role/aliyunapigatewayaccessingfcrole"

Function Compute (HttpTrigger)

---
backend:
  type: FC
  fcRegion: cn-shenzhen
  method: GET
  fcType: HttpTrigger
  fcUrl: https://1833848375796824.cn-shenzhen.fc.aliyuncs.com/2016-08-15/proxy/servicetest/fctest3/fctest3
  roleArn: acs:ram::1833848375796824:role/aliyunapigatewayaccessingfcrole

OSS

---
backend:
  type: OSS
  ossRegionId: cn-hangzhou
  bucketName: bucketName
  key: /objectName
  timeout: 10000
  action: putObject

MOCK

---
backend:
  type: MOCK
  mockResult: "mock resul sample"
  mockStatusCode: 200
  mockHeaders:
    - name: server
      value: mock
    - name: proxy
      value: GW

Weighted traffic distribution

You can assign weights to routes to distribute traffic proportionally. Routes with higher weights receive more requests.

---
routes:
  - name: Backend01
    condition: "1 = 1"   # Always matches
    weight: 100
    backend:
      type: "HTTP"
      address: "https://test01.com"
      path: "/web/cloudapi"
  - name: Backend02
    condition: "1 = 1"
    weight: 80
    backend:
      type: "HTTP"
      address: "https://test02.com"
      path: "/web/cloudapi"

Traffic distribution rules:

Condition

Behavior

One route matches

All requests go to that route's backend

Multiple routes match

Requests are distributed proportionally by weight

No route matches

Requests go to the API's default backend

Important

Weight-based distribution requires specifying all backend parameters in each route.

Consistent hashing

Consistent hashing distributes requests based on a hash factor. Requests with the same hash factor always reach the same backend.

Supported hash factors:

Hash factor

Description

Source IP address

Requests from the same client IP go to the same backend

Request parameter

Requests with the same parameter value go to the same backend

Example: source IP hashing

---
parameters:
  clientIp: "System:CaClientIp"
routeByHash: clientIp
routes:
  - name: route1
    condition: "1 = 1"
    backend:
      type: "MOCK"
      statusCode: 200
      mockResult: "Hello World!!!"
  - name: route2
    condition: "1 = 1"
    backend:
      type: "MOCK"
      statusCode: 400
      mockResult: "mock resul sample"
  - name: route3
    condition: "1 = 0"   # Never matches
    backend:
      type: "HTTP"
      address: "https://test.com"
    constant-parameters:
      - name: x-route-by-hash
        location: header
        value: "route-by-hash"

In this example, parameters maps clientIp to the system parameter CaClientIp. The routeByHash field selects clientIp as the hash factor. Requests from the same client IP are consistently routed to the same backend among the matching routes.

Routing scenarios

Route by application ID

Route VIP callers (AppId 10098 or 10099) to a dedicated virtual private cloud (VPC) backend:

---
routes:
  - name: Vip
    condition: "$CaAppId = 10098 or $CaAppId = 10099"
    backend:
      type: "HTTP-VPC"
      vpcAccessName: "slbAccessForVip"

Route by environment

Send all test-stage requests to a public test server:

---
routes:
  - name: Vip
    condition: "$CaStage = 'TEST'"
    backend:
      type: "HTTP"
      address: "https://test-env.foo.com"

Blue-green deployment

Split traffic 5%/95% between a beta server and a VPC production backend:

---
routes:
  - name: BlueGreenPercent05
    condition: "1 = 1"
    weight: 5
    backend:
      type: "HTTP"
      address: "https://beta-version.api.foo.com"
      path: "/web/cloudapi"
    constant-parameters:
      - name: x-route-blue-green
        location: header
        value: "route-blue-green"
  - name: BlueGreenPercent95
    condition: "1 = 1"
    weight: 95
    backend:
      type: HTTP-VPC
      path: "/web/cloudapi"
      vpcAccessName: testvpc
condition: "1 = 1" always matches. condition: "1 = 0" never matches. Use weight to control traffic distribution between matching routes.

Limitations

Constraint

Limit

Error code

Plug-in metadata size

16,384 bytes

InvalidPluginData.TooLarge

Routes per plug-in

160

InvalidPluginData.TooManyRoutes

Conditional expression size

512 bytes

InvalidPluginData.ConditionTooLong

Minimum update interval

45 seconds

InvalidPluginData.UpdateTooBusy