WO2024078025A1

WO2024078025A1 - Traffic isolation method, apparatus, and system, and computer-readable storage medium

Info

Publication number: WO2024078025A1
Application number: PCT/CN2023/103668
Authority: WO
Inventors: 林生琴; 陶建波; 王先荣; 薛军
Original assignee: 华为技术有限公司
Priority date: 2022-10-10
Filing date: 2023-06-29
Publication date: 2024-04-18
Also published as: CN117908942A

Abstract

Disclosed are a traffic isolation method, apparatus, and system, and a computer readable storage medium, for achieving traffic isolation between different versions of a microservice. The method is applied to a microservice cluster, the microservice cluster comprising a plurality of swimlanes, each swimlane comprising a plurality of deployment units, and each deployment unit being a microservice instance of a microservice; each deployment unit is configured with a routing address set, and addresses in the routing address set are all addresses of other deployment units in a swimlane to which the deployment unit belongs. The method comprises: a deployment unit sending a call request to a target microservice; and a routing module of a deployment unit using the routing address set to route the call request to a deployment unit corresponding to the target microservice.

Description

Traffic isolation method, device, system and computer readable storage medium

This application claims priority to the Chinese patent application filed with the China Patent Office on October 10, 2022, with application number 202211234556.8 and invention name “Traffic isolation method, device, system and computer-readable storage medium”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of Internet technology, and in particular to a traffic isolation method, device, system and computer-readable storage medium.

Background technique

Grayscale release is to deploy the old and new versions of the application in the environment at the same time. Business requests may be routed to the old version (official version) or the new version (grayscale version). The grayscale release process needs to be combined with the grayscale release strategy to determine which traffic is routed to the new version, so as to control which users use the new version functions. During the grayscale release process, since there are multiple versions of software in the environment, in order to avoid business failures due to version compatibility issues, it is necessary to isolate the traffic versions, that is, the traffic flowing into the old version will keep calling the old version when calling between microservices; the traffic flowing into the new version will keep calling the new version when calling between microservices.

The current traffic isolation solution mainly implements the isolation between the grayscale version of traffic and the official version of traffic by transmitting grayscale marks through traffic. Specifically, the gateway compares the content of the traffic (composed of request messages) with the grayscale release policy, adds a grayscale mark to the header of the request message that complies with the grayscale release policy, and routes the request message with the grayscale mark to the first service of the grayscale version, otherwise the traffic is routed to the first service of the official version. If this request causes a call to the next service, the service will put the grayscale mark in the header of the call request message when sending a call request to the next service. Traffic routing is implemented according to the grayscale mark of the traffic to achieve traffic isolation.

However, in some scenarios, such as when the received request and the call request to be sent are not in the same thread, the grayscale mark is lost because the grayscale mark does not support cross-thread transmission, causing the isolation of different versions of traffic to fail.

Summary of the invention

The present application provides a traffic isolation method, device, system and computer-readable storage medium to achieve traffic isolation between microservices of different versions.

The first aspect provides a traffic isolation method. The method is applied to a microservice cluster, the microservice cluster includes multiple lanes, and each lane includes deployment units corresponding to multiple microservices. Among them, each deployment unit is a microservice instance of a microservice. The deployment unit is configured with a routing address set, and the addresses in the routing address set are all addresses of other deployment units in the lane to which the deployment unit belongs. The routing address set indicates the deployment unit that can be selected when calling other microservices. The method includes that the deployment unit sends a call request to the target microservice to call the target microservice, the routing module of the deployment unit intercepts the call request, and routes the call request to the deployment unit corresponding to the target microservice according to the routing address set. Thus, by configuring the deployment unit in the grayscale lane with only the address routing address set of the deployment unit in the grayscale lane, it is ensured that when the deployment unit of a certain service calls the deployment unit of other services, the call request can be routed to the deployment unit in the same grayscale lane without passing the grayscale label through the traffic, so as to ensure the traffic isolation in the grayscale lane and make the upgrade smoother.

In a possible implementation, each lane includes at least one deployment unit corresponding to all microservices on the call link. Therefore, the call of microservices of the entire call link can be implemented in the same lane without calling deployment units in other lanes, and traffic isolation between different lanes can be achieved.

In a possible implementation, the multiple lanes include a grayscale lane, which includes at least one grayscale version of a microservice, and the grayscale lane is used to implement the grayscale release of at least one grayscale version of a microservice. Based on the grayscale lane, the traffic in the grayscale lane is completely isolated from the traffic in other lanes, which can avoid business failures caused by version compatibility issues and smoothly implement microservice upgrades.

