Traffic distribution method, device and computer equipment suitable for gray release

Abstract

The application relates to a traffic distribution method and device suitable for gray release and a computer device, and relates to the technical field of computers. The method can be used in the field of financial technology or other related fields. The method comprises the following steps: determining a target microservice corresponding to an access request based on a business access traffic corresponding to the access request; distributing the business access traffic to a plurality of gray version services deployed in the target microservice according to a target proxy instance corresponding to the target microservice and a traffic distribution rule of the target proxy instance, so as to obtain business transit traffic output by the gray version services; and distributing the business transit traffic to a next microservice associated with the target microservice based on a business traffic transmission path corresponding to the target microservice, a proxy instance contained in the business traffic transmission path and a traffic distribution rule corresponding to the proxy instance, until the business transit traffic is distributed to a terminal microservice corresponding to the target microservice.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a traffic distribution method and device suitable for gray release, a computer device, a storage medium, and a computer program product. BACKGROUND

[0002] Currently, the main process of micro-service gray release is that request traffic enters a traffic gateway based on a context root or an HTTP domain name through a load balancing strategy from a front end, and the request traffic is controlled through a load balancing strategy when passing through a port of a micro-service, and finally the request traffic is distributed to a gray group. Since there are a large number of services in a distributed architecture, the request link will pass through multiple micro-services when the above distribution strategy is used, causing high-frequency long-time parallel development, resulting in insufficient computing resources and storage resources, thereby reducing the operating efficiency of the system. SUMMARY

[0003] Therefore, it is necessary to provide a traffic distribution method and device suitable for gray release, a computer device, a computer readable storage medium, and a computer program product, which can improve the operating efficiency of the system.

[0004] In a first aspect, the present application provides a traffic distribution method suitable for gray release. The method comprises:

[0005] Based on an access request corresponding to business access traffic, a target micro-service corresponding to the access request is determined from a plurality of micro-services included in a business system; each micro-service included in the business system is configured with a proxy instance, and each proxy instance is configured with a traffic distribution rule;

[0006] According to a target proxy instance corresponding to the target micro-service and a traffic distribution rule of the target proxy instance, the business access traffic is distributed to a plurality of gray version services deployed in the target micro-service, to obtain business transit traffic output by each gray version service;

[0007] Based on a business traffic transmission path corresponding to the target micro-service, a proxy instance of each associated micro-service included in the business traffic transmission path, and a traffic distribution rule corresponding to the proxy instance of the associated micro-service, the business transit traffic is distributed to a next micro-service associated with the target micro-service, until the business transit traffic is distributed to a terminal micro-service corresponding to the target micro-service; the terminal micro-service is used to return a processing result corresponding to the business access traffic to a terminal generating the business access traffic.

[0008] In one of the embodiments, the traffic distribution rule of the target proxy instance comprises a distribution rule for determining shunting based on user basic information of each user in the service access traffic; and the shunting of the service access traffic to the multiple gray version services of the target microservice that have been deployed comprises:

[0009] obtaining multiple user basic information contained in the service access traffic and multiple gray version services corresponding to the target microservice; the service access traffic contains multiple user access traffics, and each user access traffic corresponds to the user basic information;

[0010] if the attribute value of the user basic information matches a preset value in the traffic distribution rule of the target proxy instance, then shunting the user access traffic corresponding to the user basic information to the gray version service determined by the traffic distribution rule.

[0011] In one of the embodiments, the target proxy instance corresponding to the target microservice is configured with multiple different traffic distribution rules; and before the shunting of the service access traffic to the multiple gray version services of the target microservice that have been deployed, the method further comprises:

[0012] sorting each of the different traffic distribution rules according to a priority identifier in each of the different traffic distribution rules to determine the sorted traffic distribution rule as the traffic distribution rule of the target proxy instance.

[0013] In one of the embodiments, before the determining of the target microservice corresponding to the access request of the service access traffic from the multiple microservices contained in the business system, the method further comprises:

[0014] establishing a proxy instance corresponding to each microservice and determining a traffic distribution rule corresponding to each proxy instance;

[0015] connecting the proxy instances of each microservice based on a data interaction relationship of each microservice to obtain a service mesh corresponding to the business system;

[0016] determining a service traffic transmission path from the target microservice to an end microservice corresponding to the target microservice based on the service mesh.

[0017] In one of the embodiments, the determining of the traffic distribution rule corresponding to each proxy instance comprises:

[0018] for each proxy instance, obtaining a service identifier corresponding to the current proxy instance;

[0019] obtaining, from a rule component, a traffic distribution rule matching the service identity corresponding to the current proxy instance; the rule component is configured to manage traffic distribution rules corresponding to each proxy instance; after obtaining the user profile, the rule component verifies the user profile, and after verification, parses the traffic distribution rule corresponding to the proxy instance contained in the user profile.

[0020] In one of the embodiments, the target microservice corresponding to the access request of the business access traffic is determined from a plurality of microservices included in a business system based on the access request of the business access traffic, comprising:

[0021] parsing the access request to obtain the service identity corresponding to the business access traffic;

[0022] The service identity of a plurality of microservices included in a business system is matched with the service identity corresponding to the business access traffic respectively, to obtain the target microservice matched with the business access traffic.

[0023] In one of the embodiments, the method further comprises:

[0024] In the case of failure in determining the shunting of the business access traffic, determining the failure type of the business access traffic;

[0025] obtaining the failure recovery strategy corresponding to the failure type pre-configured by the current proxy instance; the current proxy instance is a proxy instance assigned to the business access traffic;

[0026] Based on the failure recovery strategy, the current proxy instance performs failure recovery on the business access traffic.

