Service publishing method, service routing method, device, system, storage medium, and program product

Abstract

Embodiments of the present disclosure provide a service publishing method, a service routing method, a device, a system, a storage medium, and a program product. In the embodiments of the present disclosure, a grayscale version of a target service, on a baseline link, that needs to be upgraded is deployed in a baseline environment; according to a multi-level rollback routing rule, grayscale traffic rolls back from a characteristic version in a characteristic environment to the grayscale version in the baseline environment and then to a baseline version, such that the grayscale traffic is directed to the characteristic version and the grayscale version, and the verification of the grayscale version is completed without affecting the operation of the characteristic version of the service; and when the verification is passed, the baseline traffic on the baseline link is switched onto the grayscale link to perform a lossless full-link upgrade of the target service to the grayscale version. After all the baseline traffics are switched, a lossless full-link upgrade of the target service on the baseline link to the grayscale version is performed. The baseline traffic is switched when the verification is passed, so that the problem of incompatibility between new and old versions is avoided, and thus there is no need to worry about traffic loss.

Description

Service publishing and routing methods, devices, systems, storage media, and application products Technical Field

[0001] This disclosure relates to the field of microservices technology, and in particular to a service publishing and routing method, device, system, storage medium, and program product. Background Technology

[0002] Microservice architecture is a software architecture design pattern that breaks down an application into multiple independent services. These services depend on and call each other, but each service can be developed independently. This gives application development a significant advantage in terms of flexibility and efficiency. As a result, more and more enterprises are starting to adopt microservice architecture for application development.

[0003] Application development involves multiple stages such as development, testing, integration, deployment, and production. In order to ensure that developers in different stages can work in parallel without affecting each other, the concept of multiple isolated environments is proposed under the microservice architecture. This allows multiple isolated environments such as development environment, testing environment, and production environment to coexist. Due to the dependencies between services, each environment must include at least a relatively complete service with dependencies in order for each environment to run normally.

[0004] As the scale of microservice architectures increases and the dependencies between services become more complex, the number of developers grows, and the demand for isolated environments increases. If physically isolated environments are deployed, each environment requires a large amount of physical resources to support a series of dependent services, which can be very costly.

[0005] Therefore, a solution of logically isolating multiple environments has emerged, which involves physically deploying a baseline environment, deploying complete services in the baseline environment, and then using the local environment of the developers as a feature environment (such as a test environment) based on the baseline environment. Only the services that need to be processed need to be deployed in the feature environment, while other services reuse those in the baseline environment. This saves the physical resources required to repeatedly deploy other services and reduces implementation costs.

[0006] The normal operation of services in the aforementioned special environment depends on services in the baseline environment, which places high demands on the stability of services in the baseline environment. Therefore, how to perform a full-link lossless upgrade of services in the baseline environment without affecting the normal operation of services in the special environment has become a major technical challenge. Summary of the Invention

[0007] This disclosure provides a service publishing and routing method, device, system, storage medium, and program product for performing end-to-end lossless upgrades of services in a baseline environment without affecting the normal operation of services in a specific environment.

[0008] This disclosure provides a service publishing method applied to an application system including multiple services. The application system includes a baseline environment and at least one feature environment. The baseline environment deploys baseline versions of the multiple services, and the feature environment is empty or deploys a feature version of at least one service. The method includes: if a canary release of a target service in the baseline environment is required, deploying a first canary version of the target service in the baseline environment; dividing access traffic entering the baseline environment into canary traffic and baseline traffic, wherein the access traffic includes at least tagged access traffic from at least some feature environments; and routing the canary service according to a multi-level fallback routing rule. Gray-scale traffic is routed to a gray-scale link to verify the first gray-scale version. The gray-scale link includes the service node where the first gray-scale version is located. If the verification is successful, the baseline traffic is switched from the baseline link to the gray-scale link according to the multi-level fallback routing rules. The baseline link includes the service node where the baseline version of the target service is located. The multi-level fallback routing rules include: for access traffic with tags, service nodes on the gray-scale link are selected in the order of fallback from the feature version to the gray-scale version and then to the baseline version; for access traffic without tags, service nodes on the gray-scale link are selected in the order of fallback from the gray-scale version to the baseline version.

[0009] This disclosure provides a service publishing method and a service routing method, applied to service nodes in a baseline environment or a feature environment of an application system. The service nodes deploy any service on a grayscale link where a target service resides, and multi-level fallback routing rules are pre-configured. The target service is a service that needs to be grayscale published. The method includes: receiving first access traffic, where the first access traffic is grayscale traffic or baseline traffic; if the first access traffic is identified as having a tag according to the multi-level fallback routing rules, selecting the next service node on the grayscale link in the fallback order from the feature version to the grayscale version and then to the baseline version; if the first access traffic is identified as not having a tag according to the multi-level fallback routing rules, selecting the next service node on the grayscale link in the fallback order from the grayscale version to the baseline version; and sending the first access traffic to the next service node on the grayscale link.

[0010] This disclosure also provides a control device, including a memory and a processor. The memory is used to store a computer program, and the processor is coupled to the memory to execute the computer program to implement the steps in the various methods provided in this disclosure.

[0011] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, enables the processor to perform the steps in the methods described above.

[0012] This disclosure also provides a computer program product, which includes a computer program / instructions that, when executed by a processor, enable the processor to perform the steps described in the method embodiments above.

[0013] This disclosure also provides an application system, including: a baseline environment and at least one feature environment; the baseline environment deploys baseline versions of multiple services, and the feature environment is empty or deploys a feature version of at least one service; wherein, a first grayscale version of a target service is also deployed in the baseline environment, and the target service is at least one of the multiple services that needs to be grayscale released; the application system further includes: a management and control device; the management and control device is used to execute the steps in the service release method to achieve end-to-end lossless release of the target service.

[0014] In this embodiment, the grayscale version of the target service to be upgraded on the baseline link is deployed in the baseline environment. Through multi-level fallback routing rules, the grayscale traffic is allowed to fall back from the feature version in the feature environment to the grayscale version in the baseline environment and then back to the baseline version. This allows the grayscale traffic to be successfully guided to the feature version and the grayscale version, thereby completing the verification of the grayscale version of the target service without affecting the normal operation of the feature version of the service in the feature environment. If the verification is successful, the baseline traffic on the baseline link is switched to the grayscale link, so that the target service can be upgraded to the grayscale version without loss of time throughout the entire link.

[0015] Furthermore, in an optional embodiment of this disclosure, after all baseline traffic on the baseline link is switched to the grayscale link, no traffic passes through the target service on the baseline link. In this case, the target service on the baseline link can be upgraded to the grayscale version without loss throughout the entire link. In addition, since the baseline traffic is switched to the grayscale version of the target service after verification, incompatibility issues between the old and new versions are avoided, and there is no need to worry about traffic loss.

[0016] Furthermore, in the optional embodiments of this disclosure, during the verification of the grayscale version, since the baseline version still exists, if the verification of the grayscale version fails, it can be quickly rolled back without involving the redeployment of the baseline version, and the rollback cost is low. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of this disclosure and are used to explain this disclosure, but do not constitute an undue limitation of this disclosure.

[0018] Figure 1a is a schematic diagram of a service call chain structure provided by an exemplary embodiment of this disclosure.

[0019] Figure 1b is a schematic diagram of the structure of a microservice application system employing physical isolation, provided in another exemplary embodiment of this disclosure.

[0020] Figure 1c is a schematic diagram of the structure of a microservice application system with logical isolation provided by another exemplary embodiment of this disclosure.

[0021] Figure 2a is a schematic diagram of the first grayscale version verification process of a microservice application system provided by another exemplary embodiment of this disclosure.

[0022] Figure 2b is a schematic diagram of the status of a microservice application system after the first grayscale version verification is passed, provided by another exemplary embodiment of this disclosure.

[0023] Figure 2c is a schematic diagram of the second grayscale version verification process of a microservice application system provided by another exemplary embodiment of this disclosure.

[0024] Figure 2d is a schematic diagram of the status of a microservice application system after the second grayscale version verification is passed, provided by another exemplary embodiment of this disclosure.

[0025] Figure 3 is a flowchart illustrating a service publishing method provided in an exemplary embodiment of this disclosure.

[0026] Figure 4 is a flowchart illustrating a service routing method provided in an exemplary embodiment of this disclosure.

[0027] Figure 5 is a schematic diagram of the structure of a control device provided in another exemplary embodiment of this disclosure. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0029] It should be noted that, in the cases involving user information in the embodiments of this disclosure, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards.

[0030] In a microservices architecture, a monolithic application is broken down into independent services, each undertaking a specific function. These services are interdependent. Each request entering the microservices application system may be processed by multiple dependent services before returning a response. These dependent services form a service call chain, providing a relatively complete service to the outside world. A service call chain refers to the complete path from the initiating service to the final response service in an application system for a given request. A service call chain describes the call relationships between at least multiple services, and the service chain may differ for different requests.

[0031] Figure 1a shows a schematic diagram of a service call chain provided in an exemplary embodiment of this disclosure. As shown in Figure 1a, the chain includes services A, B, C, D, E, and F. For ease of description, services can be referred to by their English suffixes; for example, service A can be abbreviated as A. Multiple services in the chain have dependencies on each other, such as dependencies between A and B, A and C, C and D, C and E, and between E and F. These dependent services form a service call chain. For example, Figure 1a includes three service call chains: A→B; A→C→D; and A→C→E→F. Taking the service call chain A→C→E→F as an example, when A receives a request from a client, it calls C, C then calls E, E then calls F, and the processing result is returned to A along the original path, and A returns a response to the client. For information on A→B and A→C→D, please refer to the content on A→C→E→F.

[0032] As microservice application systems grow rapidly in scale and the dependencies between services become increasingly complex, developers often find it impossible to complete development locally due to these dependencies. Therefore, a complete environment is necessary to meet the development, testing, and integration needs of the application. Based on this, microservice application systems can employ physical isolation, setting up multiple isolated environments. Each isolated environment should contain at least the relatively complete services with dependencies.

[0033] Figure 1b shows a schematic diagram of a microservice application system with physical isolation. In this application system, there is a baseline environment and multiple development environments. Taking two development environments as an example, they are development environment 1 and development environment 2.

[0034] The baseline environment and the development environment each deploy complete services and have the same physical resource quota. The physical resources included in the baseline environment and the development environment can be service nodes. In Figure 1b, the number of service nodes in the baseline environment is the same as that in the feature environment. Service nodes can be any electronic device with computing, storage and communication functions, such as computers, mobile phones, tablets and other terminal devices, or traditional servers, cloud servers, server clusters or workstations and other server-side devices, without any restrictions.

