As a base unit of the system architecture, cloud-native gateways integrate traditional traffic gateways with microservice gateways. The integration significantly reduces network overheads and O&M costs and provides various throttling methods and systematic monitoring methods. This topic describes how to configure routing policies, view gateway metrics, and configure alerts and authentication. For more information about basic operations of cloud-native gateways, see Get started with cloud-native gateways.
Prerequisites
A cloud-native gateway is created. For more information, see Create an MSE cloud-native gateway.
Add a service
Configure a Container Service for Kubernetes (ACK) cluster as a service source
In the left-side navigation pane, choose Service Management > Sources.
In the upper-left corner of the Sources page, click Add Source.
In the Add Source panel, configure the parameters and click OK. The following table describes the parameters.
Parameter
Description
Source Type
Select Container Service.
ACK/ACK Serverless Cluster
Select the cluster in which your backend service is deployed.
Cloud-native gateways support Container Service and other service sources, such as MSE Nacos, MSE ZooKeeper, and EDAS Registry. For more information, see Add a service source.
Add a container service
In the left-side navigation pane, choose Service Management > Services.
In the upper-left corner of the Services page, click Add Service.
In the Add Service panel, configure the parameters and click OK. The following table describes the parameters.
Parameter
Description
Container Service
Select Container Service.
Namespace
Select a namespace for the cluster.
Services
Select destination services.
In addition to Container Service, cloud-native gateways also support other service sources, such as MSE Nacos, DNS Domain Name, Fixed Address, and EDAS Registry. For more information, see Add a service.
Configure a route
Configure no route
Log on to the MSE console. In the top navigation bar, select a region.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.
On the Gateway Ingress tab of the Overview page, view the Ingress IP Address of the gateway.
NoteThe ingress IP address of a cloud-native gateway is the IP address of a Server Load Balancer (SLB) instance that is associated with the gateway. You can replace the SLB instance with a self-managed SLB instance. For more information, see Manage SLB instances that are specified as Ingresses.
Run the following command to send a test request:
curl -I http://121.196.XX.XX
The following result is returned. The HTTP status code 404 is returned because no route is configured.
HTTP/1.1 404 Not Found date: Mon, 29 Nov 2021 03:36:32 GMT server: istio-envoy transfer-encoding: chunked
Configure a mock route for a gateway
Cloud-native gateways also support other routing methods, such as single-service routing, multi-service routing, and tag-based routing. For more information, see Routing modes.
In the left-side navigation pane of the Overview page, choose Routes > Route Settings. In the upper-left corner of the page that appears, click Add Route.
In the Add Route panel, configure the parameters and click Save and Release.
In the Request Information step, configure the parameters and click Next. The following table describes the parameters.
For more information, see Create a routing rule.
Parameter
Description
Routing Rule Name
Set this parameter to
mock
.Domain Name
Select the default associated domain name
*
from the drop-down list.Match Rule
Path
Select Prefix Match from the Path Match Condition drop-down list and enter /mock in the field.
Method
This parameter is used to match HTTP requests that have a route. If you do not configure this parameter, requests that contain any Method parameter value can match the route. You can specify multiple values for the Method parameter in the matching condition to match more requests that have a route.
Header
This parameter is used to match HTTP requests that have a route. If multiple routes have the same matching conditions aside from the number of specified Header parameters, a route that has a larger number of Header parameters in the rule has a higher priority. Click Request Header to add a Header parameter in the routing rule.
Query Parameters
This parameter is used to match HTTP requests that have a route. If multiple routes have the same matching conditions aside from the number of specified Query parameters, a route that has a larger number of Query parameters in the rule has a higher priority. Click Request Parameters to add a Query parameter in the routing rule.
In the Destination Service step, select Mock for Destination Service, and configure the Status Code and Response Content parameters.
Run the following command to send a test request:
curl http://121.196.XX.XX/mock
The following result is returned:
{code:200,data:"hello mock!"}
Configure routing policies
Configure no routing policies
Log on to the MSE console.
In the top navigation bar, select a region.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.
In the left-side navigation pane of the Overview page, choose Routes > Route Settings.
Run the following command to send a test request:
curl -I http://121.196.XX.XX/demo/item/list
NoteThe preceding command contains the Demo service of the Nacos source. You can replace the URL with an actual URL based on your backend service.
The following result is returned:
HTTP/1.1 200 OK x-content-type-options: nosniff x-xss-protection: 1; mode=block cache-control: no-cache, no-store, max-age=0, must-revalidate pragma: no-cache expires: 0 x-frame-options: DENY content-type: application/json content-length: 86 date: Mon, 29 Nov 2021 08:28:00 GMT x-envoy-upstream-service-time: 4 server: istio-envoy
Configure a throttling policy
You can also configure rewrite policies, cross-origin resource sharing (CORS) policies, and header setting policies for cloud-native gateways. For more information, see Routing policies.
On the Route Settings page, find the route whose routing rule you want to modify, and click Policies in the Actions column.
In the Policies section of the page that appears, click the Throttling tab.
Gateways of 1.2.25 or later
Configure a throttling rule
Throttling rules are used to block traffic immediately if the system detects that the QPS of a route reaches a specified threshold. This prevents a breakdown of backend services due to traffic surges and ensures high availability of backend services.
On the Throttling tab, click the Throttling Rules subtab.
On the Throttling Rules subtab, configure the parameters.
Parameter
Description
Gateway QPS Threshold
Enter a value for Gateway QPS Threshold.
Web Fallback Behavior
Select Return Specified Content or Go to Specified Page for Web Fallback Behavior.
If you set Web Fallback Behavior to Go to Specified Page:
Redirect URL
Enter the address to be redirected to.
If you set Web Fallback Behavior to Return Specified Content:
HTTP Status Code
Enter the HTTP status code. The default value is 429.
Returned Content Type
Select Plain Text or JSON for Returned Content Type.
Returned HTTP Text
Enter the returned text.
Enable
If you turn on this switch, the configured throttling rule takes effect.
Click New or Save to create or update the rule.
Configure a concurrency rule
Concurrency rules are used to block traffic immediately if the system detects that the total number of requests that are being processed by a gateway reaches a specified threshold. When you configure concurrency rules, you can specify the maximum number of concurrent requests that can be processed by backend services. This ensures availability of backend services in scenarios in which a large number of concurrent requests are initiated.
On the Throttling tab, click the Concurrency Rules subtab.
On the Concurrency Rules subtab, configure the parameters.
Parameter
Description
Gateway Parallelism Threshold
Enter a value for Gateway Parallelism Threshold.
Web Fallback Behavior
Select Return Specified Content or Go to Specified Page for Web Fallback Behavior.
If you set Web Fallback Behavior to Go to Specified Page:
Redirect URL
Enter the address to be redirected to.
If you set Web Fallback Behavior to Return Specified Content:
HTTP Status Code
Enter the HTTP status code. The default value is 429.
Returned Content Type
Select Plain Text or JSON for Returned Content Type.
Returned HTTP Text
Enter the returned text.
Enable
If you turn on this switch, the configured concurrency rule takes effect.
Click Create or Save to create or update the rule.
Configure a circuit breaking rule
Circuit breaking rules are used to lower the dependency priority of a route immediately if the system detects that the response time (RT) of requests or the percentage of abnormal requests on the route reaches a specified threshold. If circuit breaking is triggered, the system does not call the requests on the route in the specified period of time. This ensures high availability of backend services. After the specified period of time elapses, the system resumes the calls to the requests on the route.
On the Throttling tab, click the Fuse rule subtab.
On the Fuse rule subtab, configure the parameters.
Parameter
Description
Statistical window duration
The length of the time window. The valid range is from 1 second to 120 minutes.
Minimum number of requests
The minimum number of requests to trigger circuit breaking. If the number of requests in the current time window is less than the value of this parameter, circuit breaking is not triggered even if the circuit breaking rule is met.
Threshold Type
Valid values: Slow call ratio (%) and Abnormal proportion (%).
If you set this parameter to Slow call ratio (%), you must configure the Slow call RT parameter. The Slow call RT parameter specifies a threshold for the response time of requests. If the response time of a request exceeds the value of the Slow call RT parameter, the request is counted as a slow call. Set the downgrade threshold to a threshold for the percentage of slow calls. After the rule is enabled, if the number of requests that are initiated in a specified period of time is greater than the specified minimum number of requests and the percentage of slow calls is greater than the specified threshold, circuit breaking is automatically implemented on requests that are processed in the next circuit breaking period. After the circuit breaking period elapses, the circuit breaker starts to detect the RT of the next request. If the RT of the next request is less than the value of the Slow call RT parameter, circuit breaking ends. If the RT of the next request is greater than the value of the Slow call RT parameter, circuit breaking is retriggered.
If you select Abnormal proportion (%), you must set the downgrade threshold to a threshold for the percentage of abnormal requests. After the circuit breaking rule is enabled, if the number of abnormal requests in a specified period of time is greater than the specified minimum number of requests and the percentage of abnormal requests is greater than the specified threshold, circuit breaking is automatically implemented on requests that are processed in the next circuit breaking period.
Fusing time (s)
The period in which circuit breaking is implemented. If circuit breaking is implemented on the requests for the route, the calls to all the requests for the route fail in the configured circuit breaking period.
Web Fallback Behavior
Select Return Specified Content or Go to Specified Page for Web Fallback Behavior.
If you set Web Fallback Behavior to Go to Specified Page:
Redirect URL
Enter the address to be redirected to.
If you set Web Fallback Behavior to Return Specified Content:
HTTP Status Code
Enter the HTTP status code. The default value is 429.
Returned Content Type
Select Plain Text or JSON for Returned Content Type.
Returned HTTP Text
Enter the returned text.
Enable
If you turn on this switch, the configured throttling rule takes effect.
Click Create or Save to create or update the rule.
Gateways from 1.1.0 to 1.2.24
Configure a throttling rule
Throttling rules are used to block traffic immediately if the system detects that the QPS of a route reaches a specified threshold. This prevents a breakdown of backend services due to traffic surges and ensures high availability of backend services.
On the Throttling tab, click the Throttling Rules subtab, and click Add Throttling Rule.
In the Add Throttling Protection Rule dialog box, configure the parameters.
In the Configure a Throttling Rule step, enter a value in the Overall QPS Threshold field and turn on the Whether to open switch. Then, click Next to configure the throttling behavior.
In the Configure Throttling Behavior step, click New behavior to configure the HTTP response behavior after throttling is enabled.
After you configure the throttling behavior, click New.
Configure a concurrency rule
Concurrency rules are used to block traffic immediately if the system detects that the total number of requests that are being processed by a gateway reaches a specified threshold. When you configure concurrency rules, you can specify the maximum number of concurrent requests that can be processed by backend services. This ensures availability of backend services in scenarios in which a large number of concurrent requests are initiated.
On the Throttling tab, click the Concurrency Rules subtab, and click Add Concurrency Rules.
In the Add Concurrency Protection Rule dialog box, configure the parameters.
In the Configure a Protection Rule step, enter a value in the Overall Request Concurrency Threshold field and turn on the Whether to open switch. Then, click Next to configure the throttling behavior.
In the Configure Throttling Behavior step, click Add Behavior to configure the HTTP response behavior after throttling is triggered.
After you configure the throttling behavior, click New.
Configure a circuit breaking rule
Circuit breaking rules are used to lower the dependency priority of a route immediately if the system detects that the RT of requests or the percentage of abnormal requests on the route reaches a specified threshold. If circuit breaking is triggered, the system does not call the requests on the route in the specified period of time. This ensures high availability of backend services. After the specified period of time elapses, the system resumes the calls to the requests on the route.
On the Throttling tab, click the Fuse rule subtab, and click Added fusing rule.
In the Add Circuit Breaking Protection Rule dialog box, configure the parameters.
In the Configure a Protection Rule step, enter a value in the Overall Request Concurrency Threshold field and turn on the Whether to open switch. Then, click Next to configure the throttling behavior.
Parameter
Description
Statistical window duration
The length of the time window. The valid range is from 1 second to 120 minutes.
Minimum number of requests
The minimum number of requests to trigger circuit breaking. If the number of requests in the current time window is less than the value of this parameter, circuit breaking is not triggered even if the circuit breaking rule is met.
Threshold Type
Valid values: Slow call ratio (%) and Abnormal proportion (%).
If you select Slow call ratio (%), you must specify the Slow call RT parameter. The Slow call RT parameter specifies the maximum RT. If the RT of a request is greater than the value of the Slow call RT parameter, a slow call is counted. Set the downgrade threshold to a threshold for the percentage of slow calls. After the rule is enabled, if the number of requests that are initiated in a specified period of time is greater than the specified minimum number of requests and the percentage of slow calls is greater than the specified threshold, circuit breaking is automatically implemented on requests that are processed in the next circuit breaking period. After the circuit breaking period elapses, the circuit breaker starts to detect the RT of the next request. If the RT of the next request is less than the value of the Slow call RT parameter, circuit breaking ends. If the RT of the next request is greater than the value of the Slow call RT parameter, circuit breaking is retriggered.
If you select Abnormal proportion (%), you must set the downgrade threshold to a threshold for the percentage of abnormal requests. After the rule is enabled, if the number of abnormal requests in a specified period of time is greater than the specified minimum number of requests and the percentage of abnormal requests is greater than the specified threshold, circuit breaking is automatically implemented on requests that are processed in the next circuit breaking period.
Fusing time (s)
The period in which circuit breaking is implemented. If circuit breaking is implemented on the requests for the route, the calls to all the requests for the route fail in the configured circuit breaking period.
Fuse recovery strategy
Specifies whether a circuit breaker retriggers circuit breaking after the circuit breaking period elapses.
If you select Single probe recovery, the circuit breaker detects the status of the next request after the circuit breaking period elapses. If no slow request calls occur or the request is normal, circuit breaking ends. Otherwise, circuit breaking is retriggered.
In the Configure Throttling Behavior step, click Add Behavior to configure the HTTP response behavior after throttling is triggered.
After you configure the throttling behavior, click New.
Run the following command to send a test request:
curl -I http://121.196.XX.XX/demo/item/list
The following result is returned. After you enable a throttling policy, the HTTP status code 429 is returned.
HTTP/1.1 429 Too Many Requests x-local-rate-limit: true content-length: 18 content-type: text/plain date: Mon, 29 Nov 2021 08:28:01 GMT server: istio-envoy
Monitoring and alerting
Cloud-native gateways provide the monitoring center and log center features. You can use these features to view monitoring data. Cloud-native gateways also provide the alerting feature based on Application Real-Time Monitoring Service (ARMS). If alert conditions are met, MSE sends alert notifications by using emails, SMS messages, and DingTalk. This feature helps you identify exceptions in real time.
View monitoring data
Log on to the MSE console.
In the top navigation bar, select a region.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.
In the left-side navigation pane, click Observation Analysis and select the following items to view monitoring data based on your business requirements:
Business Monitoring: Displays the overall access statistics on the gateway.
Log Center: Displays the access logs of the gateway.
Resource Monitoring: Displays the resource usage of the gateway node.
You can use the observation analysis feature to perform business monitoring and manage monitoring data. For more information, see View the monitoring data of a cloud-native gateway.
Configure an alert contact
Log on to the MSE console, and select a region in the top navigation bar.
In the left-side navigation pane, choose Cloud-native Gateway > Alerts > Contacts.
On the Contacts tab, click Create Contact in the upper-right corner.
In the Create Contact dialog box, configure the parameters and click OK. For more information, see Manage alert contacts.
Configure an alert rule
Log on to the MSE console, and select a region in the top navigation bar.
In the left-side navigation pane, choose Cloud-native Gateway > Alerts > Policies.
In the upper-right corner of the Cloud-native Gateway Alert Policy Management page, click Create Cloud-native Gateway Alerts.
On the Create Gateway Alert Rule page, configure the parameters and click Save. For more information, see Manage an alert rule.
Canary release
Cloud-native gateways also support other routing methods, such as single-service routing, multi-service routing, and tag-based routing. For more information, see Routing modes.
Configure weight values for multiple versions of a service
Log on to the MSE console. In the top navigation bar, select a region.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.
In the left-side navigation pane, choose Service Management > Services.
On the Services page, click the name of the desired service.
In the Service Version section, click Add Version on the right side. Then, configure the Version Name, Tag Name, and Tag Value parameters and click the icon in the Actions column. In this step, services of v1 and v2 are deployed. For more information, see Manage service versions.
On the Route Settings page, find the route that you want to modify and click Edit in the Actions column. In the Destination Service step, select Tag-based Routing for Destination Service, and click Save and Release. For more information about how to change a routing method, see Modify a routing rule.
Run the following command to send a test request:
curl http://121.196.XX.XX/version
The following result is returned:
version:v2 (returned in 20% of the responses) version:v1 (returned in 80% of the responses)
Configure an authentication method for a gateway
Cloud-native gateways support multiple authentication methods, such as JSON Web Token (JWT), OpenID Connect (OIDC), Identity as a Service (IDaaS), and custom authentication. For more information, see Gateway authentication.
Configure JWT authentication
Log on to the MSE console. In the top navigation bar, select a region.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.
In the left-side navigation pane, choose Security Management > Authentication.
In the left-side navigation pane of the Overview page, click Global Authentication. In the upper-left corner of the page that appears, click Create Authentication. In the Create Authentication panel, configure the parameters and click OK. For more information, see Configure JWT authentication.
Run the following command to send a test request that does not contain a token:
curl -I http://121.196.XX.XX/
The following result is returned. After you enable JWT authentication, a request without a token is rejected and the HTTP status code 403 is returned.
HTTP/1.1 403 Forbidden content-length: 19 content-type: text/plain date: Tue, 30 Nov 2021 09:35:09 GMT server: istio-envoy
Run the following command to send a test request that contains a token:
curl -I -H "Authorization: Bearer $TOKEN" http://121.196.XX.XX/
The following result is returned:
HTTP/1.1 200 OK content-type: text/html; charset=utf-8 content-length: 1683 server: istio-envoy date: Tue, 30 Nov 2021 09:35:59 GMT x-envoy-upstream-service-time: 5