[0027] In a second aspect, the application further provides a traffic distribution device suitable for gray release. The device comprises:

[0028] The microservice determination module is configured to determine the target microservice corresponding to the access request of the business access traffic from a plurality of microservices included in a business system based on the access request of the business access traffic; each microservice included in the business system is configured to correspond to a proxy instance, and each proxy instance is configured to correspond to a traffic distribution rule;

[0029] The first shunting module is configured to shunt the business access traffic to a plurality of gray version services deployed in the target microservice according to the target proxy instance corresponding to the target microservice and the traffic distribution rule of the target proxy instance, to obtain the business transit traffic output by each gray version service.

[0030] The second shunting module is configured to distribute the service transit traffic to a next microservice associated with the target microservice based on a service traffic transmission path corresponding to the target microservice, proxy instances of each associated microservice included in the service traffic transmission path, and traffic distribution rules corresponding to the proxy instances of the associated microservices, until the service transit traffic is shunted to a terminal microservice corresponding to the target microservice; and the terminal microservice is configured to return a processing result corresponding to the service access traffic to a terminal generating the service access traffic.

[0031] In a third aspect, the present application also provides a computer device. The computer device comprises a memory and a processor. The memory stores a computer program. The processor implements the steps of the method in the first aspect when executing the computer program.

[0032] In a fourth aspect, the present application also provides a computer readable storage medium. The computer readable storage medium stores a computer program. The computer program is executed by a processor to implement the steps of the method in the first aspect.

[0033] In a fifth aspect, the present application also provides a computer program product. The computer program product comprises a computer program. The computer program is executed by a processor to implement the steps of the method in the first aspect.

[0034] The traffic distribution method, device, computer equipment, storage medium and computer program product suitable for gray release can determine the target microservice corresponding to the access request from the multiple microservices included in the business system through the access request corresponding to the business access traffic. The business system includes multiple deployed microservices, and each microservice can deploy multiple versions of gray version services. Each microservice in the business system corresponds to a deployed proxy instance. Based on this, the business access traffic is distributed to the multiple gray version services deployed in the target microservice through the target proxy instance corresponding to the target microservice and the traffic distribution rule corresponding to the target proxy instance, so that the target microservice processes the business access traffic and obtains the business transit traffic to be transmitted to the next service node. Then, the server can distribute the business transit traffic to the next transit microservice step by step based on the business traffic transmission path corresponding to the target microservice, the proxy instances of each associated microservice included in the business traffic transmission path, and the traffic distribution rule corresponding to each proxy instance, until the business transit traffic is distributed to the terminal microservice of the business traffic transmission path, so that the server completes the entire scheduling of the business access traffic based on the proxy instances corresponding to the multiple microservices included in the business system. The server can distribute the business access traffic to all microservices for gray release in the business system through the above method. Since there is a proxy instance and a traffic distribution rule corresponding to the proxy instance for each microservice, the server can distribute the business access traffic through the proxy instance in the scheduling process, without the participation of the microservice in the distribution process, reducing the consumption of computing resources by the microservice. In addition, the business access traffic can be pre-planned according to the distribution direction of the business traffic transmission path, further reducing the traffic received by each microservice and reducing the time of parallel development, thereby improving the operation efficiency of the business system. BRIEF DESCRIPTION OF DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the embodiments or related art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0036] Figure 1 An application environment diagram of the traffic distribution method suitable for gray release in an embodiment;

[0037] Figure 2 A flowchart of the traffic distribution method suitable for gray release in an embodiment;

[0038] Figure 3 A flowchart of the step of distributing business access traffic in an embodiment;

[0039] Figure 4 Flowchart for determining service traffic transmission path in one embodiment;

[0040] Figure 5 Flowchart for fault recovery in one embodiment;

[0041] Figure 6 Flowchart for traffic distribution method suitable for gray release in another embodiment;

[0042] Figure 7 Framework diagram for traffic distribution in one embodiment;

[0043] Figure 8 Diagram for managing agent instance communication security in one embodiment;

[0044] Figure 9 Flowchart for traffic distribution method suitable for gray release in another embodiment;

[0045] Figure 10 Structure block diagram for traffic distribution device suitable for gray release in one embodiment;

[0046] Figure 11 Internal structure diagram of computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not used to limit the present application.

[0048] The traffic distribution method suitable for gray release provided by the embodiments of the present application can be applied to, for example, Figure 1The application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The terminal 102 can initiate an access request to the server 104, and generate service access traffic corresponding to the access request. After receiving the access request in the service access traffic, the server 104 can determine the target microservice corresponding to the access request, and distribute the service access traffic through the target proxy instance corresponding to the target microservice. The target proxy instance can distribute the service access traffic through the traffic distribution rule, and process the service access traffic through the gray version service after distribution, to obtain service transit traffic. In addition, the target microservice has a preset service traffic transmission path, and the server 104 can distribute the service transit traffic to the subsequent multiple associated microservices step by step according to the service traffic transmission path, and finally distribute it to the terminal microservice corresponding to the target microservice. The data storage system can store the data required to be processed by the server 104, such as user information, credit information and other data required by the approval system. The data storage system can be integrated on the server 104, or placed on the cloud or other network servers. Among them, the terminal 102 can be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, Internet of Things devices and portable wearable devices, Internet of Things devices can be smart speakers, smart televisions, smart air conditioners, smart car devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The server 104 can be implemented by an independent server or a server cluster composed of multiple servers.

[0049] In an exemplary embodiment, as Figure 2 shown, a traffic distribution method suitable for gray release is provided, and the method is applied to Figure 1 the server 104 in the application environment as an example for illustration, including the following steps S202 to S206. Among them:

