Microservices Engine:Dive deeper into cloud-native gateways

Configure a Container Service for Kubernetes (ACK) cluster as a service source

1. In the left-side navigation pane, choose Service Management > Sources.

2. In the upper-left corner of the Sources page, click Add Source.

3. 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

1. In the left-side navigation pane, choose Service Management > Services.

2. In the upper-left corner of the Services page, click Add Service.

3. 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 no route

1. Log on to the MSE console. In the top navigation bar, select a region.

2. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.

3. On the Gateway Ingress tab of the Overview page, view the Ingress IP Address of the gateway.

   Note

   The 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.

4. 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.

1. 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.

2. In the Add Route panel, configure the parameters and click Save and Release.

   1. 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.

   2. In the Destination Service step, select Mock for Destination Service, and configure the Status Code and Response Content parameters.

3. 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 no routing policies

1. Log on to the MSE console.

2. In the top navigation bar, select a region.

3. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.

4. In the left-side navigation pane of the Overview page, choose Routes > Route Settings.

5. Run the following command to send a test request:

   curl -I http://121.196.XX.XX/demo/item/list 

   Note

   The 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.

1. On the Route Settings page, find the route whose routing rule you want to modify, and click Policies in the Actions column.

2. 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.

     1. On the Throttling tab, click the Throttling Rules subtab.

     2. 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.

     3. 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.

     1. On the Throttling tab, click the Concurrency Rules subtab.

     2. 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.

     3. 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.

     1. On the Throttling tab, click the Fuse rule subtab.

     2. 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.

     3. 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.

     1. On the Throttling tab, click the Throttling Rules subtab, and click Add Throttling Rule.

     2. In the Add Throttling Protection Rule dialog box, configure the parameters.

        1. 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.

        2. In the Configure Throttling Behavior step, click New behavior to configure the HTTP response behavior after throttling is enabled.

     3. 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.

     1. On the Throttling tab, click the Concurrency Rules subtab, and click Add Concurrency Rules.

     2. In the Add Concurrency Protection Rule dialog box, configure the parameters.

        1. 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.

        2. In the Configure Throttling Behavior step, click Add Behavior to configure the HTTP response behavior after throttling is triggered.

     3. 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.

     1. On the Throttling tab, click the Fuse rule subtab, and click Added fusing rule.

     2. In the Add Circuit Breaking Protection Rule dialog box, configure the parameters.

        1. 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.

        2. In the Configure Throttling Behavior step, click Add Behavior to configure the HTTP response behavior after throttling is triggered.

     3. After you configure the throttling behavior, click New.

3. 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

View monitoring data

1. Log on to the MSE console.

2. In the top navigation bar, select a region.

3. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.

4. 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

1. Log on to the MSE console, and select a region in the top navigation bar.

2. In the left-side navigation pane, choose Cloud-native Gateway > Alerts > Contacts.

3. On the Contacts tab, click Create Contact in the upper-right corner.

4. In the Create Contact dialog box, configure the parameters and click OK. For more information, see Manage alert contacts.

Configure an alert rule

1. Log on to the MSE console, and select a region in the top navigation bar.

2. In the left-side navigation pane, choose Cloud-native Gateway > Alerts > Policies.

3. In the upper-right corner of the Cloud-native Gateway Alert Policy Management page, click Create Cloud-native Gateway Alerts.

4. On the Create Gateway Alert Rule page, configure the parameters and click Save. For more information, see Manage an alert rule.