[0035] The application system's services are deployed on service nodes. Each service node comprises multiple Pods. A Pod is the basic unit for container deployment and management; it can be viewed as a collection of one or more containers, each used to deploy a service. For example, a Pod encapsulates a container, which runs a service. Different versions of any service can be deployed in different Pods. Thus, one Pod runs one version of the service, and multiple Pods can run different versions of the service. These multiple Pods can be located on different service nodes to improve service disaster recovery capabilities.

[0036] Furthermore, as shown in Figure 1b, at least some services in the baseline environment and the development environment have different versions. The baseline environment includes A, C, E, and F, where each service is version V1. The development environment is deployed for developers, who can set up the corresponding development environment when iterating on one or more services in the baseline environment. Except for the services that need to be iterated, i.e., the gray-scale versions of those services, the other services in the development environment can be the same as those in the baseline environment. For example, development environment 1 is deployed to iterate A and E from V1 to V1.1, where V1.1 is a gray-scale version of V1, and the other services such as C and F can be the same as the versions of C and F in the baseline environment. Similarly, development environment 2 is deployed to iterate E from V1 to V1.2, where V1.2 is a gray-scale version of V1, and the other services such as A, C, and F can be the same as the versions of A, C, and F in the baseline environment.

[0037] Based on the above, physical isolation between environments leads to relatively complex deployment environments, and there may also be multiple physically isolated development environments iterating in parallel. Furthermore, for some ultra-large-scale microservice systems, involving development teams of several hundred people and serving over a hundred services, and still growing rapidly, potentially reaching or even surpassing the industry benchmark T3's scale of thousands of services in the future, the annual machine cost per development environment would be extremely high if each developer had a relatively independent isolated environment. Moreover, this doesn't even include labor costs, which increase exponentially with the increase in development environments.

[0038] Therefore, a multi-feature environment scheme based on logical isolation emerged, as shown in Figure 1c. This involves deploying complete services in a baseline environment. The baseline environment is a complete and stable foundational environment, possessing integrity and stability. As shown in Figure 1c, the baseline environment includes A, C, E, and F, with each service version V1. The core of this scheme is maintaining the stability of the baseline environment. The baseline environment can be any environment in the development process, such as development, testing, or production. Then, based on the baseline environment, the developers' local environments are used as feature environments (e.g., testing environments, development environments, etc.). For example, the development environment in Figure 1c is one example of a feature environment, but it is not limited to this. A feature environment refers to an environment that depends on the baseline environment. Different feature environments are isolated from each other. Each feature environment requires only a small amount of physical resources to deploy services that need to be iterated, while other services can reuse those in the baseline environment.

[0039] When application systems employ logical isolation, feature environments can reuse services from the baseline environment. When there are needs for service development, testing, or integration testing in a feature environment, only a feature version of the service needs to be deployed there. This feature version can be a development version, a test version, or a integration testing version of the service. Developers in the feature environment can then initiate access traffic for that feature version. This access traffic is required for development, testing, or integration testing of the feature version. As this access traffic flows through the service call chain to which the service belongs, the gateways and service nodes it passes through identify whether the access traffic carries a tag for a feature environment (such as a development environment). If the access traffic is tagged, it is routed to the feature environment with the corresponding tag, thus fulfilling the feature requirements for service development, testing, or integration testing in the feature environment.

[0040] For example, when a request enters an application system, it triggers sequential calls between multiple services. The feature version of the upstream service will pass the request to the feature version of the downstream service. If a service does not have a feature version, the request will be routed to the stable version of that service; if a service has a feature version, the request will be routed to that feature version. The following description uses the application system in Figure 1c as an example.

[0041] As shown in Figure 1c, development environment 1 only needs to include versions V1.1 of A and E. Versions V1.1 of A and E can be considered as feature versions of A and E. Development environment 2 only needs to include version V1.2 of E. Version V1.2 of E can be considered as another feature version of E. The calling relationships between multiple services A, C, E and F can be seen in Figure 1a.

[0042] When a request carrying tag 1 enters the gateway, the gateway first routes the request traffic to version V1.1 of A in development environment 1, corresponding to tag 1. Further, based on the call relationship of tag 1 and the service call chain, the request traffic should be routed to version V1.1 of C in development environment 1. However, version V1.1 of C does not exist in development environment 1, so it falls back from version V1.1 of C to version V1 of C, thus routing the request traffic to C in the baseline environment. Further, based on the call relationship of tag 1 and the service call chain, the request traffic is routed to version V1.1 of E in development environment 1. Since version V1.1 of F does not exist in development environment 1, it falls back from version V1.1 of F to version V1 of F, thus routing the request traffic to F in the baseline environment. Development environments 1 and 2 can reuse the services of the baseline environment, thus saving the physical resources required for redundant deployment of other services and reducing implementation costs. The routing process for a request carrying tag 2 entering the gateway can be referred to the routing process for a request carrying tag 1, and will not be repeated here.

[0043] As shown in the example in Figure 1c, access traffic carrying tags is routed to the corresponding feature version in the feature environment (such as the development environment) to achieve the purpose of developing, testing, or integrating the feature version. Verification methods for gray-scale versions can include, but are not limited to, functional testing, performance testing, and integration testing with external systems to ensure that the gray-scale version can function normally. After successful verification, the baseline environment is then upgraded, thereby ensuring the stability of the baseline environment.

[0044] As discussed above, service development, testing, and integration in a specialized environment (such as a development environment) rely on services in the baseline environment. This places high demands on the stability of these services. The service upgrade process in the baseline environment is a major factor leading to instability. Therefore, ensuring that service upgrades in the baseline environment are completed while maintaining its stability is crucial.

[0045] Optionally, a rolling update service upgrade approach can be adopted. Rolling updates refer to upgrading the service version without downtime. It ensures service continuity and high availability by gradually replacing old Pods with new ones. After successful canary release verification, the service in the baseline environment is updated using rolling updates. However, rolling updates are a process of gradually replacing old Pods with new ones, making it difficult to avoid the coexistence of old and new versions, thus posing a risk of request traffic loss. For example, taking the service call chain A→C→D in Figure 1a as an example, if this upgrade is from A to A1 and from D to D1, and if the traffic from A1→B→D1 is fine after successful canary release verification, then the baseline environment can be upgraded. However, because the rolling updates and startup / destruction times of different services are inconsistent when upgrading A→A1 and D→D1 simultaneously, there may be both old and new version service call chains for A→C→D1 and A1→C→D. In this case, it is necessary to ensure the compatibility between the old and new versions (such as A1 and D or A and D1). If compatibility issues exist, traffic will be lost during the deployment process.

[0046] Furthermore, when the baseline environment is implemented as a production environment, the traffic is large, and there is both online and offline traffic. The online traffic is the traffic of the production environment, and the offline traffic can be the traffic generated during the application development process before it is put into production. Due to the large traffic volume, the impact of traffic loss will be more severe. Therefore, the need to achieve lossless upgrade of the entire service chain in the baseline environment is more urgent.

[0047] Therefore, how to perform a seamless end-to-end upgrade of services in the baseline environment without affecting the normal operation of services in the feature environment has become a major technical challenge. In this embodiment, a grayscale version of the target service to be upgraded is deployed on the baseline link in the baseline environment. Through multi-level fallback routing rules, grayscale traffic is allowed to fall back from the feature version in the feature environment to the grayscale version in the baseline environment and then back to the baseline version. This ensures that grayscale traffic can be smoothly guided to the feature version and the grayscale version, thereby completing the verification of the grayscale version of the target service without affecting the normal operation of the feature version of the service in the feature environment. After successful verification, the baseline traffic on the baseline link is switched to the grayscale link, which can upgrade the target service to the grayscale version seamlessly throughout the entire process.

[0048] Furthermore, in an optional embodiment of this disclosure, after all baseline traffic on the baseline link is switched to the grayscale link, no traffic passes through the target service on the baseline link. In this case, the target service on the baseline link can be upgraded to the grayscale version without loss throughout the entire link. In addition, since the baseline traffic is switched to the grayscale version of the target service after verification, incompatibility issues between the old and new versions are avoided, and there is no need to worry about traffic loss.

[0049] Furthermore, in the optional embodiments of this disclosure, during the verification of the grayscale version, since the baseline version still exists, if the verification of the grayscale version fails, it can be quickly rolled back without involving the redeployment of the baseline version, and the rollback cost is low.

[0050] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0051] Figure 2a is a schematic diagram of the structure of an application system provided in an exemplary embodiment of this disclosure. As shown in Figure 2a, the application system includes: a baseline environment, and at least one feature environment that reuses the baseline environment. Figure 2a and the following figures use one feature environment as an example and do not constitute a limitation on this embodiment. For a detailed description of the baseline environment and feature environment, please refer to the above embodiments, which will not be repeated here.

[0052] As mentioned above, the baseline environment generally has more physical resources than the feature environment. In this embodiment, the application system's services are deployed on service nodes. The number of service nodes in the baseline environment is greater than that in the feature environment, as shown in Figure 2a. The baseline environment has more service nodes than the feature environment. It should be understood that Figure 2a only shows the feature environment with one service node as an example, but it is not limited to this.

[0053] In this embodiment, the application system includes multiple services. This embodiment uses some of the services in the example shown in Figure 1a as an example for illustration. As shown in Figure 2a, the application system includes services A, C, E, and F, and the service call chain is A→C→E→F.

[0054] In the baseline environment, multiple service baseline versions are deployed on the service nodes. For example, in Figure 2a, baseline versions A, C, E, and F are deployed on the service nodes of the baseline environment. The baseline versions are stable versions of the services and can be used as the basis for developing feature versions of those services. The feature environment has no deployed services, or at least one feature version of a service is deployed on a small number of service nodes. For example, in Figure 2a, feature version C is deployed on the service nodes of the feature environment. A feature version refers to a version of a service whose functionality or features have changed based on the baseline version. This can involve extending, improving, or deleting the functions performed by the service. Feature version development can occur at any stage of the application development process, including development, testing, integration, deployment, and production; there are no restrictions on this.