[0050] Step S202, based on the access request corresponding to the service access traffic, determining the target microservice corresponding to the access request from the multiple microservices included in the business system.

[0051] Among them, each microservice included in the business system is configured with a proxy instance, and each proxy instance is configured with a traffic distribution rule. The proxy instance is used to distribute the service access traffic to the microservices according to the respective traffic distribution rules of each microservice. The traffic distribution rule is used to determine how the service access traffic should be distributed to the multiple gray version services corresponding to the microservice. The service access traffic is the traffic generated when the terminal initiates a request to the business system. The access request is the request initiated by the terminal to access the target microservice, and the access request can include the identification information of the target microservice. The business system can be a financial product approval system and various financial systems required to be used in the financial industry, and the embodiments of the present application are not limited.

[0052] Specifically, the server can read the identification information contained in the access request. The server traverses a plurality of microservices contained in the business system and determines a target microservice matching the identification information corresponding to the access request from the plurality of microservices.

[0053] In step S204, the business access traffic is shunted to a plurality of gray version services deployed in the target microservice according to the target proxy instance corresponding to the target microservice and the traffic distribution rule of the target proxy instance, and business transit traffic output by each gray version service is obtained.

[0054] The gray version service is a plurality of version services corresponding to the target microservice. Since the microservice needs to be updated and developed, a test version is usually created to face a preset small part of terminals, and the version is opened to all terminals after verification of feasibility.

[0055] Specifically, the server calls the target proxy instance corresponding to the target microservice, and reads the preset traffic distribution rule through the target proxy instance. The server can obtain the business access traffic corresponding to the target proxy instance through the target proxy instance, and obtain the traffic information in the business access traffic. The traffic information can include user basic information. The server can divide the business access traffic according to the user basic information to obtain the business access traffic corresponding to a plurality of users. The server can determine whether the user basic information satisfies the traffic distribution rule through the target proxy instance, and if the user basic information satisfies the traffic distribution rule, the business access traffic corresponding to the user basic information is shunted to the corresponding gray version service. It should be understood that the traffic distribution rule can also be shunted according to the instantaneous traffic size of the business access traffic and the current load of each gray version service in the microservice. The above method of determining whether the business access traffic satisfies the traffic distribution rule based on the user basic information is only one feasible shunting implementation.

[0056] In one example, the target microservice corresponds to a plurality of gray version services. The target proxy instance of the target microservice can shunt the business access traffic to the plurality of gray version services according to the corresponding traffic distribution rule. The traffic distribution rule can be based on the current load of each gray version service in the microservice; or based on the user basic information contained in the business access traffic, etc.

[0057] In step S206, the business transit traffic is distributed to the next microservice associated with the target microservice based on the business traffic transmission path corresponding to the target microservice, the proxy instance of each associated microservice contained in the business traffic transmission path, and the traffic distribution rule corresponding to the proxy instance of the associated microservice, until the business transit traffic is shunted to the terminal microservice corresponding to the target microservice.

[0058] The service traffic transmission path is a traffic transmission path with the target microservice as a starting point, the associated microservice as a transfer point, and the terminal microservice as an end point, and the connection relationship between the microservices as an edge. The service traffic transmission path can be preconfigured or dynamically configured by the server according to the load of each target microservice. The target microservice, the associated microservice, and the terminal microservice can be deployed with a plurality of corresponding gray version services. The target microservice, the associated microservice, and the terminal microservice are each deployed with a corresponding proxy instance, and each proxy instance is configured with a corresponding traffic distribution rule. The associated microservice is used to receive the service transfer traffic output by the previous microservice, and to split the service transfer traffic to the gray version services corresponding to the associated microservice for processing, and finally to send the processed service transfer traffic to the next microservice. The terminal microservice is used to return the processing result corresponding to the service access traffic to the terminal generating the service access traffic.

[0059] Specifically, the server obtains the current service traffic transmission path of the target microservice, and determines the corresponding next associated microservice in the service traffic transmission path. The server sends the service transfer traffic output by the target microservice to the proxy instance corresponding to the next associated microservice, and the proxy instance corresponding to the next associated microservice splits the service transfer traffic to the plurality of gray version services corresponding to the next associated microservice according to its own traffic distribution rule, and obtains the processed service transfer traffic after processing by the gray version services. The server repeats the above process until the service transfer traffic is finally split to the last microservice in the service traffic transmission path, i.e., to the terminal microservice. The gray version service corresponding to the terminal microservice returns the final processing result to the terminal issuing the access request after processing the service transfer traffic, thereby completing the entire traffic life cycle in the business system.

[0060] In one example, the traffic distribution rules of each microservice in the business system can be the same or different. The traffic distribution rule of each microservice only acts on the microservice, and cannot be used in other microservices.

[0061] In the traffic distribution method suitable for gray release, a target microservice corresponding to an access request is determined from a plurality of microservices included in a business system by the access request corresponding to the business access traffic. The business system includes a plurality of deployed microservices, and each microservice can deploy a plurality of gray version services. Each microservice in the business system corresponds to a deployed proxy instance. Based on this, the business access traffic is distributed to a plurality of deployed gray version services in the target microservice by the target proxy instance corresponding to the target microservice and the traffic distribution rule corresponding to the target proxy instance, so that the target microservice processes the business access traffic and obtains the business transit traffic to be transmitted to the next service node. Then, the server can distribute the business transit traffic to the next transit microservice step by step based on the business traffic transmission path corresponding to the target microservice, the proxy instances of each associated microservice included in the business traffic transmission path, and the traffic distribution rule corresponding to each proxy instance, until the business transit traffic is distributed to the terminal microservice of the business traffic transmission path, so that the server completes the entire scheduling of the business access traffic based on the proxy instances corresponding to the plurality of microservices included in the business system. The server can distribute the business access traffic to all microservices in the business system for gray release by the above method. Since there is a proxy instance and a traffic distribution rule corresponding to the proxy instance for each microservice, the server can distribute the business access traffic through the proxy instance in the scheduling process, without the participation of the microservice in the distribution process, reducing the consumption of computing resources by the microservice. In addition, the business access traffic can be pre-planned according to the distribution direction of the business traffic transmission path, further reducing the traffic received by each microservice and reducing the time of parallel development, thereby improving the operation efficiency of the business system.