In a possible implementation, the method further includes: a routing module of the deployment unit obtains a routing strategy from the control module, the routing strategy includes a routing address set and a routing rule. The routing module of the deployment unit routes the call request to the deployment unit corresponding to the target microservice according to the routing address set, including: the routing module of the deployment unit determines the target address of the deployment unit corresponding to the target microservice in the routing address set according to the routing rule; the routing module of the deployment unit routes the call request to the deployment unit corresponding to the target microservice according to the target address.

The second aspect provides a traffic isolation method. The method is implemented by a lane state management module and a control module of the management plane. The method includes: the lane state management module manages multiple lanes in the microservice cluster according to the target lane state instruction, each lane includes multiple deployment units, each A deployment unit is a microservice instance of a microservice; the control module sends a routing policy to the deployment unit in each lane, and the routing policy includes a routing address set. The addresses in the routing address set are all addresses of the deployment units in the lane to which the deployment unit belongs, so that the deployment unit calls other deployment units in the lane to which the deployment unit belongs according to the routing address set.

In a possible implementation, each lane includes at least one deployment unit corresponding to all microservices on the call link.

In a possible implementation, the multiple lanes include a grayscale lane, the grayscale lane includes at least one grayscale version of a microservice, and the grayscale lane is used to implement the grayscale release of at least one grayscale version of a microservice.

The third aspect provides a traffic isolation device. The traffic isolation device is a device in a microservice cluster, the microservice cluster includes multiple lanes, each lane includes multiple traffic isolation devices, each traffic isolation device is a microservice instance of a microservice, the traffic isolation device is configured with a routing address set, the addresses in the routing address set are all addresses of other traffic isolation devices in the lane to which the traffic isolation device belongs, and the device includes a calling module and a routing module. Among them, the calling module is used to send a call request to the target microservice. The routing module is used to route the call request to the deployment unit corresponding to the target microservice according to the routing address set.

In a possible implementation, each lane includes at least one traffic isolation device corresponding to all microservices on the call link.

In a possible implementation, the routing module is used to obtain a routing strategy from the control module, the routing strategy including a routing address set and a routing rule. The routing module is specifically used to determine a target address of a deployment unit corresponding to a target microservice in the routing address set according to the routing rule. The routing module is specifically used to route a call request to a deployment unit corresponding to a target microservice according to the target address.

The fourth aspect provides a traffic isolation system. The system includes a lane state management module, a control module and multiple deployment units. Among them, the lane state management module is used to manage multiple lanes in the microservice cluster according to the target lane state instruction, each lane includes multiple deployment units, and each deployment unit is a microservice instance of a microservice. The control module is used to issue a routing policy to the deployment unit in each lane, and the routing policy includes a routing address set. The addresses in the routing address set are all addresses of the deployment units in the lane to which the deployment unit belongs. The deployment unit is used to call other deployment units in the lane to which the deployment unit belongs according to the routing address set.

The fifth aspect provides a traffic isolation device, which includes a processor and a memory, the processor is coupled to the memory, and the processor is configured to execute the traffic isolation method in the first aspect or any possible implementation of the first aspect, or the traffic isolation method in the second aspect or any possible implementation of the second aspect based on instructions stored in the memory.

The sixth aspect provides a computer-readable storage medium, comprising instructions, which, when the computer-readable storage medium is run on a computer, enables the computer to perform the operations of the traffic isolation method in the first aspect or any possible implementation of the first aspect, or the traffic isolation method in the second aspect or any possible implementation of the second aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1a is a schematic diagram of traffic distribution before grayscale release provided by the present application;

FIG1b is a schematic diagram of traffic distribution during grayscale release provided by the present application;

FIG1c is a schematic diagram of traffic distribution after the grayscale release is completed provided by the present application;

FIG2 is a schematic diagram of a method of grayscale marking based on SDK transparent transmission provided by the present application;

FIG3 is a schematic diagram of a grayscale marking method based on a load balancer transparent transmission provided by the present application;

FIG4 is a schematic diagram of the structure of a flow isolation system provided by the present application;

FIG5 is a flow chart of a flow isolation method provided by the present application;

FIG6 is a schematic diagram of the structure of another flow isolation system provided by the present application;

FIG7 is a flow chart of another flow isolation method provided by the present application;

FIG8 is a schematic diagram of a traffic isolation scenario provided by the present application;

FIG9 is a schematic structural diagram of a flow isolation device provided by the present application;

FIG. 10 is a schematic diagram of the structure of another flow isolation device provided in the present application.

Detailed ways

The present application provides a traffic isolation method, device, system and computer-readable storage medium to achieve traffic isolation between microservices of different versions without transmitting grayscale labels through traffic.

In this application, the words "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

In the embodiments of the present application, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the present application, unless otherwise specified, "plurality" means two or more.

The term "at least one" in this application means one or more, and the term "multiple" in this application means two or more, for example, multiple second messages means two or more second messages. The terms "system" and "network" are often used interchangeably herein.