[0055] In this embodiment, the service call chain in the application system is divided into a baseline chain and a gray-scale chain. A baseline chain is a service call chain for at least some baseline versions of multiple services in a baseline environment, including the service node where the baseline version of the target service resides. The target service is the service that needs to be upgraded, and can be at least some of the services included in the application system. As shown in Figure 2a, the service call chain A→C→E→F formed by the baseline versions of services A, C, E, and F is the baseline chain. If a gray-scale release is required for the target service in the baseline chain of the baseline environment, a corresponding gray-scale chain will be generated. The gray-scale chain includes the service node where the gray-scale version of the target service resides. A gray-scale version is a gray version of the service's baseline version. The difference between a gray-scale version and a feature version is that the gray-scale version is deployed in the baseline environment, while the feature version is deployed in the local environment, i.e., the feature environment.

[0056] In this embodiment, the grayscale version includes at least a first grayscale version, which is the version updated iteratively from the current baseline version. Of course, the grayscale version can also include a second grayscale version, etc., where the second grayscale version can be a grayscale version of the first grayscale version. As shown in Figure 2a, taking A and E as target services as an example, the baseline link includes the baseline versions corresponding to A and E, and the grayscale link includes the first grayscale versions corresponding to A and E. Furthermore, the grayscale versions of the target services can reside on different service nodes than the baseline versions to improve system availability. Of course, in some embodiments, the grayscale versions of the target services can also reside on the same service node as the baseline versions to improve resource utilization.

[0057] In cases where multiple grayscale versions exist, there are no restrictions on their deployment locations. For example, if a grayscale version includes a first grayscale version and a second grayscale version, the first grayscale version of the target service can reside on different service nodes than the second grayscale version to improve system availability. Of course, in some embodiments, the first grayscale version of the target service can also reside on the same service node as the second grayscale version to improve resource utilization.

[0058] In this embodiment, the grayscale link includes at least a grayscale version of the target service and is used to verify the grayscale version of the target service. Furthermore, if any service in the grayscale link has a feature version, then the grayscale link includes that feature version. In this case, the grayscale link is also used to maintain the normal operation of the feature version. If no service in the grayscale link has a feature version, but the grayscale link has grayscale versions of at least some services, including the target service, then the grayscale link includes the grayscale versions of those at least some services. If some services in the grayscale link do not have grayscale versions, then the grayscale link includes the baseline versions of those services. The grayscale link includes the baseline versions to enable the reuse of some services on the baseline link, forming a complete service call link and providing a relatively complete service.

[0059] In this embodiment, traffic entering the baseline environment includes tagged access traffic from at least a portion of the characteristic environment, as well as untagged access traffic from outside. Access traffic must at least invoke the target service. In this embodiment, access traffic is divided into gray-scale traffic and baseline traffic. Baseline traffic includes tagged and / or untagged access traffic, while gray-scale traffic includes access traffic awaiting labeling and / or untagged access traffic. This embodiment does not limit the method of dividing access traffic. For example, it can be based on a set ratio, such as setting 20% ​​of the access traffic as gray-scale traffic and the remaining access traffic as baseline traffic; or it can be divided according to various methods such as the user's ID, region, etc., and there is no limitation on this.

[0060] In this embodiment, baseline traffic refers to traffic passing through the baseline environment, which may include, but is not limited to, online traffic, development traffic, and test traffic. Gray-scale traffic refers to traffic used at least to verify gray-scale versions of the target service. As shown in Figure 2a, access traffic includes gray-scale traffic and baseline traffic. Dashed lines represent gray-scale traffic, and solid lines represent baseline traffic. Both gray-scale traffic and baseline traffic contain two thicknesses: thicker dashed lines represent labeled gray-scale traffic or baseline traffic; thinner dashed lines represent unlabeled gray-scale traffic or baseline traffic. Subsequent figures will refer to these definitions, which will not be repeated here.

[0061] In this embodiment, gray-scale traffic is used to verify gray-scale versions without affecting the normal operation of the feature environment. During this process, gray-scale traffic is routed to gray-scale links according to multi-level fallback routing rules to verify the gray-scale version of the target service. These multi-level fallback routing rules include: for tagged access traffic, service nodes on the gray-scale link are selected in the order of fallback from the feature version to the gray-scale version and then to the baseline version; for untagged access traffic, service nodes on the gray-scale link are selected in the order of fallback from the gray-scale version to the baseline version. The process of verifying using gray-scale traffic is described below using Figure 2a as an example.

[0062] As shown in Figure 2a, during the verification of the first grayscale version of the target service according to the multi-level fallback routing rules, if the grayscale traffic is tagged, the service nodes on the grayscale link are selected in the order of fallback from the feature version of the target service to the grayscale version and then to the baseline version, based on the multi-level fallback routing rules. Based on this, the grayscale traffic is sent to the traffic ingress node of the application system. The traffic ingress node is a gateway (as shown in Figure 2a) or a load balancer, responsible for routing access traffic to the services on each interconnected service node. Further, the traffic ingress node routes the grayscale traffic to the first service node based on the multi-level fallback routing rules. Since A has no feature version but has a first grayscale version, it can fall back from the feature version to the first grayscale version. Then, as shown in S11 of Figure 2a, the grayscale traffic is sent to the service node where the first grayscale version of A is deployed. For a service node with the first grayscale version of A, upon receiving grayscale traffic, the service node C, selected from the baseline and feature environments based on multi-level fallback routing rules (as shown in Figure 2a), has a feature version and therefore no fallback is needed. As shown in S12 of Figure 2a, the grayscale traffic can be sent to the service node with the feature version of C. For a service node with the feature version of C, the service node E, selected from the baseline and feature environments based on multi-level fallback routing rules, can also receive grayscale traffic. Since E does not have a feature version but has a first grayscale version, a fallback can be performed from the feature version to the first grayscale version (as shown in S13 of Figure 2a), sending the grayscale traffic to the service node with the first grayscale version of E. Finally, when the service node with the first gray version of E receives gray traffic, it selects the service node F from the baseline environment and the feature environment based on the multi-level fallback routing rules. Since F has neither a feature version nor a first gray version, it can fall back from the feature version to the first gray version and then to the baseline version, which is a two-level fallback method, as shown in S14 in Figure 2a, and send the gray traffic to the service node with the baseline version of F.

[0063] If the gray-scale traffic is unlabeled, based on the multi-level fallback routing rules, service nodes on the gray-scale link are selected in the order of fallback from the gray-scale version of the target service to the baseline version. Therefore, when gray-scale traffic enters the application system's traffic ingress node (the gateway in Figure 2a), since A has a first gray-scale version, no fallback is needed. As shown in S21 of Figure 2a, the gray-scale traffic is sent to the service node with the first gray-scale version of A deployed. When the service node with the first gray-scale version of A receives gray-scale traffic, based on the multi-level fallback routing rules, it selects service node C from the baseline environment. C does not have a first gray-scale version, so it falls back from the first gray-scale version to the baseline version. Then, as shown in S22 of Figure 2a, the gray-scale traffic can be sent to the service node with the baseline version of C deployed. For the service node with the baseline version of C deployed, based on the multi-level fallback routing rules, it selects service node E from the baseline environment. Since E has a first gray-scale version, no fallback is needed. Then, as shown in S23 of Figure 2a, the gray-scale traffic is sent to the service node with the first gray-scale version of E deployed. Finally, when a service node with the first gray version of E receives gray traffic, it selects service node F from the baseline environment based on the multi-level fallback routing rules. Since there is no first gray version, it can fall back from the first gray version to the baseline version, as shown in S24 in Figure 2a, and send the gray traffic to the service node with the baseline version of F.

[0064] As shown in the example above, regardless of whether the gray-scale traffic is tagged, it will always pass through the first gray-scale version of the target service to verify it. Meanwhile, if the gray-scale traffic is tagged, it will be routed to the feature version of the service in the feature environment to ensure the normal operation of the feature version that depends on the baseline environment.

[0065] Before successful verification, as shown in Figure 2a, baseline traffic is routed to the baseline link to maintain its stable and normal operation. Once the first grayscale version of the target service passes verification, baseline traffic can be switched from the baseline link to the grayscale link according to multi-level fallback routing rules. The service nodes on the grayscale link must be able to handle at least the baseline traffic. The process of switching baseline traffic from the baseline link to the grayscale link can be found in the grayscale traffic switching process. Similar to grayscale traffic, regardless of whether the baseline traffic is tagged, if the service nodes on the baseline link where the target service is deployed have multi-level fallback routing rules enabled, the baseline traffic of the target service is redirected from the baseline link to the grayscale link, as shown in Figure 2b. The baseline traffic switches from the target service on the baseline link to the target service on the grayscale link, thus enabling a lossless upgrade of the target service on the baseline link to the grayscale version.

[0066] In this embodiment, the grayscale version of the target service to be upgraded on the baseline link is deployed in the baseline environment. Through multi-level fallback routing rules, the grayscale traffic is allowed to fall back from the feature version in the feature environment to the grayscale version in the baseline environment and then back to the baseline version. This allows the grayscale traffic to be successfully guided to the feature version and the grayscale version, thereby completing the verification of the grayscale version of the target service without affecting the normal operation of the feature version of the service in the feature environment. If the verification is successful, the baseline traffic on the baseline link is switched to the grayscale link, so that the target service can be upgraded to the grayscale version without loss of time throughout the entire link.

[0067] In an optional embodiment, the baseline environment includes a traffic ingress node for routing external requests according to predefined routing rules. Similarly, the service nodes in this embodiment also have the capability to route traffic from external requests according to predefined routing rules. This embodiment does not limit the method by which the traffic ingress node and service nodes implement routing according to predefined routing rules. For example, the agent can be mounted as a functional module of the service in each service of a microservice architecture to route traffic for these services according to predefined routing rules. Further, the control node can distribute the predefined routing rules to the service nodes where the services reside, allowing the agents mounted on those service nodes to apply the routing rules. As another example, a sidecar (proxy container) can be used to run an independent proxy container next to each service, which can be used to intercept traffic for that service and route it according to predefined routing rules.

[0068] In one optional embodiment, the routing rules can be multi-level fallback routing rules. Specifically, these rules are used to: instruct that upon receiving gray-scale traffic or baseline traffic, identify whether the gray-scale traffic or baseline traffic is tagged access traffic; if the gray-scale traffic or baseline traffic is identified as tagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, prioritize the service node with the featured version deployed; if no service node with the featured version is deployed, prioritize the service node with the gray-scale version deployed; if no service node with the gray-scale version is deployed, select the service node with the baseline version deployed. In other words, when the access traffic is tagged, it is preferable to select a service node with the featured version deployed, followed by a service node with the gray-scale version deployed, and then a service node with the baseline version deployed. If the gray-scale traffic or baseline traffic is identified as untagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, prioritize the service node with the gray-scale version deployed; if no service node with the gray-scale version is deployed, select the service node with the baseline version deployed. In other words, when access traffic is tagged, it is preferable to deploy the gray-scale version of the service node, and the second choice is to deploy the baseline version of the service node.