[0062] In an exemplary embodiment, the traffic distribution rule of the target proxy instance includes a distribution rule determined based on user basic information of each user in the business access traffic, such as Figure 3 As shown, the specific implementation process of the step "distributing the business access traffic to a plurality of deployed gray version services in the target microservice according to the target proxy instance corresponding to the target microservice and the traffic distribution rule of the target proxy instance" includes steps S302 to S304. Among them:

[0063] Step S302, obtaining a plurality of user basic information included in the business access traffic and a plurality of gray version services corresponding to the target microservice.

[0064] Among them, the business access traffic includes a plurality of user access traffic, and the user access traffic corresponds to the user basic information one by one. The user basic information can include customer code, customer name, card number, etc.

[0065] Specifically, the server reads the service access traffic, and splits the service access traffic into multiple user access traffics according to user basic information corresponding to the service access traffic. After determining the target microservice, the server determines multiple gray version services contained in the target microservice.

[0066] In step S304, if the attribute value of the user basic information matches the preset value in the traffic distribution rule of the target proxy instance, the user access traffic corresponding to the user basic information is shunted to the gray version service determined by the traffic distribution rule.

[0067] Specifically, the server reads the attribute value of the user basic information through the target proxy instance, and compares the attribute value of the user basic information with the preset value in the traffic distribution rule of the target proxy instance. If the attribute value of the user basic information meets the preset value in the traffic distribution rule, the user access traffic corresponding to the user basic information is shunted to the gray version service specified by the traffic distribution rule.

[0068] In one example, the target proxy instance contains three gray version services, i.e., a first gray version service, a second gray version service, and a third gray version service. The traffic distribution rule of the target proxy instance can be to determine whether the customer code in the user basic information is within a preset first range interval, a second range interval, and a third range interval. The first range interval corresponds to the first gray version service, the second range interval corresponds to the second gray version service, and the third range interval corresponds to the third gray version service. If the customer code corresponding to the current user access traffic is within the first range interval, the current user access traffic is shunted to the first gray version service. If the customer code corresponding to the current user access traffic is within the second range interval, the current user access traffic is shunted to the second gray version service.

[0069] In this embodiment, by matching the user basic information with the traffic distribution rule, it can be determined which gray version service the user access traffic corresponding to the user basic information should be shunted to. The shunting result can be determined from the customer side according to the actual use demand of the business system, which can improve the user experience of using the system and improve the shunting efficiency.

[0070] In one example, the target microservice corresponds to a target proxy instance configured with multiple different traffic distribution rules. Before the step of "shunting the service access traffic to the multiple gray version services deployed in the target microservice according to the target proxy instance corresponding to the target microservice and the traffic distribution rule of the target proxy instance", the method further includes:

[0071] According to the priority identifiers in the different traffic distribution rules, the different traffic distribution rules are sorted, and the sorted traffic distribution rule is determined as the traffic distribution rule of the target proxy instance.

[0072] The proxy instance corresponding to each microservice in the business system can include multiple traffic distribution rules. Each traffic distribution rule has different conditions.

[0073] Specifically, the server can set a priority for each traffic distribution rule in the target proxy instance, and determine the priority of each traffic distribution rule through a priority identifier. Based on this, the target proxy instance can sort the multiple traffic distribution rules according to the priority, and use the sorted traffic distribution rules as the traffic distribution rules corresponding to the target proxy instance. When the target proxy instance receives business access traffic, it can distribute the business access traffic according to the sorted traffic distribution rules. If the traffic distribution rules with higher priority cannot distribute the business access traffic, the next traffic distribution rule is used to distribute the business access traffic in order of sorting, until all business access traffic is distributed.

[0074] In one example, the target proxy instance includes a first traffic distribution rule and a second traffic distribution rule, the priority of the first traffic distribution rule is higher than that of the second traffic distribution rule, for example, the priority of the first traffic distribution rule is 10, and the priority of the second traffic distribution rule is 5. The first traffic distribution rule is to distribute the traffic of the intranet terminal to multiple gray version services according to the weight, and the second traffic distribution rule is to determine the distribution weight of each gray version service according to the current load of the gray version service, so as to distribute all traffic. Based on this, if the business access traffic is initiated by an extranet terminal, the first traffic distribution rule cannot distribute the business access traffic, and the target proxy instance calls the second traffic distribution rule to distribute the business access traffic.

[0075] In this embodiment, by prioritizing the multiple traffic distribution rules in the target proxy instance, a distribution strategy close to the business demand can be obtained, and the user access traffic can be distributed according to the distribution strategy, thereby improving the running stability of the business system.

[0076] In one example, as shown in FIG. 4, the method further includes steps S402 to S406 before the step of "determining the target microservice corresponding to the access request from the multiple microservices included in the business system based on the access request corresponding to the business access traffic". Figure 4

[0077] Step S402, establishing a proxy instance corresponding to each microservice, and determining the traffic distribution rules corresponding to each proxy instance.

