Backend routing
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 |
Environment-based routing | Direct test-stage requests to a test server | Match |
Blue-green deployment | Split traffic between stable and new versions | Assign weights to multiple routes with |
Consistent hashing | Pin requests from the same IP or with the same parameter to one backend | Set |
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 |
| Yes | Unique name within the plug-in. Letters and digits only. When a request matches this rule, API Gateway adds an |
| Yes | A conditional expression that determines whether a request matches this rule. Rules are evaluated in order; the first match wins. |
| Yes | Backend configuration that overrides the API's default backend. Must conform to the API Gateway OpenAPI specification. Incomplete configuration returns |
| No | Custom constant parameters attached to the request before forwarding. Each parameter requires |
| 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
andandor. 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 |
|
INTEGER | Integer values |
|
NUMBER | Floating-point values |
|
BOOLEAN | Boolean values |
|
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 |
| Deployment stage of the API |
|
| Domain name of the API group | - |
| Time the request was received (UTC) | - |
| AppId of the caller |
|
| AppKey of the caller | - |
| Client IP address |
|
| Name of the requested API | - |
| Request protocol |
|
| 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.
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 |
| Backend URL, e.g. |
| Host header override (highest priority) | |
| Request path, e.g. | |
| HTTP method, e.g. | |
| Timeout in milliseconds (minimum 300 ms) | |
HTTP-VPC |
| VPC access authorization name |
| Host header override (highest priority) | |
| Protocol for the VPC backend, e.g. | |
| Request path | |
| HTTP method | |
| Timeout in milliseconds (minimum 300 ms) | |
FC |
| Function Compute region, e.g. |
| Trigger type: | |
| FC service name (FCEvent) | |
| FC function name (FCEvent) | |
| Function URL (HttpTrigger) | |
| RAM role ARN for API Gateway to access FC | |
| HTTP method (HttpTrigger only) | |
OSS |
| Object Storage Service (OSS) region, e.g. |
| OSS bucket name | |
| Object key, e.g. | |
| Timeout in milliseconds (minimum 300 ms) | |
| OSS operation, e.g. | |
MOCK |
| Mock response body |
| HTTP status code for the mock response | |
| Array of response headers (each with |
Configuration examples
HTTP
---
backend:
type: HTTP
address: "http://10.10.100.2:8000"
httpTargetHostName: "a.b.com"
path: "/users/{userId}"
method: GET
timeout: 7000HTTP-VPC
---
backend:
type: HTTP-VPC
vpcAccessName: vpcAccess1
vpcTargetHostName: "a.b.com"
vpcScheme: "https"
path: "/users/{userId}"
method: GET
timeout: 10000Function 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/aliyunapigatewayaccessingfcroleOSS
---
backend:
type: OSS
ossRegionId: cn-hangzhou
bucketName: bucketName
key: /objectName
timeout: 10000
action: putObjectMOCK
---
backend:
type: MOCK
mockResult: "mock resul sample"
mockStatusCode: 200
mockHeaders:
- name: server
value: mock
- name: proxy
value: GWWeighted 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 |
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: testvpccondition: "1 = 1"always matches.condition: "1 = 0"never matches. Useweightto control traffic distribution between matching routes.
Limitations
Constraint | Limit | Error code |
Plug-in metadata size | 16,384 bytes |
|
Routes per plug-in | 160 |
|
Conditional expression size | 512 bytes |
|
Minimum update interval | 45 seconds |
|