[0069] Furthermore, during the process of routing gray-scale traffic to the gray-scale link to verify the first gray-scale version, the control node can issue multi-level fallback routing rules to the traffic ingress node and service node in the baseline environment, as well as the service node in the feature environment. Then, the gray-scale traffic is sent to the traffic ingress node, which selects the first service node on the gray-scale link from the baseline environment and feature environment based on the multi-level fallback routing rules, and sends the gray-scale traffic to the first service node.

[0070] It should be understood that whether the traffic ingress node selects the first service node of the feature version of the service as the first service node on the gray-scale link depends on whether the access traffic is tagged. Therefore, for the traffic ingress node that receives gray-scale traffic, in the process of selecting the first service node based on the multi-level fallback routing rules, it is possible to identify whether the gray-scale traffic is tagged access traffic.

[0071] If the traffic entry node identifies the gray-scale traffic as tagged access traffic, then if the first feature version of the service exists in both the baseline and feature environments, the service node deploying the first feature version of the service will be used as the first service node on the gray-scale link. If the first feature version of the service does not exist in either the baseline or feature environments, then if the first gray-scale version of the service exists in either the baseline or feature environments, the service node deploying the first gray-scale version of the service will be used as the first service node on the gray-scale link. If the first gray-scale version of the service does not exist in either the baseline or feature environments, then the service node deploying the first baseline version of the service will be used as the first service node on the gray-scale link.

[0072] If the traffic entry node identifies the gray-scale traffic as unlabeled access traffic, then if a gray-scale version of the first service exists in both the baseline environment and the feature environment, the service node with the gray-scale version of the first service deployed will be used as the first service node on the gray-scale link; if a gray-scale version of the first service does not exist in either the baseline environment or the feature environment, then the service node with the baseline version of the first service deployed will be used as the first service node on the gray-scale link.

[0073] Furthermore, for any service node that receives gray-scale traffic, the next service node on the gray-scale link is selected from the baseline environment and the feature environment based on the multi-level fallback routing rules, and the gray-scale traffic is sent to the next service node. Any service node can be a service node in the baseline environment or the feature environment of the application system. Any service node has any service on the gray-scale link where the target service is located deployed. Any service may be the target service, or it may be a service other than the target service among multiple services in the application system. The version of any service may be the feature version, the gray-scale version, or the baseline version.

[0074] In this embodiment, from the perspective of the service node, the access traffic received by any service node during and after the gray-scale verification process is referred to as the first access traffic, that is, the access traffic switching from the baseline link to the gray-scale link is referred to as the first access traffic. The first access traffic can be gray-scale traffic or baseline traffic. Baseline traffic flows into the service nodes on the gray-scale link after the gray-scale version verification of the target service has passed. The processing process of gray-scale traffic and baseline traffic by the service nodes on the gray-scale link is similar. The following describes how the service node processes the received gray-scale traffic. The processing method for baseline traffic can be referred to the processing method for gray-scale traffic. Whether any service node selects the service node of the next feature version of the next service as the next service node on the gray-scale link depends on whether the gray-scale traffic is the first access traffic with a label.

[0075] Therefore, for any service node that receives gray-scale traffic, in the process of selecting the next service node based on multi-level fallback routing rules, it is possible to identify whether the gray-scale traffic is the first access traffic with a label.

[0076] If any service node identifies the gray-scale traffic as the first access traffic with a label according to the multi-level fallback routing rules, it selects the next service node on the gray-scale link in the fallback order from the feature version to the gray-scale version and then to the baseline version. The following describes the different scenarios: If a feature version of the next service exists in both the baseline and feature environments, the service node deploying the feature version of the next service will be used as the next service node on the gray-scale link; if a feature version of the next service does not exist in either the baseline or feature environments, and a gray-scale version of the next service exists in both environments, the service node deploying the gray-scale version of the next service will be used as the next service node on the gray-scale link; if a gray-scale version of the next service does not exist in either the baseline or feature environments, the service node deploying the baseline version of the next service will be used as the next service node on the gray-scale link.

[0077] If any service node identifies the gray-scale traffic as unlabeled first-access traffic according to the multi-level fallback routing rules, it selects the next service node on the gray-scale link in the fallback order from the gray-scale version to the baseline version. The following describes the different scenarios: If a gray-scale version of the next service exists in both the baseline and feature environments, the service node deploying that gray-scale version will be used as the next service node on the gray-scale link. If no gray-scale version of the next service exists in either the baseline or feature environments, the service node deploying the baseline version of the next service will be used as the next service node on the gray-scale link. This process continues until all services on the gray-scale link have been invoked, thus completing the verification of the first gray-scale version of the target service. Furthermore, if the verification of the first gray-scale version of the target service is successful, the baseline traffic can be switched from the baseline link to the gray-scale link. The baseline link includes the service node where the baseline version of the target service resides.

[0078] Before successful verification, the traffic ingress node and service node in the baseline environment receive a switching instruction. This instruction switches from a multi-level fallback routing rule to a single-level fallback routing rule. The single-level fallback routing rule is used to route baseline traffic to baseline links at least once. Specifically, the single-level fallback routing rule selects service nodes on the baseline link in the order of fallback from feature version to baseline version for tagged access traffic; and selects service nodes on the baseline link in the order of selection of baseline version for untagged access traffic. The process of traffic ingress nodes and service nodes routing access traffic based on the single-level fallback routing rule is described below.

[0079] When baseline traffic enters the traffic ingress node, the traffic ingress node identifies whether the baseline traffic is tagged access traffic. If the baseline traffic is identified as tagged access traffic, then if a feature version of the first service exists in both the baseline and feature environments, the service node deploying the feature version of the first service will be used as the first service node on the baseline link; otherwise, if a feature version of the first service does not exist in either the baseline or feature environments, the service node deploying the baseline version of the first service will be used as the first service node on the baseline link. If the baseline traffic is identified as untagged access traffic, then the service node deploying the baseline version of the first service will be used as the first service node on the baseline link.

[0080] Furthermore, for any service node receiving baseline traffic, if the service on that service node is not a grayscale version of the target service, that service node will also be located on the baseline link where the baseline version of the target service resides. Furthermore, this service node can receive a switching instruction to switch from a multi-level fallback routing rule to a single-level fallback routing rule. Based on the single-level fallback routing rule, it selects the next service node on the baseline link from the baseline environment and the feature environment, and sends the baseline traffic to the next service node. During the process of selecting the next service node on the baseline link based on the single-level fallback routing rule and sending the baseline traffic to the next service node, it is possible to identify whether the baseline traffic is tagged access traffic.

[0081] If any service node identifies the baseline traffic as tagged access traffic, then, if a feature version of the next service exists in both the baseline and feature environments, the service node deploying that feature version will be used as the next service node on the baseline link. If no feature version of the next service exists in either the baseline or feature environment, then the service node deploying the baseline version of the next service will be used as the next service node on the baseline link. If any service node identifies the baseline traffic as untagged access traffic, then the service node deploying the baseline version of the next service will be used as the next service node on the baseline link.

[0082] As described above, before successful verification, the traffic ingress nodes and service nodes within the baseline environment route baseline traffic to the baseline link based on single-level fallback routing rules to maintain the stability of the baseline link. During this process, canary traffic is routed to the canary link based on multi-level fallback routing rules to verify the canary version of the target service. If the verification passes, it proves that the canary version can operate normally, so baseline traffic can be switched from the baseline link to the canary link.

[0083] In one optional embodiment, upon successful verification of the first grayscale version of the target service, the control node issues a first switching instruction to the traffic ingress node and service node in the baseline environment, respectively, to instruct a switch from a single-level fallback routing rule to a multi-level fallback routing rule. The multi-level fallback rule is used at least to switch baseline traffic from the baseline link to the grayscale link. Further, the baseline traffic is sent to the traffic ingress node, which selects the first service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rule, and sends the baseline traffic to the first service node. For any service node that receives the baseline traffic, it selects the next service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rule, and sends the baseline traffic to the next service node, thereby switching the baseline traffic from the baseline link to the grayscale link.

[0084] Optionally, after switching baseline traffic from the baseline link to the grayscale link, the baseline version of the target service in the baseline link can be upgraded to the first grayscale version to obtain a new baseline version. Since the baseline traffic has been switched, there is no traffic on the baseline version of the target service, so no service interruption occurs, and a lossless upgrade of the target service can be achieved. Furthermore, when the baseline version of the target service in the baseline link is upgraded to the first grayscale version, according to the single-level fallback routing rules, the access traffic in the grayscale link is switched back to the upgraded baseline link, and the resources occupied by the target service in the grayscale link are released.

[0085] In an optional embodiment, when the baseline version of the target service is upgraded to the first grayscale version, when switching the access traffic in the grayscale link back to the upgraded baseline link according to the single-level fallback routing rule, the process includes: the control node issuing a third switching instruction to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to instruct a switch from the multi-level fallback routing rule to the single-level fallback routing rule; sending the access traffic entering the baseline environment to the traffic ingress node, the traffic ingress node selecting the first service node on the upgraded baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sending the access traffic to the first service node; for any service node that receives the access traffic, selecting the next service node on the upgraded baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sending the access traffic to the next service node, so as to switch the access traffic in the grayscale link back to the upgraded baseline link.

[0086] Optionally, if the verification of the first grayscale version of the target service fails, i.e., the grayscale version release fails (e.g., the first grayscale version of the target service may be faulty or the service node it resides in may crash), then the access traffic directed to the grayscale link where the first grayscale version of the target service resides can be switched back to the baseline link. This involves rolling back the first grayscale version. Since the baseline version still exists, there is no need to redeploy it. The rollback of the first grayscale version includes: if a rollback occurs during the verification process of the first grayscale version of the target service, the grayscale traffic in the grayscale link is switched back to the baseline link according to the single-level fallback routing rules; and / or, if a rollback occurs during the process of switching baseline traffic from the baseline link to the grayscale link, the grayscale traffic in the grayscale link and the baseline traffic already switched to the grayscale link are switched back to the baseline link according to the single-level fallback routing rules.

[0087] In one optional embodiment, if the first gray-scale version verification of the target service fails, during the process of switching gray-scale traffic in the gray-scale link back to the baseline link according to the single-level fallback routing rule, the control node issues a second switching instruction to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to instruct the switch from the multi-level fallback routing rule to the single-level fallback routing rule; the incoming gray-scale traffic is sent to the traffic ingress node, and the traffic ingress node selects the first service node on the baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the gray-scale traffic to the first service node.

