All Products
Search

This Product

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

    Document Center

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

    Last Updated:Jun 17, 2026

    You can configure gateway routing for your application to distribute requests to other services or applications. The routing rules are managed through a Microservices Engine (MSE) cloud-native gateway.

    Background information

    MSE cloud-native gateways are compatible with Kubernetes Ingresses, support service discovery 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

      A custom name for the routing rule.

      Network Type

      The network type for request forwarding.

      • 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

      The request path used 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 To > Prefix > Regular Expression Match.

        • Equal To: 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 Match: a regular expression-based match. For example, the character class is user.

      Method

      The HTTP method used to match requests. If left empty, all methods are matched. You can select multiple methods.

      Header

      The HTTP header used to match requests. If multiple rules share the same matching type, the rule with more header parameters takes priority.

      Query

      The query string parameter used to match HTTP requests. If multiple rules share the same matching type, the rule with more query parameters takes 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 Namespace of MSE Nacos Instance.

      Note

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

      Scenario

      The destination service type for the route.

      • Basic scenario

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

      • Canary release scenario

        • By Percentage (Multi-service): Requests are distributed to multiple backend services based on specific percentages. This is often used in traffic shifting and canary release scenarios.

        • Tag (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 Services

      The backend application, service, and port to associate with the route.

      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 (Seconds)

      The timeout period in seconds. Default value: 60. A value of 0 means the request never times out.

      Advanced Settings

      Fallback

      Turn on Fallback and select a fallback service. If no node is available for the backend service that the route points to, requests are forwarded to 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 configuration, or edit or delete the rule on the Gateway Routing page.