[0078] ​Specifically, the server can employ a shunting framework as a driving framework for shunting of the microservices. The shunting framework can include a proxy management module and a rule management module. The server creates proxy instances corresponding to the microservices in the business system through the proxy management module, and configures a corresponding traffic distribution rule for each proxy instance through the rule management module.

[0079] At step S404, the proxy instances of the microservices are connected based on the data interaction relationship of the microservices, to obtain a service mesh corresponding to the business system.

[0080] The data interaction relationship can be determined based on a data interaction process generated in a running process of the microservices in the business system. The service mesh includes the proxy instances of the microservices and the data interaction relationship between the proxy instances. The service mesh can be established through the proxy management module.

[0081] Specifically, the server determines the connection relationship between the microservices based on the data flow between the microservices in the business system. The server applies the connection relationship between the microservices to the proxy instances corresponding to the microservices respectively, to obtain a service mesh corresponding to the business system.

[0082] In an example, the proxy management module can include a service authentication function, and perform identity authentication between the microservices respectively, and establish a communication connection between the microservices that pass the identity authentication. The proxy management module can also perform access control between the microservices, to control which microservices can communicate with other microservices, thereby realizing fine-grained access control.

[0083] At step S406, a business traffic transmission path between the target microservice and a terminal microservice corresponding to the target microservice is determined based on the service mesh.

[0084] Specifically, the server can determine the business traffic transmission path between the target microservice and the terminal microservice corresponding to the target microservice through a preset path calculation strategy. Since the service mesh includes multiple microservices, and there can be a connection relationship between the microservices, the business traffic transmission path can be multiple. The proxy management module can determine which path is the optimal business traffic transmission path according to the current load of each microservice in each business traffic transmission path.

[0085] In this embodiment, the proxy instances of the microservices are connected through the data interaction relationship of the microservices, to obtain a service mesh corresponding to the business system, so that the business traffic transmission path between the target microservice and the terminal microservice corresponding to the target microservice is determined through the service mesh, the optimal shunting path can be obtained, and the shunting efficiency of the business access traffic of the business system is improved, and the running stability of the business system is improved.

[0086] In an example embodiment, the specific implementation process of the step of "determining the traffic distribution rule corresponding to each agent instance" includes:

[0087] For each agent instance, obtaining the service identifier corresponding to the current agent instance; obtaining the traffic distribution rule matching the service identifier corresponding to the current agent instance from the rule component.

[0088] The rule component is used to manage the traffic distribution rules corresponding to each agent instance. After obtaining the user configuration file, the rule component verifies the user configuration file and parses the traffic distribution rules corresponding to the agent instances contained in the user configuration file after passing the verification. In an example, the rule component can be a rule management module in the distribution framework.

[0089] Specifically, the server can receive the user configuration file uploaded by the user. The server can verify the user configuration file through the rule management module, and store the user configuration file that passes the verification in the rule management module. The rule management module can parse the traffic distribution rules corresponding to the agent instances from the user configuration file. One user configuration file can contain the traffic distribution rules of at least one agent instance. The server can traverse each agent instance and obtain the service identifier, such as a unique identifier, corresponding to the current agent instance. The server retrieves the traffic distribution rule matching the service identifier of the current agent instance in the rule management module.

[0090] In this embodiment, the rule component is used to uniformly manage the traffic distribution rules of each agent instance. The server can also update the traffic distribution rules of each agent instance through the user configuration file, thereby improving the management efficiency of the traffic distribution rules of each agent instance.

[0091] In an example embodiment, the specific implementation process of the step of "determining the target microservice corresponding to the access request based on the service identifier corresponding to the business access traffic" includes:

[0092] Parsing the access request to obtain the service identifier corresponding to the business access traffic; matching the service identifiers of the plurality of microservices included in the business system with the service identifier corresponding to the business access traffic, respectively, to obtain the target microservice matching the business access traffic.

[0093] The service identifier is used to determine the microservice requested by the access request.

[0094] Specifically, the server can parse the access request to obtain the service identifier contained in the access request. The server can match the service identifiers of the plurality of microservices to determine that the microservice matching the service identifier corresponding to the access request is the target microservice.

[0095] In one example, the server includes microservice 1, microservice 2 and microservice 3, which correspond to service identifiers 001, 002 and 003 respectively. If the access request corresponds to the service identifier 003, it is determined that the business access traffic corresponding to the access request will be transmitted to the microservice 3. The proxy instance of the microservice 3 will shunt the business access traffic.

[0096] In this embodiment, the service identifier can be used to determine the target microservice required by the access request in the plurality of microservices in the business system, and the efficiency of determining the target microservice can be improved.

[0097] In one example, as shown in Figure 5 The method further includes steps S502 to S506. Wherein:

[0098] Step S502, in the case where the shunting of the business access traffic fails, determining the fault type of the business access traffic.

[0099] Wherein, the shunting of the business access traffic may fail due to a fault, and the fault type can include network interruption, network delay and data loss, etc.

[0100] Specifically, if the server detects that the business access traffic cannot be shunted through the proxy instance, the network state corresponding to the business access traffic, the data transmission record are determined by obtaining the log record of the shunting, and the fault type of the business access traffic is determined by the network state and the data transmission record.

[0101] Step S504, obtaining the fault recovery strategy corresponding to the fault type pre-configured by the current proxy instance.

[0102] Wherein, the current proxy instance is the proxy instance to which the business access traffic is allocated. The fault recovery strategy is pre-configured by the server.

[0103] Specifically, the server can obtain a plurality of fault recovery strategies pre-configured by the current proxy instance through the proxy management module, and determine the required fault recovery strategy according to the fault type corresponding to each fault recovery strategy and the fault type of the business access traffic.