[0088] For any service node, the access traffic flowing into that service node during the switch from a grayscale link to a baseline link is called the second access traffic. As shown in the above embodiment, the second access traffic can be grayscale traffic, or it can be baseline traffic, which is the baseline traffic that has been switched to the grayscale link. The processing of grayscale traffic and baseline traffic by the service node is similar. The following describes how the service node processes the received grayscale traffic; the processing method for baseline traffic can be found in the grayscale traffic processing method.

[0089] In this embodiment, upon receiving a second switching instruction, any service node switches from a multi-level fallback routing rule to a single-level fallback routing rule. Further, the service node selects the next service node on the baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule. If the grayscale traffic identified as the second access traffic based on the single-level fallback routing rule has a label, the next service node on the baseline link is selected in the order of fallback from the feature version to the baseline version. If the grayscale traffic identified as the second access traffic based on the single-level fallback routing rule does not have a label, the next service node on the baseline link is selected directly according to the baseline version. The grayscale traffic is then sent to the next service node to switch the grayscale traffic in the grayscale link back to the baseline link.

[0090] Regarding the rollback that occurs during the process of switching baseline traffic from the baseline link to the gray link, and how to switch the gray traffic in the gray link and the baseline traffic that has been switched to the gray link back to the baseline link according to the single-level fallback routing rules, please refer to the gray traffic switching process described above. The difference is that this situation includes the second access traffic, which includes both gray traffic and baseline traffic. Other related content will not be elaborated here.

[0091] Further optionally, as shown in Figure 2c, if a canary release of the first canary version is required, a second canary version of the target service is deployed in the baseline environment to perform a canary release of the second canary version; wherein, the canary version includes the first canary version and the second canary version, and the second canary version is a canary version of the first canary version. In this optional embodiment, the multi-level fallback routing rule further includes: in the case of falling back to a canary version, the canary version can be either the first canary version or the second canary version, and the service nodes on the canary link are selected according to the order of falling back from the second canary version to the first canary version.

[0092] In this embodiment, the multi-level fallback routing rule is specifically used to: instruct that upon receiving gray-scale traffic, it is necessary to identify whether the gray-scale traffic is tagged access traffic; if the gray-scale traffic or baseline traffic is identified as tagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a feature version is preferentially selected; if no service node with a feature version is deployed, a service node with a second gray-scale version is preferentially selected; if no service node with a second gray-scale version is deployed, a service node with a first gray-scale version is selected; if no service node with a first gray-scale version is deployed, a service node with a baseline version is selected; if the gray-scale traffic or baseline traffic is identified as untagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a second gray-scale version is preferentially selected; if no service node with a second gray-scale version is deployed, a service node with a first gray-scale version is selected; if no service node with a first gray-scale version is deployed, a service node with a baseline version is selected.

[0093] Based on the aforementioned multi-level fallback routing rules, when routing gray-scale traffic to the gray-scale link to verify the first gray-scale version according to the multi-level fallback routing rules, the process includes: the control node issuing multi-level fallback routing rules to the traffic ingress node and service node in the baseline environment, as well as the service node in the feature environment. Further, the traffic ingress node and service node, according to the multi-level fallback routing rules, route the gray-scale traffic to the gray-scale link to verify the second gray-scale version. The verification process of the second gray-scale version is described below with reference to Figure 2c.

[0094] As shown in Figure 2c, for example, during the process of routing gray-scale traffic to the gray-scale link to verify the second gray-scale version of the target service according to the multi-level fallback routing rules, if the gray-scale traffic has a label, based on the multi-level fallback routing rules, the service nodes on the gray-scale link are selected in the order of falling back from the feature version of the target service to the second gray-scale version, then to the first gray-scale version, and finally back to the baseline version. Based on this, when gray-scale traffic enters the traffic entry node of the application system, the gray-scale traffic is routed to the first service node. Since A does not have a feature version but has a second gray-scale version, it can fall back from the feature version to the second gray-scale version. Therefore, as shown in S31 of Figure 2c, the traffic entry node sends the gray-scale traffic to the service node where the second gray-scale version of A is deployed. For a service node with a second grayscale version of A that receives grayscale traffic, the service node C selected from the baseline and feature environments based on the multi-level fallback routing rules, as shown in Figure 2c, has a feature version and therefore does not need to fall back. As shown in S32 of Figure 2c, the grayscale traffic can be sent to the service node with the feature version of C. For a service node with a feature version of C that is selected from the baseline and feature environments based on the multi-level fallback routing rules, the service node E that is selected from the baseline and feature environments, does not have a feature version but has a second grayscale version. Therefore, it can fall back from the feature version to the second grayscale version, as shown in S33 of Figure 2c, and send the grayscale traffic to the service node with the second grayscale version of E. Finally, when the service node with the second gray version of E receives gray traffic, it selects the service node F from the baseline environment and the feature environment based on the multi-level fallback routing rules. Since F has neither a feature version nor the first or second gray version, it can fall back from the feature version to the second gray version, then to the first version, and finally back to the baseline version, which is a three-level fallback method, as shown in S34 in Figure 2c. The gray traffic is then sent to the service node with the baseline version of F.

[0095] For example, if the gray-scale traffic is unlabeled, based on the multi-level fallback routing rules, service nodes on the gray-scale link are selected in the order of falling back from the gray-scale version of the target service to the baseline version. Therefore, when gray-scale traffic enters the traffic ingress node of the application system, since A has a second gray-scale version, no fallback is needed, as shown in S41 of Figure 2c. The traffic ingress node sends the gray-scale traffic to the service node with the second gray-scale version of A deployed. When the service node with the second gray-scale version of A receives the gray-scale traffic, based on the multi-level fallback routing rules, it selects service node C from the baseline environment. C does not have a gray-scale version, so it falls back from the second gray-scale version to the first baseline version and then back to the baseline version. Furthermore, as shown in S42 of Figure 2c, the gray-scale traffic can be sent to the service node with the baseline version of C deployed. For the service node with the baseline version of C, based on the multi-level fallback routing rules, it selects service node E from the baseline environment. Since E has a second gray-scale version, no fallback is needed. Then, as shown in S43 of Figure 2c, the gray-scale traffic is sent to the service node with the second gray-scale version deployed with E. Finally, when the service node with the second gray-scale version deployed with E receives the gray-scale traffic, based on the multi-level fallback routing rules, the service node F selected from the baseline environment, since it has no gray-scale version, can fall back from the second gray-scale version to the first gray-scale version and then back to the baseline version, as shown in S44 of Figure 2c, and send the gray-scale traffic to the service node with the baseline version deployed with F.

[0096] As shown in the example above, regardless of whether the gray-scale traffic is tagged, it will always pass through the second gray-scale version of the target service to verify it. Meanwhile, if the gray-scale traffic is tagged, it will be routed to the feature version of the service in the feature environment to ensure the normal operation of the feature version that depends on the baseline environment.

[0097] Before the second grayscale version of the target service passes verification, as shown in Figure 2c, baseline traffic is routed to the baseline link to maintain its stable and normal operation. Once the second grayscale version of the target service passes verification, baseline traffic can be switched from the baseline link to the grayscale link according to multi-level fallback routing rules. The service nodes on the grayscale link are at least capable of carrying the baseline traffic. The process of switching baseline traffic from the baseline link to the grayscale link can be referred to the aforementioned embodiment. Similar to grayscale traffic, regardless of whether the baseline traffic is tagged, if the service nodes on the baseline link where the target service is deployed have multi-level fallback routing rules enabled, the baseline traffic of the target service is redirected from the baseline link to the grayscale link, as shown in Figure 2d. The baseline traffic switches from the target service on the baseline link to the target service on the grayscale link, ensuring that no traffic passes through the target service on the baseline link, thus allowing the target service on the baseline link to be upgraded to the second grayscale version without loss.

[0098] Furthermore, if the baseline version of the target service is upgraded to the second grayscale version, the access traffic in the grayscale link will be switched back to the upgraded baseline link according to the single-level fallback routing rule. The process of switching access traffic from the grayscale link back to the baseline link can be referred to the aforementioned embodiments.

[0099] Compared to the application system in Figure 1b, which includes multiple isolated environments with complete services, the application system in Figure 2a only requires one complete baseline environment containing all services, thus significantly reducing system resource expenditure. Based on this, this disclosure provides a formula for calculating physical resource costs, used to calculate the resource cost difference between the application systems shown in Figure 1b and Figure 2a. The formula is as follows:

[0100] Where f(x) represents the resource cost saved by this solution. In this embodiment, multiple microservice domains are included, each microservice domain contains multiple services, and D... uA The number of Pods representing service deployments across multiple microservice domains; D uE The number of services deployed across multiple microservice domains. N a1i N represents the number of Pods deployed for each service in each isolated environment, where i ≥ 1 and i is a natural number; e1j U represents the number of services in each isolated environment, where j≥1 and i is a natural number; Pod Cost per Pod. N a2i Represents the number of Pods deployed for each service in each feature environment; U ecs K represents the cost per Pod in the feature environment; K is the number of Pods deployed for each service in the baseline environment; N represents the cost per Pod. e2j This represents the number of services deployed in the baseline environment.

[0101] The above embodiments describe a lossless upgrade process for a target service on a baseline link in a microservice application system. This disclosure also provides a service publishing method applied to an application system comprising multiple services. The application system includes a baseline environment and at least one feature environment. The baseline environment deploys baseline versions of multiple services, while the feature environment is either empty or deploys a feature version of at least one service. This method can be implemented by the application system's control layer in conjunction with each service node. The control layer can be a management and control device within the application system, but is not limited to this. As shown in Figure 3, the method includes: S301: If a canary release of the target service in the baseline environment is required, deploy the first canary version of the target service in the baseline environment; S302: Divide the access traffic entering the baseline environment into canary traffic and baseline traffic, the access traffic including at least some tagged access traffic from the feature environment; S303: According to the multi-level fallback routing rules, route the canary traffic to the canary link to verify the first canary version, the canary link including the service node where the first canary version is located; S304: If the verification is successful, according to the multi-level fallback routing rules, switch the baseline traffic from the baseline link to the canary link, the baseline link including the service node where the baseline version of the target service is located; wherein, the multi-level fallback routing rules include: for tagged access traffic, select the service node on the canary link in the order of fallback from the feature version to the canary version and then to the baseline version; for untagged access traffic, select the service node on the canary link in the order of fallback from the canary version to the baseline version.