It should be understood that the terms used in the description of the various examples herein are only for describing specific examples and are not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should also be understood that the term "and/or" used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The term "and/or" is a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character "/" in this application generally indicates that the associated objects before and after are in an "or" relationship.

It should also be understood that in the various embodiments of the present application, the size of the serial number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

It should be understood that determining B based on A does not mean determining B only based on A. B can also be determined based on A and/or other information.

It should also be understood that the term “comprise” (also known as “includes,” “including,” “comprises” and/or “comprising”) when used in this specification specifies the presence of stated features, integers, steps, operations, elements, and/or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "if" may be interpreted to mean "when" or "upon" or "in response to determining" or "in response to detecting." Similarly, the phrase "if it is determined that ..." or "if [a stated condition or event] is detected" may be interpreted to mean "upon determining that ..." or "in response to determining that ..." or "upon detecting [a stated condition or event]" or "in response to detecting [a stated condition or event]," depending on the context.

It should be understood that the references to "one embodiment", "an embodiment", or "a possible implementation" throughout the specification mean that specific features, structures, or characteristics related to the embodiment or implementation are included in at least one embodiment of the present application. Therefore, the references to "in one embodiment" or "in an embodiment", or "a possible implementation" appearing throughout the specification do not necessarily refer to the same embodiment. In addition, these specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

With the development of computer application technology, in order to better utilize resources and realize rapid deployment of applications, applications can be split into multiple microservices. Microservices are used to provide external services, and each microservice supports mutual connection and access to realize the functional services of the overall application. Each microservice is a small functional block focusing on a single responsibility and function, and several microservices are combined to form a complex large-scale application. Each microservice has its own process, which can communicate with other microservices through lightweight communication mechanisms, such as application programming interfaces (APIs) based on hypertext transfer protocol (HTTP).

Microservice architecture is an architecture that splits applications (especially large applications, such as e-commerce systems, social platforms, or financial systems) into several microservices. In some examples, microservice architecture can specifically include classic architectures such as Spring Cloud and Dubbo, which are less invasive. Compared with the traditional monolithic architecture that concentrates all functional services in one container, the microservice architecture achieves business decoupling by decomposing functions into discrete services. Each business team maintains the microservices corresponding to their respective businesses, which reduces maintenance complexity and improves maintenance efficiency. Moreover, when a single microservice fails, other microservices can continue to work, which improves system stability.

In some cases, there may be a calling relationship between multiple microservices of an application, that is, multiple microservices may form at least one calling link. For example, when executing a request, microservice A calls microservice B, and microservice B calls microservice C and microservice D. A calling chain is from microservice A to microservice B, and from microservice B to microservice C and microservice D. For example, in the application scenario of an e-commerce system, the microservice of the product system may also call the microservice of the evaluation system to display the user's historical evaluation of the product when displaying the product details. price.

Service governance is the process of handling the relationship between service calls in a distributed service framework. Service governance can be divided into the following levels: service registration and discovery, load balancing, fault handling and recovery (current limiting, circuit breaking, timeout, retry), grayscale release, and service tracking.

Currently, applications based on microservice architecture can also implement service governance through service mesh. Service mesh is an infrastructure layer used to handle communication between services (including microservices). One way to implement service mesh is to assign a separate agent to each microservice, which is also called a sidecar. Among them, the agent is responsible for handling communication, monitoring and some security-related work between services, thereby providing functions such as service discovery, load balancing, encryption, identity authentication, authorization and fuse. The microservice itself is no longer responsible for processing the specific logic of business requests, such as balancing based on business requests, etc., and only needs to complete business processing.

The sidecar can intercept all network traffic of the corresponding microservice, allowing traffic control functions to be provided according to the configuration set by the user. The sidecar is deployed with each microservice started in the cluster, or runs with microservices running on virtual machines or containers.

In a microservices architecture, canary release generally refers to a method of smoothly transitioning and upgrading between at least two versions of a microservice.

Exemplarily, as shown in Figures 1a to 1c, the grayscale release can deploy the old version v1 and the new version v2 of the microservice in the environment at the same time, and the access request may be routed to the old version v1 or the new version v2. In the grayscale release process, the new version can also be called a grayscale version or a test version. The traffic proportion of the v1 version and the v2 version can be adjusted by defining a grayscale release strategy. When the application releases a new version, the grayscale release can customize the user and traffic proportion of the new version, gradually complete the full launch of the new version of the application, and maximize the control of the business risks brought by the release of the new version and reduce the impact of the failure. As shown in Figure 1a, before the grayscale release, 100% of the traffic is on the v1 version of the service. As shown in Figure 1a, during the grayscale release, the v2 version of the service is deployed, and the traffic of a small number of users is introduced to the new version of the service through the release strategy control. As shown in Figure 1c, after the grayscale release verification is passed, the traffic of all users is gradually introduced to the new version of the service to achieve the purpose of version upgrade.