[0104] Step S506, performing fault recovery on the business access traffic through the current proxy instance based on the fault recovery strategy.

[0105] Specifically, according to the fault type, the corresponding fault recovery strategy is selected, and the fault recovery is performed on the microservice corresponding to the current proxy instance or the business access traffic that has failed. The fault recovery strategy can include timeout, retry and fuse, etc.

[0106] In this embodiment, the fault recovery strategy can be used to recover the fault of the service access traffic, so as to ensure that the service access traffic can be correctly distributed, and the operation safety of the service system is improved.

[0107] As shown in the following, the specific execution process of the traffic distribution method suitable for gray release is described in detail in combination with one specific embodiment. Figure 6

[0108] The server first accesses the credit card access traffic, and controls the access traffic through the Istio micro-service plane. Generally, each micro-service includes multiple service environments, such as the service environment of pod1 and the service environment of pod2 in Figure 6 . The Istio micro-service plane distributes the credit card access traffic to different service environments through a distribution rule. Each micro-service needs to be authenticated by Citadel and establish a communication connection and communication authority between micro-services. In addition, the server also needs to verify the traffic distribution rule through Galley, and configure the verified traffic distribution rule to the proxy instance corresponding to each micro-service, which can be represented by Envoy.

[0109] The server can use the distribution framework Istio as the driving framework for micro-service distribution. The Istio framework can include two components, Pilot and Envoy.

[0110] Pilot is responsible for service discovery, load balancing and traffic management. Specifically, it manages and configures all Envoy proxy instances deployed in a specific Istio service mesh. Pilot can determine the routing traffic rules used between Envoy proxies and configure the corresponding fault recovery function of the traffic. For example, fault recovery of traffic through timeout, retry and fuse. The Envoy proxy instances managed by Pilot can all store load balancing information, so that the proxies can intelligently distribute traffic based on inter-instance routing rules.

[0111] As shown in the following, the process of gray release distribution of the credit card approval system can be explained by the istiod plane control (control plane) and Envoy proxy dynamic (data plane) of the present application. Figure 7

[0112] I. istiod plane control:

[0113] (1) Pilot service management

[0114] ​​The traffic routing rules of Istio can be configured according to multiple service versions corresponding to each microservice, and the configuration management in the control plane can be used to configure each traffic routing rule. Each proxy instance can contain multiple service versions, and the services can be further subdivided by different service versions (such as v1, v2) to enable traffic to be distributed to different service versions. Since the large data customer base of credit cards is built on different servers, the servers can deploy different versions of the same microservice in different environments to achieve the purpose of primary and backup separation. Different versions of services can be the same API version, that is, services can be different iterations of the same service deployed in different environments. The traffic routing rules of Istio can control the traffic between services according to the service versions.

[0115] (II) Citadel certificate server control

[0116] As shown in Figure 8 , the Envoy proxy instance dynamically obtains the certificate private key through service configuration, thereby ensuring the security of the microservice. Citadel can listen to the certificate and private key to monitor the microservice. The server can design the credit card user traffic to be processed by the istio-agent security component under the Envoy proxy rule, create a private key and certificate signature, and send a certificate and secret key request to the control plane proxy, thereby connecting to the istiod control platform. After successful identification of the microservice, the control plane proxy verifies and generates a certificate, thereby authorizing the certificate, and returns the authorized certificate to the security component, thereby achieving the implementation of key and certificate rotation in the process cycle.

[0117] (III) Galley configuration verification

[0118] The credit card cluster is large, and the server service scalability and portability are guaranteed. The server verifies, injects, processes, and distributes the traffic distribution rules through Gallery, and based on the Istio architecture, the server captures and forwards traffic through the Envoy proxy. However, there are differences between the traffic distribution rules of different Envoy configurations. The server can modify the traffic distribution rules without changing the deployed application code, thereby achieving the purpose of traffic distribution rule management.

[0119] II. Envoy proxy dynamic

[0120] Communication between servers is accessed through hostnames or IP addresses. Envoy proxy instances can intercept and forward all requests and responses between clients and servers. Servers use the traffic distribution rules specified by Pilot, and Envoy proxy instances dynamically determine the shunted canary services according to the traffic distribution rules. Traffic distribution rules can enable Envoy proxy instances to select canary services according to standards such as headers, labels associated with sources / destinations, and / or weights assigned to each version.

[0121] (I) Build a service framework instance

[0122] (1) Build an Istio shunting framework and bookinfo test program, and perform traffic shunting through canary services V1 and V2, and demonstrate through Envoy service proxy.

[0123] (2) First, deploy the V1 version of the Bookinfo application. Confirm that the pod1 node is deployed.

[0124] (3) Second, deploy the V2 version of the reviews service. Determine that the pod2 node is deployed. Before deploying the V2 version of the reviews service, a default routing rule needs to be created to direct all production traffic to the V1 version to avoid affecting online users.

[0125] (II) Configure service proxy settings traffic rule strategy.

[0126] Because the user traffic shunting features required by different services and groups in the credit card business are different, some services need to be differentiated through browser addresses, some through user three elements (customer code, customer name, card number), and some services through domain names. Therefore, weight allocation, request header head splitting, browser address, and user source can be used for splitting. As shown in Table 1, weight allocation is used as an example: Figure 9

[0127] Traffic can include access requests from three types of users: operation and maintenance, users, and tests. The proxy instance of microservice 1 can use a weight shunting strategy to shunt 50% of the traffic to the V1 version of microservice 2 and 50% of the traffic to the V2 version of microservice 2.