[0102] In an optional embodiment, when routing the gray-scale traffic to a gray-scale link to verify the first gray-scale version according to the multi-level fallback routing rules, the process includes: issuing the multi-level fallback routing rules to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively; sending the gray-scale traffic to the traffic ingress node, whereby the traffic ingress node selects the first service node on the gray-scale link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sends the gray-scale traffic to the first service node; for any service node that receives the gray-scale traffic, selecting the next service node on the gray-scale link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sending the gray-scale traffic to the next service node to verify the first gray-scale version; wherein, any service node has a feature version, gray-scale version, or baseline version of any service called by the gray-scale traffic deployed on it, and the service called by the gray-scale traffic includes at least the target service.

[0103] In an optional embodiment, when switching the baseline traffic from the baseline link to the grayscale link according to the multi-level fallback routing rule, the process includes: issuing a first switching instruction to the traffic ingress node and service node in the baseline environment, respectively, to instruct a switch from the single-level fallback routing rule to the multi-level fallback routing rule, wherein the single-level fallback routing rule is at least used to route the baseline traffic to the baseline link; sending the baseline traffic to the traffic ingress node, wherein the traffic ingress node selects the first service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rule, and sends the baseline traffic to the first service node; for any service node that receives the baseline traffic, selecting the next service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rule, and sending the baseline traffic to the next service node, thereby switching the baseline traffic from the baseline link to the grayscale link.

[0104] In an optional embodiment, the multi-level fallback routing rule is specifically used to: instruct, upon receiving gray-scale traffic or baseline traffic, to identify whether the gray-scale traffic or baseline traffic is tagged access traffic; if the gray-scale traffic or baseline traffic is identified as tagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a feature version is preferentially selected; if no service node with a feature version is deployed, a service node with a gray-scale version is preferentially selected; if no service node with a gray-scale version is deployed, a service node with a baseline version is selected; if the gray-scale traffic or baseline traffic is identified as untagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a gray-scale version is preferentially selected; if no service node with a gray-scale version is deployed, a service node with a baseline version is selected.

[0105] In an optional embodiment, after deploying the first grayscale version in the baseline environment, the method further includes: if it is necessary to perform grayscale release of the first grayscale version, deploying a second grayscale version of the target service in the baseline environment to perform grayscale release of the second grayscale version; wherein, the second grayscale version is a grayscale version of the first grayscale version.

[0106] In an optional embodiment, the multi-level fallback routing rule further includes: in the case of falling back to a gray-scale version, selecting service nodes on the gray-scale link in the order of falling back from the second gray-scale version to the first gray-scale version; and routing the gray-scale traffic to the gray-scale link to verify the first gray-scale version according to the multi-level fallback routing rule, including: routing the gray-scale traffic to the gray-scale link to verify the second gray-scale version according to the multi-level fallback routing rule.

[0107] In an optional embodiment, the multi-level fallback routing rule is specifically used to: instruct, upon receiving gray-scale traffic, to identify whether the gray-scale traffic is tagged access traffic; if the gray-scale traffic or baseline traffic is identified as tagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a feature version is preferentially selected; if no service node with a feature version is deployed, a service node with a second gray-scale version is preferentially selected; if no service node with a second gray-scale version is deployed, a service node with a first gray-scale version is selected; if no service node with a first gray-scale version is deployed, a service node with a baseline version is selected; if the gray-scale traffic or baseline traffic is identified as untagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a second gray-scale version is preferentially selected; if no service node with a second gray-scale version is deployed, a service node with a first gray-scale version is selected; if no service node with a first gray-scale version is deployed, a service node with a baseline version is selected.

[0108] In an optional embodiment, the method further includes: if a rollback occurs during the verification of the gray-scale version of the target service, switching the gray-scale traffic in the gray-scale link back to the baseline link according to a single-level fallback routing rule; and / or, if a rollback occurs during the process of switching the baseline traffic from the baseline link to the gray-scale link, switching the gray-scale traffic in the gray-scale link and the baseline traffic already switched to the gray-scale link back to the baseline link according to a single-level fallback routing rule; wherein the single-level fallback routing rule includes: for access traffic with labels, selecting service nodes on the baseline link in the order of fallback from the feature version to the baseline version; for access traffic without labels, directly selecting the service node where the baseline version is located as the service node on the baseline link.

[0109] In an optional embodiment, when switching gray-scale traffic in the gray-scale link back to the baseline link according to the single-level fallback routing rule, the process includes: issuing a second switching instruction to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to instruct a switch from the multi-level fallback routing rule to the single-level fallback routing rule; sending the gray-scale traffic into the traffic ingress node, whereby the traffic ingress node selects the first service node on the baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the gray-scale traffic to the first service node; for any service node that receives the access traffic, selecting the next service node on the baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sending the gray-scale traffic to the next service node, thereby switching the gray-scale traffic in the gray-scale link back to the baseline link.

[0110] In an optional embodiment, after switching the baseline traffic from the baseline link to the grayscale link, the method further includes: upgrading the baseline version of the target service in the baseline link to the grayscale version to obtain a new baseline version; switching the access traffic in the grayscale link back to the upgraded baseline link according to the single-level fallback routing rules, and releasing the resources occupied by the target service in the grayscale link; wherein, the single-level fallback routing rules include: for access traffic with labels, selecting service nodes on the baseline link in the order of fallback from feature version to baseline version; for access traffic without labels, directly selecting service nodes on the baseline link according to the baseline version.

[0111] In an optional embodiment, when switching access traffic in the grayscale link back to the upgraded baseline link according to the single-level fallback routing rule, the process includes: issuing a third switching instruction to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to instruct a switch from the multi-level fallback routing rule to the single-level fallback routing rule; sending access traffic entering the baseline environment to the traffic ingress node, the traffic ingress node selecting the first service node on the upgraded baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sending the access traffic to the first service node; for any service node that receives the access traffic, selecting the next service node on the upgraded baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sending the access traffic to the next service node, thereby switching the access traffic in the grayscale link back to the upgraded baseline link.

[0112] This disclosure also provides a service routing method. This method is applied to service nodes in a baseline or feature environment of an application system. The service node deploys any service on a grayscale link where the target service resides, and pre-configures multi-level fallback routing rules. The target service is a service that needs to be grayscale released. The multi-level fallback routing rules can be pre-issued by the control plane of the application system. The service deployed on the service node can be a grayscale version of the target service on the grayscale link, or a baseline or feature version of a non-target service on the grayscale link. As shown in Figure 4, the method includes: S401: Receiving first access traffic, where the first access traffic is grayscale traffic or baseline traffic; S402: If the first access traffic is identified as having a label according to the multi-level fallback routing rules, selecting the next service node on the grayscale link in the fallback order from feature version to grayscale version and then to baseline version; S403: If the first access traffic is identified as not having a label according to the multi-level fallback routing rules, selecting the next service node on the grayscale link in the fallback order from grayscale version to baseline version; S404: Sending the first access traffic to the next service node on the grayscale link.

[0113] The first access traffic can be either gray-scale traffic or baseline traffic. For example, if the first access traffic is received during the verification process of the gray-scale version of the target service, it is specifically gray-scale traffic; if the first access traffic is received during the switch from the baseline link to the gray-scale link after successful verification, it is specifically baseline traffic.

[0114] In an optional embodiment, if the service on the service node is not a grayscale version of the target service, then the service on the service node can be a baseline version or a feature version of the non-target service. In this case, the service node will also be located on the baseline link where the baseline version of the target service is located. Based on this, the method further includes: receiving a switching instruction, the switching instruction indicating a switch from the multi-level fallback routing rule to a single-level fallback routing rule; the switching instruction can be issued by the control plane (e.g., management device) of the application system; subsequently, receiving second access traffic; if the second access traffic is identified as having a label based on the single-level fallback routing rule, selecting the next service node on the baseline link in the order of fallback from the feature version to the baseline version; if the second access traffic is identified as not having a label based on the single-level fallback routing rule, directly selecting the next service node on the baseline link according to the baseline version; and sending the second access traffic to the next service node on the baseline link. The second access traffic can be grayscale traffic or baseline traffic. For example, if the second access traffic is received when a rollback occurs during the verification process, it is specifically the grayscale traffic that needs to be rolled back; if the second access traffic is received when a rollback occurs during the switch from the baseline link to the grayscale link, it includes both the grayscale traffic that needs to be rolled back and the baseline traffic that needs to be rolled back.

[0115] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0116] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 301 to 303 can be device A; or the execution subject of steps 301 and 302 can be device A, and the execution subject of step 303 can be device B; and so on.

[0117] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 301, 302, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0118] Figure 5 is a schematic diagram of a control device provided in another exemplary embodiment of this disclosure. As shown in Figure 5, the control device includes a memory 54 and a processor 55.

[0119] Memory 54 is used to store computer programs and can be configured to store various other data to support operation on the control device. Examples of this data include instructions for any application or method used to operate on the control device, contact data, phone book data, messages, pictures, videos, etc.

[0120] The memory 54 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0121] Processor 55, coupled to memory 54, is configured to execute a computer program in memory 54 for: deploying a first grayscale version of the target service in the baseline environment if a grayscale release of the target service in the baseline environment is required; dividing access traffic entering the baseline environment into grayscale traffic and baseline traffic, the access traffic including at least tagged access traffic from at least some feature environments; routing the grayscale traffic to a grayscale link to verify the first grayscale version according to a multi-level fallback routing rule, the grayscale link including the service node where the first grayscale version is located; if the verification is successful, switching the baseline traffic from the baseline link to the grayscale link according to the multi-level fallback routing rule, the baseline link including the service node where the baseline version of the target service is located; wherein the multi-level fallback routing rule includes: for tagged access traffic, selecting service nodes on the grayscale link in the fallback order from feature version to grayscale version and then to baseline version; for untagged access traffic, selecting service nodes on the grayscale link in the fallback order from grayscale version to baseline version.

[0122] In an optional embodiment, when the processor 55 routes the grayscale traffic to the grayscale link to verify the first grayscale version according to the multi-level fallback routing rules, it is specifically configured to: issue the multi-level fallback routing rules to the traffic ingress node and service node in the baseline environment and the service node in the feature environment respectively; send the grayscale traffic to the traffic ingress node, the traffic ingress node selects the first service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sends the grayscale traffic to the first service node; for any service node that receives the grayscale traffic, selects the next service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sends the grayscale traffic to the next service node to verify the first grayscale version; wherein, any service node has a feature version, grayscale version or baseline version of any service called by the grayscale traffic deployed on it, and the service called by the grayscale traffic includes at least the target service.