The grayscale release process needs to be combined with the grayscale release strategy to determine which traffic is routed to the v2 version, so as to control which users use the new version functions. There are currently two main strategies: based on traffic ratio and based on traffic content. Among them, based on traffic ratio, the traffic ratio is configured for different versions, for example, 20% of the traffic uses the new version and 80% of the traffic uses the old version. Based on traffic content, specifically, the user identity information (cookie), message header (header), parameters (param) and other content in the traffic are parsed. Only access traffic that meets the rule constraints, such as access traffic from specific users or clients, can access the new version.

During the grayscale release process, since there are multiple versions of microservices in the environment, in order to avoid business failures due to version compatibility issues, traffic needs to be version isolated. That is, traffic flowing into the old version v1 will keep calling the old version v1 when calling between microservices; traffic flowing into the new version v2 will keep calling the new version v2 when calling between microservices.

Currently, different versions of traffic can be isolated through software routing isolation. Software routing isolation is achieved by transparently transmitting grayscale marks in traffic, so that microservices can determine which version of microservice to route to next hop based on the grayscale marks in the request. There are two specific implementation methods, one is to transparently transmit the grayscale marks in the request through the software development kit (SDK), and the other is to transparently transmit the grayscale marks in the request through the load balancer (LB).

As shown in Figure 2, Figure 2 is a schematic diagram of the method of SDK transparent transmission of grayscale tags provided by this application. Specifically, after the traffic passes through the gateway, the gateway adds a grayscale tag to the header of the request for traffic that meets the grayscale policy (composed of multiple request messages, the request message will be referred to as the request below). For example, in Figure 2, the field color=read is added to the header of the request. After the traffic enters the first service microservice A, the SDK extracts the grayscale tag in the header of the request and caches it. When microservice A wants to send a request to microservice B, the SDK extracts the cached grayscale tag and determines whether to send the request to the address of the grayscale version (v2) or the address of the official version (v1) based on the value of the grayscale tag. When the SDK sends a request, it also carries this grayscale tag in the header of the request for subsequent microservices to determine the destination of the request.

As shown in Figure 3, Figure 3 is a schematic diagram of the method of transparent transmission of grayscale marks based on the load balancer provided by the present application. Specifically, after the traffic passes through the gateway, the gateway adds a grayscale mark to the header of the request for traffic that meets the grayscale policy. For example, in Figure 2, the field color=read is added to the header of the request. When microservice A wants to send a request to microservice B, microservice A carries the grayscale mark of the upper entry request in the request and sends it to the load balancer. The load balancer confirms the address of the next-hop microservice based on the grayscale mark in the request. Similarly, for subsequent traffic on the calling link, microservices need to continue to transparently transmit grayscale marks to help subsequent microservices determine the address of the next-hop calling object.

However, no matter which of the above traffic isolation methods is used, there may be a situation where the grayscale mark is lost. For example, the received request and the request to be sent are in different threads, and the grayscale mark does not support cross-thread transmission, resulting in the loss of the grayscale mark. Grayscale marking cannot achieve subsequent traffic isolation, affecting the stability of the system and making different versions of microservices incompatible during the grayscale release process.

Therefore, the present application provides the following embodiments to solve the problem that different versions of microservices cannot be smoothly compatible due to the loss of grayscale marks.

The present application provides a software routing isolation solution to achieve lane-level traffic isolation. Specifically, when there are multiple versions of microservices in a microservice cluster (each version of the microservice corresponds to at least one deployment unit), and the traffic of multiple versions of microservices needs to be isolated, the present application uses the deployment unit as the granularity to divide the deployment units of microservices belonging to different versions into different lanes in the microservice cluster. In this embodiment, the lane that includes the grayscale version of the microservice is called the grayscale lane, and the lane that does not include the grayscale version of the microservice is called the formal lane. In addition, the grayscale lane also includes the deployment units of the microservices that have a call relationship with the grayscale version of the microservice, that is, the grayscale lane includes the deployment units corresponding to all microservices in the call link where the grayscale version is located.

Furthermore, some microservices in the lane need to call other microservices. The routing modules in the deployment units corresponding to these microservices that need to call other microservices are all configured with a routing address set. The addresses in the routing address set are all the addresses of the deployment units in the lane where the deployment unit is located. When the deployment unit of a certain microservice needs to call other microservices, it will send a call request to the target microservice that needs to be called. The routing module of the deployment unit that calls the target microservice determines the address of the deployment unit of the target microservice in the routing address set, and routes the call request to the corresponding deployment unit according to the address. Since the addresses in the routing address set are all the addresses of the deployment units in the same lane, the call request will only be routed to the deployment unit in the same lane, and will not be routed to the deployment units in other lanes, that is, the deployment unit in one lane will not call the deployment unit in other lanes. Thus, the traffic in different lanes is isolated from each other. Since the call request is routed through the routing address set, the traffic can be kept in the same lane, and isolation can be achieved without the need to pass the grayscale mark through the traffic, so that the grayscale mark will not be lost, resulting in the failure of traffic isolation, so that the grayscale release process will be smoothly transitioned.

