Service versions are used for the tag-based routing feature that is configured for routes of a cloud-native gateway. You can configure tag-based routing policies for routes to meet requirements in scenarios such as canary releases, tag-based routing, and high-availability deployments. This topic describes how to configure a service version for a service that is added to a cloud-native gateway.
Background information
In microservices, services are defined as functional units of an application. Services are specific to fields such as order service and user service. Physically, services are deployed and run on physical machines, virtual machines, or inside containers with network addresses. Logically, a service consists of nodes that provide the same features.
Nodes of a service can be divided into different subsets based on the metadata on the nodes. A service version is referred to as a subset of nodes. Service versions are typically used in canary releases, tag-based routing, and high-availability deployments.
Canary releases: New versions of a service are frequently released across service iterations. To ensure service stability and continuity, developers use the canary release feature to perform service updates in most cases. If you perform a canary release to test the new version, a small percentage of traffic is routed to the new version. If the test result meets your expectation, the remaining traffic is gradually routed to the new version.
Tag-based routing: In business scenarios, multiple versions of a service may exist in parallel. Features of versions are different and applied to information-specific requests. For example, when an API operation is called, requests with different header values are forwarded to different versions of the service. Tag-based routing is also used in the scenario where multiple development environments such as test, staging, and production environments coexist. You can use service versions to forward requests to different development environments based on the request information.
High-availability deployments: To ensure service availability, identical services may be deployed on multiple Kubernetes clusters. You can manage all service instances by cluster based on the cluster metadata on the nodes. You can also adjust the weightage to distribute traffic to clusters. If a cluster fails, you can set the traffic weight to 0 for the cluster, and all traffic is then forwarded to other clusters.
Service version management depends on the metadata on service nodes.
For services in Container Service for Kubernetes (ACK) clusters, the metadata on service nodes is determined by the
Labelsattributes of pods. For example, if you register a Spring Cloud application with an instance in the ACK cluster, you can add the tag name and tag value tospec.template.metadata.labelsin the deployment.yaml file of the ACK cluster.For services that use the Nacos registry, the metadata on service nodes are configured when the service application is registered in the registry.
For example, if you register a Spring Cloud application with a Nacos instance, you can specify the spring.cloud.nacos.discovery.metadata field to determine the metadata on nodes.
Limits
You cannot manage the service versions of services whose Service Source is set to Fixed Address.
You cannot manage the service versions of services whose Service Source is set to DNS Domain Name.
Add a service version
Log on to the MSE console. In the top navigation bar, select a region.
In the left-side navigation pane, choose . On the Gateways page, click the name of the gateway.
In the left-side navigation pane, choose .
On the Services page, click the name of the desired service.
In the Service Version section of the page that appears, click Add Version.
In the Service Version section, configure the Version Name, Tag Name, and Tag Value parameters. Then, click the
icon in the Actions column. 
The following table describes the parameters in the Service Version section.
Parameter
Description
Version Name
Specify a name for the service version. We recommend that you use a short and descriptive name.
Tag Name
Select a tag name from the drop-down list. Tag names are used to identify a full set of keys that indicate the metadata on all nodes of a service. You must select a key to distinguish a set of service nodes for the service version that you want to add.
Tag Value
Select a tag value from the drop-down list. Tag values are used to identify a full set of values that correspond to the keys specified by Tag Name. You must select a value to further narrow down the scope of service nodes for the service version that you want to add.
Number of Instances/Proportion
Number of Instances: the number of service nodes that are identified by the specified tag name and tag value. These nodes belong to the service version that you want to add.
Proportion: the proportion of service nodes that belong to the new service version to all service nodes.
NoteTag Name and Tag Value are used together to identify instances of the service version that you want to add.
In the message that appears, click OK.
The added service version is displayed in the Service Version section.
What to do next
Modify a service version
In the Service Version section, find the desired service version and click the
icon in the Actions column. Modify the settings of Tag Name and Tag Value, and click the
icon in the Actions column. In the message that appears, click OK.
Delete a service version
In the Service Version section, find the desired service version and click the
icon in the Actions column. In the message that appears, click OK.