[0123] In an optional embodiment, when the processor 55 switches the baseline traffic from the baseline link to the grayscale link according to the multi-level fallback routing rule, it is specifically configured to: issue a first switching instruction to the traffic ingress node and service node in the baseline environment respectively, to instruct a switch from the single-level fallback routing rule to the multi-level fallback routing rule, wherein the single-level fallback routing rule is at least used to route the baseline traffic to the baseline link; send the baseline traffic to the traffic ingress node, wherein the traffic ingress node selects the first service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rule, and sends the baseline traffic to the first service node; for any service node that receives the baseline traffic, selects the next service node on the grayscale link from the baseline environment and the feature environment based on the multi-level fallback routing rule, and sends the baseline traffic to the next service node, thereby switching the baseline traffic from the baseline link to the grayscale link.

[0124] In an optional embodiment, the multi-level fallback routing rule is specifically used to: instruct, upon receiving gray-scale traffic or baseline traffic, to identify whether the gray-scale traffic or baseline traffic is tagged access traffic; if the gray-scale traffic or baseline traffic is identified as tagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a feature version is preferentially selected; if no service node with a feature version is deployed, a service node with a gray-scale version is preferentially selected; if no service node with a gray-scale version is deployed, a service node with a baseline version is selected; if the gray-scale traffic or baseline traffic is identified as untagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a gray-scale version is preferentially selected; if no service node with a gray-scale version is deployed, a service node with a baseline version is selected.

[0125] In an optional embodiment, after deploying the first grayscale version in the baseline environment, the processor 55 is further configured to: if it is necessary to perform grayscale release of the first grayscale version, deploy a second grayscale version of the target service in the baseline environment to perform grayscale release of the second grayscale version; wherein the second grayscale version is a grayscale version of the first grayscale version.

[0126] In an optional embodiment, the multi-level fallback routing rule further includes: in the case of falling back to a gray-scale version, selecting service nodes on the gray-scale link in the order of falling back from the second gray-scale version to the first gray-scale version; and routing the gray-scale traffic to the gray-scale link to verify the first gray-scale version according to the multi-level fallback routing rule, including: routing the gray-scale traffic to the gray-scale link to verify the second gray-scale version according to the multi-level fallback routing rule.

[0127] In an optional embodiment, the multi-level fallback routing rule is specifically used to: instruct, upon receiving gray-scale traffic, to identify whether the gray-scale traffic is tagged access traffic; if the gray-scale traffic or baseline traffic is identified as tagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a feature version is preferentially selected; if no service node with a feature version is deployed, a service node with a second gray-scale version is preferentially selected; if no service node with a second gray-scale version is deployed, a service node with a first gray-scale version is selected; if no service node with a first gray-scale version is deployed, a service node with a baseline version is selected; if the gray-scale traffic or baseline traffic is identified as untagged access traffic, then when selecting a service node corresponding to any service on the gray-scale link, a service node with a second gray-scale version is preferentially selected; if no service node with a second gray-scale version is deployed, a service node with a first gray-scale version is selected; if no service node with a first gray-scale version is deployed, a service node with a baseline version is selected.

[0128] In an optional embodiment, the processor 55 is further configured to: if a rollback occurs during the verification of the grayscale version of the target service, switch the grayscale traffic in the grayscale link back to the baseline link according to a single-level fallback routing rule; and / or, if a rollback occurs during the process of switching the baseline traffic from the baseline link to the grayscale link, switch the grayscale traffic in the grayscale link and the baseline traffic already switched to the grayscale link back to the baseline link according to a single-level fallback routing rule; wherein the single-level fallback routing rule includes: for access traffic with labels, selecting service nodes on the baseline link in the order of fallback from the feature version to the baseline version; for access traffic without labels, directly selecting the service node where the baseline version is located as the service node on the baseline link.

[0129] In an optional embodiment, when the processor 55 switches gray traffic in the gray link back to the baseline link according to the single-level fallback routing rule, it specifically performs the following steps: It issues a second switching instruction to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to instruct a switch from the multi-level fallback routing rule to the single-level fallback routing rule; it sends the gray traffic into the traffic ingress node, which selects the first service node on the baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the gray traffic to the first service node; for any service node that receives the access traffic, it selects the next service node on the baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the gray traffic to the next service node, thereby switching the gray traffic in the gray link back to the baseline link.

[0130] In an optional embodiment, after switching the baseline traffic from the baseline link to the grayscale link, the processor 55 is further configured to: upgrade the baseline version of the target service in the baseline link to the grayscale version to obtain a new baseline version; according to the single-level fallback routing rules, switch the access traffic in the grayscale link back to the upgraded baseline link and release the resources occupied by the target service in the grayscale link; wherein, the single-level fallback routing rules include: for access traffic with labels, selecting service nodes on the baseline link in the order of fallback from feature version to baseline version; for access traffic without labels, directly selecting service nodes on the baseline link according to the baseline version.

[0131] In an optional embodiment, when the processor 55 switches the access traffic in the grayscale link back to the upgraded baseline link according to the single-level fallback routing rule, it specifically performs the following steps: It issues a third switching instruction to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to instruct a switch from the multi-level fallback routing rule to the single-level fallback routing rule; it sends the access traffic entering the baseline environment to the traffic ingress node, and the traffic ingress node selects the first service node on the upgraded baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the access traffic to the first service node; for any service node that receives the access traffic, it selects the next service node on the upgraded baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the access traffic to the next service node, thereby switching the access traffic in the grayscale link back to the upgraded baseline link.

[0132] Furthermore, as shown in Figure 5, the control device also includes other components such as a communication component 56, a display 57, a power supply component 58, and an audio component 59. Figure 5 only schematically shows some components and does not imply that the control device only includes the components shown in Figure 5. Additionally, the components within the dashed boxes in Figure 5 are optional, not mandatory, and their specific inclusion depends on the product form of the working node. The control device in this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or as a server-side device such as a conventional server, cloud server, or server array. If the control device in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed boxes in Figure 5; if the control device in this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed boxes in Figure 5.

[0133] This disclosure also provides an electronic device whose implementation structure is the same as or similar to that of the control device shown in FIG5, and can be implemented with reference to the structure of the control device shown in FIG5. The main difference between the electronic device provided in this embodiment and the control device in the embodiment shown in FIG5 is that: it receives a first access traffic, which is gray-scale traffic or baseline traffic; if the first access traffic is identified as having a label according to the multi-level fallback routing rules, it selects the next service node on the gray-scale link in the order of fallback from the feature version to the gray-scale version and then to the baseline version; if the first access traffic is identified as not having a label according to the multi-level fallback routing rules, it selects the next service node on the gray-scale link in the order of fallback from the gray-scale version to the baseline version; and sends the first access traffic to the next service node on the gray-scale link.

[0134] In an optional embodiment, if the service on the service node is not a grayscale version of the target service, the service node will also be located on the baseline link where the baseline version of the target service is located. The processor is further configured to: receive a switching instruction, the switching instruction being used to indicate a switch from the multi-level fallback routing rule to a single-level fallback routing rule; receive second access traffic, the second access traffic being grayscale traffic or baseline traffic; if the second access traffic is identified as having a label based on the single-level fallback routing rule, select the next service node on the baseline link in the order of fallback from the feature version to the baseline version; if the second access traffic is identified as not having a label based on the single-level fallback routing rule, directly select the next service node on the baseline link according to the baseline version; and send the second access traffic to the next service node on the baseline link.

[0135] Accordingly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the methods described above.

[0136] This disclosure also provides a computer program product, which includes a computer program / instructions that, when executed by a processor, enable the processor to perform the steps described in the method embodiments above.

[0137] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0138] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0139] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0140] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0141] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0142] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0143] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0144] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0145] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0146] In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory.

[0147] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0148] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0149] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0150] The above are merely embodiments of this disclosure and are not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A service publishing method, applied to an application system including multiple services, the application system including a baseline environment and at least one feature environment, wherein the baseline environment deploys baseline versions of the multiple services, and the feature environment is empty or deploys a feature version of at least one service, the method comprising: If a canary release of a target service is required in the baseline environment, the first canary version of the target service shall be deployed in the baseline environment. Access traffic entering the baseline environment is divided into grayscale traffic and baseline traffic, wherein the access traffic includes at least tagged access traffic from at least some characteristic environments; According to the multi-level fallback routing rules, the gray-scale traffic is routed to the gray-scale link to verify the first gray-scale version. The gray-scale link includes the service node where the first gray-scale version is located. If the verification is successful, the baseline traffic is switched from the baseline link to the grayscale link according to the multi-level fallback routing rules. The baseline link includes the service node where the baseline version of the target service is located. The multi-level fallback routing rules include: for access traffic with labels, service nodes on the gray-scale link are selected in the order of fallback from the feature version to the gray-scale version and then to the baseline version; for access traffic without labels, service nodes on the gray-scale link are selected in the order of fallback from the gray-scale version to the baseline version.

2. The method according to claim 1, wherein, According to the multi-level fallback routing rules, the gray-scale traffic is routed to the gray-scale link to verify the first gray-scale version, including: The multi-level fallback routing rules are issued to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively. The gray-scale traffic is sent to the traffic ingress node. The traffic ingress node selects the first service node on the gray-scale link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sends the gray-scale traffic to the first service node. For any service node that receives the grayscale traffic, the next service node on the grayscale link is selected from the baseline environment and the feature environment based on the multi-level fallback routing rules, and the grayscale traffic is sent to the next service node to verify the first grayscale version. Among them, any service node has a feature version, gray version or baseline version of any service called by the gray traffic, and the service called by the gray traffic includes at least the target service.

3. The method according to claim 1, wherein, According to the multi-level fallback routing rules, the baseline traffic is switched from the baseline link to the grayscale link, including: A first switching instruction is issued to the traffic ingress node and service node in the baseline environment to indicate a switch from the single-level fallback routing rule to the multi-level fallback routing rule. The single-level fallback routing rule is used at least to route the baseline traffic to the baseline link. The baseline traffic is sent to the traffic ingress node, and the traffic ingress node selects the first service node on the gray link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sends the baseline traffic to the first service node; For any service node that receives the baseline traffic, the next service node on the gray link is selected from the baseline environment and the feature environment based on the multi-level fallback routing rules, and the baseline traffic is sent to the next service node to switch the baseline traffic from the baseline link to the gray link.