The above is the implementation principle of the present application. The following is a detailed description of possible implementation methods for implementing the above principle.

As shown in Figure 4, Figure 4 is a schematic diagram of the structure of a traffic isolation system provided by the present application. In this embodiment, the traffic isolation system includes a lane state management module, a control module and multiple deployment units.

Among them, the lane state management module is used to manage multiple lanes in the microservice cluster. Managing lanes can refer to creating, modifying and deleting lanes. Creating a lane specifically includes, for example, establishing a mapping relationship between a lane and a deployment unit. Modifying a lane includes, for example, adding or subtracting deployment units in a lane. Deleting a lane includes, for example, deleting the mapping relationship between a lane and a deployment unit to release the deployment unit. In this embodiment, a lane is a logically isolated environment.

The lane state management module specifically manages multiple lanes according to the target lane state instruction. The target lane state instruction, for example, includes one or more of the lanes that need to be modified/created, the microservices included in the lane, the version corresponding to each microservice in the lane, and the number of deployment units corresponding to each microservice in the lane. The lane state management module creates or modifies the lane according to the target lane state instruction. The lane created by the lane state management module includes deployment units of multiple microservices, and the microservices in the lane, the version of each microservice, and the number of deployment units of each microservice are the same as those indicated by the target lane state instruction.

Each deployment unit is a microservice instance, which is the smallest deployable computing unit created and managed in a microservice cluster. Each deployment unit is the smallest scheduling unit, or it can be called an atomic scheduling unit. A deployment unit belongs to only one microservice and only to the same lane. The multiple lanes of a microservice cluster can include one formal lane and at least one grayscale lane. The versions of microservices in the formal lane are all formal versions. The versions of microservices in the grayscale lane can all be grayscale versions, or some microservices can be formal versions and some can be grayscale versions. For example, if microservice C has only one version, but when it is called by a grayscale version of a microservice, the grayscale lane will also include the deployment unit of microservice C.

In order to ensure the isolation of traffic of different versions, only one version of the same microservice is included in a lane. For example, if microservice D has two versions v1 and v2, only one version of microservice D is included in any lane, and there will be no situation where both v1 and v2 of microservice D exist in the same lane.

In this embodiment, each lane includes at least one deployment unit corresponding to all microservices in the call link. That is, the call of all microservices on the entire call link can be completed in the same lane without calling the deployment unit of the microservices in other lanes, ensuring the traffic isolation between different lanes.

Taking a microservice cluster based on Kubernetes (k8s) as an example, a deployment unit can be a pod. The lane state management module establishes a mapping relationship between lanes and deployment units, which can be achieved by labeling deployment units. The labels of deployment units in the same lane are the same, and the labels of deployment units in different lanes are different. Labels are key-value pairs attached to Kubernetes objects (such as pods). Labels can be used to organize and select subsets of objects. Labels can be attached to objects when they are created, and can be added and modified at any time. Each object can define a set of key/value labels. Each key must be unique for a given object.

The control module reorganizes the routing strategy for each deployment unit in each lane according to the mapping relationship between lanes and deployment units. The strategy includes routing rules and routing address sets. Routing rules, such as round-robin or weighted round-robin, are used to instruct the deployment unit to select the deployment unit to call from the routing address set according to the routing rules. The routing address set is a collection of the addresses of the deployment units in the same lane. After the control module generates the routing strategy for each deployment unit, it sends the corresponding routing strategy to the deployment unit.

The deployment unit routes the traffic according to the routing strategy, that is, the scheduling of microservices. The deployment unit includes an application function module and a routing module. The application function module includes an application program of the microservice, which is used to perform the corresponding function. The routing module is used for the request issued by the application function module, and routes and forwards the request according to the routing strategy. Specifically, when the traffic passes through the gateway, the gateway routes the traffic to the corresponding lane according to the grayscale release strategy. The grayscale release strategy can be based on the traffic ratio or the traffic content, which is not limited here. If the request in the traffic causes the deployment unit to call other microservices, the application function module of the deployment unit sends a call request to the target microservice that needs to be called. The routing module of the deployment unit determines the address of a deployment unit of a target microservice in the routing address set according to the routing rules, and routes the call request to the corresponding deployment unit according to the address. For example, the routing address set includes the addresses corresponding to 10 deployment units of the target service. The routing module of the deployment unit determines an address among the 10 addresses by polling or weighted polling, and sends the call request to the corresponding deployment unit, thereby realizing traffic isolation and load balancing.