[0128] ​In addition, when there are multiple traffic distribution rules received by a proxy instance, the traffic distribution rules are applied according to the priorities and orders corresponding to the configuration of the traffic distribution rules, and when the traffic distribution of a microservice is completely based on weights, it can be completed in a single rule. The routing of multiple conditions (for example, requests from a specific user) must consider the priority problem, and the priority is required to ensure that the rules are executed in the correct order. A common routing mode is to provide one or more high-priority rules, which use source services and headers for traffic distribution, and then provide a separate weight-based traffic distribution rule. The low-priority rule does not set the matching rule of the user or the header, and only shunts all the remaining traffic according to the weight.

[0129] Therefore, based on the Istio microservice mesh data plane (Envoy proxy) and the control plane (Pilot), the server can split the business access traffic by deploying different release service strategies.

[0130] The embodiments of the present application can realize the traffic and call control between services by centrally configuring traffic rules, dynamically plugging, and extensible strategy, and further realize the management functions such as load balancing, fusing, fault injection, retry, and redirection, combine the logical gray control and the microservice release together, solve the deployment problem in the physical gray release service, and the multiple strategy configuration and strategy problem in the logical gray release strategy, and better realize the security and convenience of the gray release technology in application security and service security.

[0131] It should be understood that, although each step in the flowchart involved in each of the above embodiments is displayed in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other sequences. Moreover, at least part of the steps in the flowchart involved in each of the above embodiments can include multiple steps or stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of these steps or stages is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or steps or stages in other steps.

[0132] Based on the same inventive concept, the embodiments of the present application also provide a traffic distribution device for gray release for implementing the traffic distribution method for gray release involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more traffic distribution device embodiments for gray release provided below can refer to the limitations of the traffic distribution method for gray release in the above text, and will not be repeated here.

[0133] In one exemplary embodiment, as shown in Figure 10 A traffic distribution device 1000 suitable for gray release is provided, comprising a microservice determination module 1001, a first shunting module 1002 and a second shunting module 1003, wherein:

[0134] The microservice determination module 1001 is configured to determine a target microservice corresponding to an access request of the business access traffic from a plurality of microservices included in a business system.

[0135] The first shunting module 1002 is configured to shunt the business access traffic to a plurality of gray release version services deployed in the target microservice according to a target proxy instance corresponding to the target microservice and a traffic distribution rule of the target proxy instance, and obtain business transit traffic output by each gray release version service.

[0136] The second shunting module 1003 is configured to distribute the business transit traffic to a next microservice associated with the target microservice based on a business traffic transmission path corresponding to the target microservice, proxy instances of each associated microservice included in the business traffic transmission path, and a traffic distribution rule corresponding to the proxy instances of the associated microservice, until the business transit traffic is shunted to a terminal microservice corresponding to the target microservice.

[0137] Further, the traffic distribution rule of the target proxy instance includes an allocation rule determined based on user basic information of each user in the business access traffic, and the first shunting module 1002 is specifically configured to: obtain a plurality of user basic information included in the business access traffic and a plurality of gray release version services corresponding to the target microservice; the business access traffic includes a plurality of user access traffics, and each user access traffic corresponds to user basic information; if an attribute value of the user basic information matches a preset value in the traffic distribution rule of the target proxy instance, the user access traffic corresponding to the user basic information is shunted to the gray release version service determined by the traffic distribution rule.

[0138] Further, the target proxy instance corresponding to the target microservice is configured with a plurality of different traffic distribution rules, and the device further comprises a rule determination module, which is specifically configured to: sort the different traffic distribution rules according to priority identifiers in the different traffic distribution rules, and determine the sorted traffic distribution rule as the traffic distribution rule of the target proxy instance.

[0139] Further, the apparatus further comprises a transmission path determination module, specifically configured to: establish proxy instances corresponding to each microservice, and determine traffic distribution rules corresponding to each proxy instance; connect the proxy instances of each microservice based on the data interaction relationship of each microservice to obtain a service mesh corresponding to the business system; and determine a business traffic transmission path of the target microservice to a target microservice corresponding end microservice based on the service mesh.

[0140] Further, the transmission path determination module is specifically further configured to: for each proxy instance, obtain a service identifier corresponding to the current proxy instance; and obtain, from a rule component, a traffic distribution rule matching the service identifier corresponding to the current proxy instance; the rule component is configured to manage the traffic distribution rules corresponding to each proxy instance; and the rule component, after obtaining a user configuration file, verifies the user configuration file, and after passing the verification, parses the traffic distribution rules corresponding to the proxy instances contained in the user configuration file.

[0141] Further, the microservice determination module 1001 is specifically configured to: parse the access request to obtain a service identifier corresponding to the business access traffic; and match the service identifiers of the plurality of microservices included in the business system with the service identifier corresponding to the business access traffic respectively to obtain target microservices matching the business access traffic.

[0142] Further, the apparatus further comprises a fault recovery module, specifically configured to: in the case that a fault occurs when determining to split the business access traffic, determine a fault type of the business access traffic; obtain a fault recovery strategy corresponding to the fault type pre-configured by a current proxy instance; the current proxy instance is a proxy instance to which the business access traffic is distributed; and perform fault recovery on the business access traffic by the current proxy instance based on the fault recovery strategy.

[0143] The above-mentioned various modules of the traffic distribution apparatus suitable for gray release can be all or part realized by software, hardware and combinations thereof. The above-mentioned various modules can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a memory in a computer device in software form, so as to be called and executed by a processor to perform the operations corresponding to the above-mentioned various modules.

[0144] In one exemplary embodiment, a computer device, which can be a server, is provided, and an internal structure diagram of the computer device can be as shown in Figure 11As shown in the figure. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through the system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capability. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store the data required to be processed in the business system. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with the terminal outside through the network connection. The computer program is executed by the processor to realize a traffic allocation method suitable for gray release.