4. The method according to any one of claims 1-3, wherein, The multi-level fallback routing rules are specifically used for: Instructions to identify whether grayscale traffic or baseline traffic is tagged access traffic when grayscale traffic or baseline traffic is received; If the gray-scale traffic or baseline traffic is identified as tagged access traffic, when selecting a service node corresponding to any service on the gray-scale link, the service node with the feature version is selected first; if there is no service node with the feature version, the service node with the gray-scale version is selected first; if there is no service node with the gray-scale version, the service node with the baseline version is selected. If the gray-scale traffic or baseline traffic is identified as unlabeled access traffic, when selecting a service node corresponding to any service on the gray-scale link, the service node with the gray-scale version is selected first. If there is no service node with the gray-scale version, the service node with the baseline version is selected.

5. The method according to any one of claims 1-3, wherein, After deploying the first grayscale version in the baseline environment, the following steps are also included: If it is necessary to perform a canary release of the first canary version, deploy a second canary version of the target service in the baseline environment to perform a canary release of the second canary version; The second grayscale version is a grayscale version of the first grayscale version.

6. The method according to claim 5, wherein, The multi-level rollback routing rules also include: when rolling back to a gray-scale version, selecting service nodes on the gray-scale link in the order of rolling back from the second gray-scale version to the first gray-scale version; According to the multi-level fallback routing rules, the gray-scale traffic is routed to the gray-scale link to verify the first gray-scale version, including: According to the multi-level fallback routing rules, the grayscale traffic is routed to the grayscale link to verify the second grayscale version.

7. The method according to claim 6, wherein, The multi-level fallback routing rules are specifically used for: The instruction indicates that upon receiving grayscale traffic, it should identify whether the grayscale traffic is tagged access traffic. If the gray-scale traffic or baseline traffic is identified as tagged access traffic, when selecting a service node corresponding to any service on the gray-scale link, the service node with the feature version is selected first; if no service node with the feature version is deployed, the service node with the second gray-scale version is selected first; if no service node with the second gray-scale version is deployed, the service node with the first gray-scale version is selected; if no service node with the first gray-scale version is deployed, the service node with the baseline version is selected. If the gray-scale traffic or baseline traffic is identified as unlabeled access traffic, when selecting a service node corresponding to any service on the gray-scale link, the service node with the second gray-scale version is selected first; if there is no service node with the second gray-scale version, the service node with the first gray-scale version is selected; if there is no service node with the first gray-scale version, the service node with the baseline version is selected.

8. The method according to any one of claims 1-3, further comprising: If a rollback occurs during the verification of the gray version of the target service, the gray traffic in the gray link will be switched back to the baseline link according to the single-level fallback routing rules. and / or During the process of switching the baseline traffic from the baseline link to the gray link, a rollback occurs. According to the single-level fallback routing rule, the gray traffic in the gray link and the baseline traffic that has been switched to the gray link are switched back to the baseline link. The single-level fallback routing rules include: for access traffic with labels, selecting service nodes on the baseline link in the order of fallback from the feature version to the baseline version; for access traffic without labels, directly selecting the service node where the baseline version is located as the service node on the baseline link.

9. The method according to claim 8, wherein, According to the single-level fallback routing rules, the gray-scale traffic in the gray-scale link is switched back to the baseline link, including: A second switching instruction is issued to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to indicate the switch from the multi-level fallback routing rule to the single-level fallback routing rule; The grayscale traffic is sent to the traffic ingress node. The traffic ingress node selects the first service node on the baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the access traffic to the first service node. For any service node that receives the grayscale traffic, the next service node on the baseline link is selected from the baseline environment and the feature environment based on the single-level fallback routing rule, and the grayscale traffic is sent to the next service node to switch the grayscale traffic in the grayscale link back to the baseline link.

10. The method according to any one of claims 1-3, wherein, After switching the baseline traffic from the baseline link to the grayscale link, the process also includes: Upgrade the baseline version of the target service in the baseline link to a grayscale version to obtain a new baseline version; According to the single-level fallback routing rules, the access traffic in the gray-scale link is switched back to the upgraded baseline link, and the resources occupied by the target service in the gray-scale link are released. The single-level fallback routing rules include: for access traffic with labels, selecting service nodes on the baseline link in the order of fallback from the feature version to the baseline version; for access traffic without labels, directly selecting service nodes on the baseline link according to the baseline version.

11. The method according to claim 10, wherein, According to the single-level fallback routing rules, the access traffic in the gray-scale link is switched back to the upgraded baseline link, including: A third switching instruction is issued to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively, to indicate the switch from the multi-level fallback routing rule to the single-level fallback routing rule; Access traffic entering the baseline environment is sent to the traffic ingress node. The traffic ingress node selects the first service node on the upgraded baseline link from the baseline environment and the feature environment based on the single-level fallback routing rule, and sends the access traffic to the first service node. For any service node that receives the access traffic, the next service node on the upgraded baseline link is selected from the baseline environment and the feature environment based on the single-level fallback routing rule, and the access traffic is sent to the next service node to switch the access traffic in the gray link back to the upgraded baseline link.

12. A service routing method, applied to service nodes in a baseline environment or a feature environment of an application system, wherein any service on a gray-scale deployment link where a target service is located is deployed on the service node, and multi-level fallback routing rules are pre-configured, wherein the target service is a service that needs to be gray-scale deployed, the method comprising: Receive the first access traffic, which is either grayscale traffic or baseline traffic; If the first access traffic is identified as having a label according to the multi-level fallback routing rules, the next service node on the grayscale link is selected in the order of fallback from the feature version to the grayscale version and then to the baseline version. If the first access traffic is identified as not having a label according to the multi-level back-route rules, the next service node on the gray-scale link is selected in the order of back-down from the gray-scale version to the baseline version. The first access traffic is sent to the next service node on the grayscale link.

13. The method according to claim 12, wherein, If the service on the service node is not a grayscale version of the target service, the service node will also be located on the baseline link where the baseline version of the target service is located. The method further includes: Receive a switching instruction, the switching instruction being used to indicate a switch from the multi-level fallback routing rule to a single-level fallback routing rule; A second access traffic is received, which is either grayscale traffic or baseline traffic; If the second access traffic is identified as having a label based on the single-level fallback routing rule, the next service node on the baseline link is selected in the order of fallback from the feature version to the baseline version; If the second access traffic is identified as not having a label based on the single-level fallback routing rule, the next service node on the baseline link is selected directly according to the baseline version. The second access traffic is sent to the next service node on the baseline link.

14. A control device applied to an application system comprising multiple services, the application system comprising a baseline environment and at least one feature environment, wherein the baseline environment deploys baseline versions of the multiple services, and the feature environment is empty or deploys a feature version of at least one service; wherein, The control device includes a memory and a processor. The memory stores a computer program, and the processor is coupled to the memory and executes the computer program to perform the following operations: If a canary release of a target service is required in the baseline environment, the first canary version of the target service shall be deployed in the baseline environment. Access traffic entering the baseline environment is divided into grayscale traffic and baseline traffic, wherein the access traffic includes at least tagged access traffic from at least some characteristic environments; According to the multi-level fallback routing rules, the gray-scale traffic is routed to the gray-scale link to verify the first gray-scale version. The gray-scale link includes the service node where the first gray-scale version is located. If the verification is successful, the baseline traffic is switched from the baseline link to the grayscale link according to the multi-level fallback routing rules. The baseline link includes the service node where the baseline version of the target service is located. The multi-level fallback routing rules include: for access traffic with labels, service nodes on the gray-scale link are selected in the order of fallback from the feature version to the gray-scale version and then to the baseline version; for access traffic without labels, service nodes on the gray-scale link are selected in the order of fallback from the gray-scale version to the baseline version.

15. The control device according to claim 14, wherein, According to the multi-level fallback routing rules, the gray-scale traffic is routed to the gray-scale link to verify the first gray-scale version, including: The multi-level fallback routing rules are issued to the traffic ingress node and service node in the baseline environment and the service node in the feature environment, respectively. The gray-scale traffic is sent to the traffic ingress node. The traffic ingress node selects the first service node on the gray-scale link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sends the gray-scale traffic to the first service node. For any service node that receives the grayscale traffic, the next service node on the grayscale link is selected from the baseline environment and the feature environment based on the multi-level fallback routing rules, and the grayscale traffic is sent to the next service node to verify the first grayscale version. Among them, any service node has a feature version, gray version or baseline version of any service called by the gray traffic, and the service called by the gray traffic includes at least the target service.

16. The control device according to claim 14, wherein, According to the multi-level fallback routing rules, the baseline traffic is switched from the baseline link to the grayscale link, including: A first switching instruction is issued to the traffic ingress node and service node in the baseline environment to indicate a switch from the single-level fallback routing rule to the multi-level fallback routing rule. The single-level fallback routing rule is used at least to route the baseline traffic to the baseline link. The baseline traffic is sent to the traffic ingress node, and the traffic ingress node selects the first service node on the gray link from the baseline environment and the feature environment based on the multi-level fallback routing rules, and sends the baseline traffic to the first service node; For any service node that receives the baseline traffic, the next service node on the gray link is selected from the baseline environment and the feature environment based on the multi-level fallback routing rules, and the baseline traffic is sent to the next service node to switch the baseline traffic from the baseline link to the gray link.

17. The control device according to any one of claims 14-16, wherein, The multi-level fallback routing rules are specifically used for: Instructions to identify whether grayscale traffic or baseline traffic is tagged access traffic when grayscale traffic or baseline traffic is received; If the gray-scale traffic or baseline traffic is identified as tagged access traffic, when selecting a service node corresponding to any service on the gray-scale link, the service node with the feature version is selected first; if there is no service node with the feature version, the service node with the gray-scale version is selected first; if there is no service node with the gray-scale version, the service node with the baseline version is selected. If the gray-scale traffic or baseline traffic is identified as unlabeled access traffic, when selecting a service node corresponding to any service on the gray-scale link, the service node with the gray-scale version is selected first. If there is no service node with the gray-scale version, the service node with the baseline version is selected.

18. An application system, comprising: A baseline environment and at least one feature environment; the baseline environment has baseline versions of multiple services deployed, and the feature environment is either empty or has a feature version of at least one service deployed. In the baseline environment, a first grayscale version of the target service is also deployed, and the target service is at least one of the multiple services that needs to be grayscale released. The application system further includes: a management and control device; the management and control device is used to execute the steps in the method of any one of claims 1-11 to achieve end-to-end lossless publishing of the target service.

19. A computer-readable storage medium storing a computer program / instructions, wherein, When the computer program / instructions are executed by the processor, the processor is enabled to perform the steps of the method according to any one of claims 1-11.

20. A computer program product comprising: A computer program / instruction, wherein when the computer program / instruction is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-11.

Images