As shown in Figure 5, Figure 5 is a flow chart of a traffic isolation method provided by the present application. The execution subject of this embodiment is a deployment unit corresponding to any microservice in the microservice cluster that participates in calling other microservices.

S501: A first deployment unit sends a call request to a target microservice. The first deployment unit belongs to a deployment unit in a lane in a microservice cluster. The microservice cluster includes multiple lanes. Each lane includes multiple deployment units. Each deployment unit is a microservice instance of a microservice.

S502: The routing module of the first deployment unit routes the call request to the second deployment unit corresponding to the target microservice according to the routing address set, where the addresses in the routing address set are all addresses of other deployment units in the lane to which the first deployment unit belongs, and the addresses in the routing address set include the address of the second deployment unit.

The specific implementation process can be found in the above-mentioned related description, so it will not be repeated here.

In this process, the routing module of the deployment unit does not need to add a tag for traffic isolation in the request message, because the routing module of the deployment unit can achieve the isolation of traffic in different lanes through the routing address set. Traffic does not need to be isolated by passing tags, so there is no problem of traffic isolation confusion and failure caused by tag loss, which leads to smooth compatibility of the system during the upgrade process, thus achieving a smooth and stable upgrade.

Exemplarily, the microservice cluster is a k8s cluster, the deployment unit is a pod, the control module is a service grid istiod, and the routing module of the deployment unit is envoy. As shown in Figures 6 and 7, Figure 6 is a structural diagram of another traffic isolation system provided by the present application; Figure 7 is a flow diagram of another traffic isolation method provided by the present application. Among them, the lane state management module and istiod belong to the lane-level grayscale routing technology management plane, which is used to manage the lane and control the traffic. The pod and the envoy in the pod belong to the working plane, which is used to process the traffic.

The control plane of k8s includes the application programming interface (API) server and etcd components. The API server is a component of the k8s control plane. The API server verifies and configures the data of API objects, which include pods, microservices, etc. It provides HTTP Rest interfaces such as addition, deletion, modification, query, and monitoring (watch) of various k8s resource objects (pod, service, etc.). It is the data bus and data center of the entire system, and provides a front end for the shared state of the microservice cluster. All other components interact through this front end. etcd is a key-value database that takes into account consistency and high availability. It can be used as a background database for storing microservice cluster data. The mapping relationship between deployment units and lanes in a microservice cluster is saved in etcd.

The lane status management module is used to configure lanes for deployment units of microservices according to the lane status expected by users. It calls the interface of the k8s API server to set the lanes of the deployment units, and the API server calls etcd to save the mapping relationship between lanes and deployment units in etcd.

Istiod provides a unified and more efficient way to protect, connect and monitor service traffic. In this embodiment, Istio can push the routing policy of envoy according to the lane to which the pod corresponding to envoy belongs, and push the routing policy to each envoy when the lane status changes.

Envoy is an edge and service proxy, a sidecar of the Istio service grid, and is dynamically managed by Istiod. Envoy receives the routing policy pushed by Istiod, performs lane-level traffic routing according to the routing policy, and achieves lane-level traffic isolation.

Based on the architecture of FIG6 , the process of lane management, routing strategy generation and delivery can be seen in FIG7 .

S701: The user sends a target lane status instruction to the k8s API server.

The target lane status instructions include: the lane to be modified/created, the microservices included in the lane, and the version corresponding to each microservice in the lane. One or more of the number of deployment units corresponding to each microservice in the lane, etc.

The target lane state instruction can be carried in the form of a custom resource definition (CRD), which is a resource extension method of kubernetes. When a new CRD is created, the k8s API server generates a representational state transfer (RESTful) resource path based on the CRD. SRE can call the RESTful path of this API server to submit the target lane state instruction to the API server.

S702: The API server stores the information in the target lane status instruction in etcd of K8S.

S703: The API server sends a first notification message carrying information in the target lane status instruction to the lane status management module.

The first notification message is used to indicate the start of the grayscale release, and the first notification message also includes information in the target lane state instruction.

The API server has a list-watch mechanism. When the CRD content changes, the API server can notify the lane status management module that monitors this CRD.

S704: The lane status management module establishes a mapping relationship between the lane and the pod according to the information in the target lane status instruction.

The lane status management module adds lane labels to the pods in the microservice cluster based on the information in the target lane status instruction obtained, that is, establishes a mapping relationship between lanes and deployment units. For example, add a label of swimlane-type:gray to the pod. A label is a key-value pair attached to a pod.

S705: The lane status management module submits the mapping relationship between the lane and the pod to the API server.

S706: The API server stores the mapping relationship between lanes and pods in etcd.

S707: The API server sends a second notification message to Istiod to notify the lane change.