[0145] Those skilled in the art can understand that, Figure 11 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0146] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to realize the steps in each of the above method embodiments.

[0147] In one embodiment, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by the processor to realize the steps in each of the above method embodiments.

[0148] In one embodiment, a computer program product is provided, including a computer program, and the computer program is executed by the processor to realize the steps in each of the above method embodiments.

[0149] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0150] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0151] Any combination of the technical features of the above embodiments can be made. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, however, as long as the combination of the technical features does not exist, it should be considered as the scope of the present application.

[0152] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent of the present application. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of protection of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A traffic allocation method suitable for canary releases, characterized in that, The method includes: Based on the access requests corresponding to the business access traffic, the target microservice corresponding to the access request is determined from multiple microservices included in the business system; each of the microservices included in the business system is configured with a proxy instance, and traffic allocation rules are configured for each proxy instance. Based on the target proxy instance corresponding to the target microservice and the traffic allocation rules of the target proxy instance, the business access traffic is diverted to multiple canary version services deployed in the target microservice, and the business relay traffic output by each canary version service is obtained. Based on the business traffic transmission path corresponding to the target microservice, the proxy instances of each associated microservice included in the business traffic transmission path, and the traffic allocation rules corresponding to the proxy instances of the associated microservices, the business transit traffic is allocated to the next microservice associated with the target microservice until the business transit traffic is diverted to the endpoint microservice corresponding to the target microservice; the endpoint microservice is used to return the processing result corresponding to the business access traffic to the terminal that generated the business access traffic.

2. The method according to claim 1, characterized in that, The traffic allocation rules for the target proxy instance include determining the allocation rules for traffic distribution based on the basic user information of each user in the business access traffic; the step of distributing the business access traffic to multiple gray-scale version services deployed in the target microservice according to the target proxy instance corresponding to the target microservice and the traffic allocation rules of the target proxy instance includes: Obtain multiple basic user information contained in the business access traffic, as well as multiple gray-scale version services corresponding to the target microservice; the business access traffic contains multiple user access traffic, and the user access traffic corresponds one-to-one with the user basic information; If the attribute value of the user's basic information matches the preset value in the traffic allocation rule of the target proxy instance, then the user access traffic corresponding to the user's basic information will be diverted to the gray-scale version service determined by the traffic allocation rule.

3. The method according to claim 1, characterized in that, The target proxy instance corresponding to the target microservice is configured with multiple different traffic allocation rules; before diverting the business access traffic to the multiple canary version services deployed in the target microservice according to the target proxy instance corresponding to the target microservice and the traffic allocation rules of the target proxy instance, the method further includes: Based on the priority identifiers in each of the different traffic allocation rules, the different traffic allocation rules are sorted, and the sorted traffic allocation rules are determined as the traffic allocation rules for the target proxy instance.

4. The method according to claim 1, characterized in that, Before determining the target microservice corresponding to the access request from multiple microservices included in the business system based on the access request corresponding to the business access traffic, the process further includes: Establish proxy instances for each microservice and determine the traffic allocation rules for each proxy instance; Based on the data interaction relationship of each microservice, the proxy instances of each microservice are connected to obtain the service mesh corresponding to the business system. Based on the service mesh, the business traffic transmission path from the target microservice to the corresponding endpoint microservice is determined.

5. The method according to claim 4, characterized in that, The determination of the traffic allocation rules corresponding to each of the proxy instances includes: For each of the aforementioned proxy instances, obtain the service identifier corresponding to the current proxy instance; The rule component obtains a traffic allocation rule that matches the service identifier corresponding to the current proxy instance from the rule component; the rule component manages the traffic allocation rules corresponding to each proxy instance; after obtaining the user configuration file, the rule component verifies the user configuration file and, after passing the verification, parses the traffic allocation rule corresponding to the proxy instance contained in the user configuration file.

6. The method according to claim 1, characterized in that, The step of determining the target microservice corresponding to the access request from multiple microservices included in the business system based on the access request corresponding to the business access traffic includes: Parse the access request to obtain the service identifier corresponding to the service access traffic; The service identifiers of multiple microservices included in the business system are matched with the service identifiers corresponding to the business access traffic to obtain the target microservice that matches the business access traffic.

7. The method according to claim 1, characterized in that, The method further includes: If a failure occurs during the traffic splitting of the service access traffic, determine the type of failure of the service access traffic. Obtain the fault recovery strategy pre-configured for the current proxy instance corresponding to the fault type; the current proxy instance is the proxy instance that allocates the service access traffic; Based on the fault recovery strategy, the service access traffic is recovered through the current proxy instance.

8. A flow distribution device suitable for grayscale publishing, characterized in that, The device includes: The microservice determination module is used to determine the target microservice corresponding to the access request from multiple microservices included in the business system based on the access request corresponding to the business access traffic; each of the microservices included in the business system is configured with a proxy instance, and traffic allocation rules are configured for each proxy instance. The first traffic splitting module is used to split the business access traffic to multiple gray-scale version services deployed in the target microservice according to the target proxy instance corresponding to the target microservice and the traffic distribution rules of the target proxy instance, so as to obtain the business relay traffic output by each gray-scale version service. The second traffic distribution module is used to distribute the transit traffic to the next microservice associated with the target microservice based on the business traffic transmission path corresponding to the target microservice, the proxy instances of each associated microservice included in the business traffic transmission path, and the traffic distribution rules corresponding to the proxy instances of the associated microservices, until the transit traffic is distributed to the endpoint microservice corresponding to the target microservice; the endpoint microservice is used to return the processing result corresponding to the business access traffic to the terminal that generated the business access traffic.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images