All Products
Search
Document Center

Serverless App Engine:Create and manage a route for an application (MSE)

Last Updated:Aug 06, 2025

To distribute business requests to other services or applications, you can configure the gateway routing feature for your application to route and distribute the requests. This topic describes how to set a routing rule for an application using a Microservices Engine (MSE) cloud-native gateway.

Background information

MSE cloud-native gateways are compatible with Kubernetes Ingresses. These gateways can discover services from sources such as Container Service for Kubernetes (ACK) and Nacos, and provide various security and O&M capabilities.

Prerequisites

Create a routing rule

  1. In SAE Gateway Routing, select the destination region and namespace at the top of the page, and then click Create Gateway Route.

  2. On the Create Route page, configure the parameters and then click Save.

    Configuration Item

    Description

    Route Name

    The name of the routing rule. You can specify a custom name.

    Network Type

    Select the network type of the requests that you want to forward.

    • Internet: You are charged for the traffic that is forwarded by an Internet-facing gateway.

    • Private Network: You are not charged for the traffic that is forwarded by an internal-facing gateway because traffic is forwarded only within the VPC.

    Gateway Type

    Select MSE Cloud-native Gateway.

    Gateway Instance

    This parameter is required if you set Gateway Type to MSE Cloud-native Gateway. Select a gateway instance that resides in the same region and VPC as the namespace. To create a gateway instance, you can click Create MSE Cloud-native Gateway. For more information, see Create an MSE cloud-native gateway.

    Domain Name

    Select one or more domain names that you want to match. To create a domain name, you can click Create Domain Name. For more information, see Create a domain name.

    Path

    Set the Path parameter to match HTTP requests.

    • If multiple rules have the same matching type, the rule with the longer path has a higher priority.

    • If multiple rules have different matching types, the priority is Equal > Prefix > Regular Expression.

      • Equal: an exact match. For example, the path is equal to /user.

      • Prefix: a prefix-based match. For example, the path starts with /user.

      • Regular expression: a regular expression-based match. For example, the character class is user.

    Method

    Set the Method parameter to match HTTP requests. If you leave this parameter empty, all methods are matched. You can select multiple HTTP methods.

    Request Header

    Set the Header parameter to match HTTP requests. If multiple rules have the same matching type, the rule with more parameters has a higher priority.

    Request Parameter (Query)

    Set the Query parameter to match HTTP requests. If multiple rules have the same matching type, the rule with more parameters has a higher priority.

    Service Source

    Two types of registries are supported: SAE Built-in Nacos and MSE Nacos.

    • SAE Built-in Nacos: SAE automatically modifies the addresses of the registry and configuration center of the program by injecting related environment variables and using a Java agent to modify bytecode.

    • MSE Nacos: If you select this option, you must set MSE Nacos Instance and MSE Nacos Namespace.

    Note

    The service source must be the same as the service discovery method of the application.

    Scenarios

    Select the type of the destination service for the current route.

    • Basic scenario

      Single Service: Requests are distributed to a single backend service. This is the most common scenario.

    • Canary release scenario

      • Multiple Services: Requests are distributed to multiple backend services based on specific percentages. This is often used in traffic shifting and canary release scenarios.

      • Tag-based Routing: Requests are distributed to multiple backend services based on content or specific percentages. To implement the end-to-end canary release feature, you must use this feature with service administration.

    For more information about the types of destination services, see Overview of routing methods.

    Backend Service

    Select the associated backend application, service, and port.

    Note
    • The sum of the traffic weights of the destination services must be 100%.

    • Tag-based routing takes effect only for the first hop from the gateway to the backend service. If you want to implement canary release for the entire request link, you must use this feature with the end-to-end canary release feature.

    Timeout (s)

    Enter the timeout period. The default value is 60. Unit: seconds. A value of 0 indicates that the request never times out.

    Advanced Configuration

    Fallback

    Turn on the Fallback switch and set the fallback service. You need to select a specific service. If no node is available for the backend service to which the route points, the original request accesses the specified fallback service.

    Note

    Currently, the fallback feature is supported only between HTTP services.

    After the routing rule is created, you can view, edit, and manage the rule on the Gateway Routing page.

Manage a routing rule

After you create a routing rule, you can view its traffic forwarding rule, or edit or delete the routing rule on the Gateway Routing page.