The second notification is used to notify Istiod of the lane status change. The second notification message carries the mapping relationship between the lane and the deployment unit. The API server sends the second notification message to Istiod through the list-watch mechanism.

S708: Istiod obtains the routing strategy of each pod according to the mapping relationship between the lanes and the pods.

The routing strategy includes routing rules and routing address sets. The addresses in the routing address set are all the addresses of the deployment units in the lanes described by the deployment units. The routing strategy can be found in the above description, which will not be repeated here.

S709: Istiod sends the corresponding routing policy to the Envoy of the deployment unit.

S710: Envoy routes traffic in the lane according to the routing policy.

Envoy routes traffic in the lane according to the routing strategy. Please refer to the description of the routing module routing call request of the deployment unit above, which will not be repeated here.

In this embodiment, the lane state management module of the management plane updates/creates the mapping relationship between the lane and the deployment unit according to the target lane state instruction issued by the user, and the control module updates the routing policy of the deployment unit according to the mapping relationship between the lane and the deployment unit, and the addresses in the routing policy are all the addresses of the deployment units in the lanes described by the deployment units. Therefore, when the deployment unit forwards the call request according to the routing policy, it can only forward the call request to other deployment units in the same lane, thereby realizing lane-level traffic isolation, without the need for traffic transparent marking, and will not cause system smooth compatibility problems caused by the grayscale implementation mode upgrade.

In order to make this solution easier to understand, the technology of this solution is explained in combination with the scenario as an example. As shown in Figure 8, in Figure 8, the microservice cluster includes a formal lane and a grayscale lane. The microservices in the formal lane and the grayscale lane include deployment units of users, shopping carts, and orders. The call link is user→shopping cart→order. Among them, the version of deployment unit 1 corresponding to the user in the formal lane is v1, the version of deployment unit 2 corresponding to the shopping cart is v1, and the version of deployment unit 3 corresponding to the order is v1. The version of deployment unit 4 corresponding to the user in the grayscale lane is v2, the version of deployment unit 5 corresponding to the shopping cart is v1, and the version of deployment unit 6 corresponding to the order is v2.

The address in the routing address set configured by deployment unit 1 is the address of deployment unit 2, and the address in the routing address set configured by deployment unit 2 is the address of deployment unit 3. The address in the routing address set configured by deployment unit 4 is the address of deployment unit 5, and the address in the routing address set configured by deployment unit 5 is the address of deployment unit 6.

When the gateway routes the access request to deployment unit 1 in the formal lane, if deployment unit 1 needs to call the microservice shopping cart, the deployment unit sends a call request to the microservice shopping cart, and the routing module of deployment unit 1 intercepts the call request. According to the microservice shopping cart that needs to be called in the call request, the address of the microservice shopping cart is obtained from the routing address set of the deployment unit, which is the address of deployment unit 2. Deployment unit 2 calls deployment unit 3 in the same way. The calling process in the grayscale lane is similar. Therefore, different lanes are isolated from each other, and cross-lane calls will not be made. The isolation of traffic between different lanes is achieved without the need for traffic to carry identifiers.

As shown in FIG. 9 , FIG. 9 is a schematic diagram of the structure of a flow isolation device provided by the present application. The flow isolation device 900 is a device in a microservice cluster. The microservice cluster includes multiple lanes. Each lane includes multiple flow isolation devices 900. Each flow isolation device 900 is In a microservice instance of a microservice, the traffic isolation device configuration 900 has a routing address set, and the addresses in the routing address set are all addresses of other traffic isolation devices 900 in the lane to which the traffic isolation device 900 belongs. The traffic isolation device 900 is used to implement the operation of the above deployment unit.

The traffic isolation device 900 includes an application function module 901 and a routing module 902. The application function module 901 is used to send a call request to a target microservice. The routing module 902 is used to route the call request to a deployment unit corresponding to the target microservice according to a routing address set.

In a possible implementation, each lane includes at least one traffic isolation device 900 corresponding to all microservices on the call link.

In a possible implementation, the routing module 902 is used to obtain a routing strategy from the control module, where the routing strategy includes a routing address set and a routing rule. The routing module 902 is specifically used to determine the target address of the deployment unit corresponding to the target microservice in the routing address set according to the routing rule. The routing module 902 is specifically used to route the call request to the deployment unit corresponding to the target microservice according to the target address.

As shown in Figure 10, Figure 10 is a schematic diagram of the structure of another flow isolation device provided by the present application. The flow isolation device 1000 includes a processor 1001 and a memory 1002, the processor 1001 is coupled to the memory 1002, and the processor 1001 is configured to execute the flow isolation method in any of the above embodiments based on the instructions stored in the memory 1002.

The present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer, implements the flow isolation method process of any of the above-mentioned method embodiments.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of the present application can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk and other media that can store program code.

Claims

A traffic isolation method, characterized in that it is applied to a microservice cluster, the microservice cluster includes multiple lanes, each of the lanes includes multiple deployment units, each of the deployment units is a microservice instance of a microservice, the deployment unit is configured with a routing address set, and the addresses in the routing address set are all addresses of other deployment units in the lane to which the deployment unit belongs, the method comprising:

The deployment unit sends a call request to the target microservice;

The routing module of the deployment unit routes the call request to the deployment unit corresponding to the target microservice according to the routing address set.
The method according to claim 1 is characterized in that each of the lanes includes at least one deployment unit corresponding to all microservices on the call link.
The method according to claim 1 or 2 is characterized in that the multiple lanes include a grayscale lane, the grayscale lane includes at least one grayscale version of a microservice, and the grayscale lane is used to implement the grayscale release of the at least one grayscale version of the microservice.
The method according to any one of claims 1 to 3, characterized in that the method further comprises:

The routing module of the deployment unit obtains a routing strategy from the control module, wherein the routing strategy includes the routing address set and the routing rule;

The routing module of the deployment unit routes the call request to the deployment unit corresponding to the target microservice according to the routing address set, including:

The routing module of the deployment unit determines the target address of the deployment unit corresponding to the target microservice in the routing address set according to the routing rule;

The routing module of the deployment unit routes the call request to the deployment unit corresponding to the target microservice according to the target address.
A traffic isolation method, characterized in that the method comprises:

The lane state management module manages multiple lanes in the microservice cluster according to the target lane state instruction, each of the lanes includes multiple deployment units, and each of the deployment units is a microservice instance of a microservice;

The control module sends a routing strategy to each deployment unit in the lane, wherein the routing strategy includes a routing address set, and the addresses in the routing address set are all addresses of deployment units in the lane to which the deployment unit belongs, so that the deployment unit calls other deployment units in the lane to which the deployment unit belongs according to the routing address set.
The method according to claim 5 is characterized in that each of the lanes includes at least one deployment unit corresponding to all microservices on the call link.
The method according to claim 5 or 6 is characterized in that the multiple lanes include a grayscale lane, the grayscale lane includes at least one grayscale version of a microservice, and the grayscale lane is used to implement the grayscale release of the at least one grayscale version of the microservice.
A traffic isolation device, characterized in that the traffic isolation device is a device in a microservice cluster, the microservice cluster includes multiple lanes, each lane includes multiple traffic isolation devices, each traffic isolation device is a microservice instance of a microservice, the traffic isolation device is configured with a routing address set, the addresses in the routing address set are all addresses of other traffic isolation devices in the lane to which the traffic isolation device belongs, and the device includes:

The calling module is used to send a calling request to the target microservice;

A routing module is used to route the call request to the deployment unit corresponding to the target microservice according to the routing address set.
The device according to claim 8 is characterized in that each of the lanes includes at least one traffic isolation device corresponding to all microservices on the call link.
The device according to claim 8 or 9 is characterized in that the multiple lanes include a grayscale lane, the grayscale lane includes at least one grayscale version of a microservice, and the grayscale lane is used to implement the grayscale release of the at least one grayscale version of the microservice.
The device according to any one of claims 9 to 10, characterized in that

The routing module is used to obtain a routing strategy from the control module, wherein the routing strategy includes the routing address set and routing rules;

The routing module is specifically used to determine the target address of the deployment unit corresponding to the target microservice in the routing address set according to the routing rule;

The routing module is specifically used to route the call request to the deployment unit corresponding to the target microservice according to the target address.
A flow isolation system, characterized in that the system comprises:

A lane state management module, used to manage multiple lanes in a microservice cluster according to a target lane state instruction, each lane including multiple deployment units, each deployment unit being a microservice instance of a microservice;

A control module, configured to issue a routing policy to each deployment unit in the lane, wherein the routing policy includes a routing address set, and the addresses in the routing address set are all addresses of deployment units in the lane to which the deployment unit belongs;

The deployment unit is used to call other deployment units in the lane to which the deployment unit belongs according to the routing address set.
The system according to claim 12 is characterized in that each of the lanes includes at least one deployment unit corresponding to all microservices on the call link.
The system according to claim 12 or 13 is characterized in that the multiple lanes include a grayscale lane, the grayscale lane includes at least one grayscale version of a microservice, and the grayscale lane is used to implement the grayscale release of the at least one grayscale version of the microservice.
A flow isolation device, characterized in that the device includes a processor and a memory, the processor is coupled to the memory, and the processor is configured to execute the flow isolation method as described in any one of claims 1 to 4, or 5 to 7 based on instructions stored in the memory.
A computer-readable storage medium, characterized in that it includes instructions, which, when the computer-readable storage medium is run on a computer, enables the computer to execute the traffic isolation method as described in any one of claims 1 to 4, or 5 to 7.