WO2022148050A1

WO2022148050A1 - Traffic management method and apparatus, traffic management strategy configuration method and apparatus, and device and medium

Info

Publication number: WO2022148050A1
Application number: PCT/CN2021/117939
Authority: WO
Inventors: 田晓亮; 薛腾飞; 郭勇良; 刘宝
Original assignee: 华为云计算技术有限公司
Priority date: 2021-01-05
Filing date: 2021-09-13
Publication date: 2022-07-14
Also published as: CN114726789A

Abstract

Provided are a traffic management method and apparatus, a device and a medium. The traffic management method comprises: a traffic management apparatus receiving an access request, for a micro service, of a user of an application, and determining an identifier of a target service scenario according to a target traffic feature included in the access request, wherein the service scenario represents an event of the user of the application using the micro-service; and then, the traffic management apparatus searching for a target traffic management strategy associated with the identifier of the target service scenario, and managing, according to a found target traffic management strategy, network traffic belonging to the target service scenario. Therefore, during the process of an application requesting a micro-service, a traffic management apparatus effectively manages generated network traffic by using a traffic management strategy corresponding to a service scenario, thereby avoiding the problem of a network traffic anomaly caused by unstable network communication.

Description

Traffic management, method, apparatus, device and medium for configuring traffic management policy

This application claims the priority of the Chinese patent application with the application number 202110008946.2 and the invention titled "Traffic Management, Method, Apparatus, Equipment and Medium for Configuring Traffic Management Policies", which was submitted to the State Intellectual Property Office of China on January 5, 2021, The entire contents of which are incorporated herein by reference.

technical field

The present application relates to the technical field of traffic management, and in particular, to a traffic management method, a method, apparatus, device and medium for configuring a traffic management policy.

Background technique

The micro service pattern refers to splitting an application into a set of cooperating services, each of which can be responsible for a specific function. For example, in the actual application, the back-end system of the mall can include product evaluation services and product description services. , commodity recommendation service and other microservices; and the services are loosely coupled (that is, the interdependence between services is low) and can be deployed independently. When a developer implements an application in the microservice mode, the requesting device (such as a client such as a browser) usually generates corresponding network traffic in the process of requesting to call the microservice in the application, such as the traffic requesting the evaluation service. In practical applications, the network communication when calling microservices remotely is usually complex and unstable. Therefore, it is necessary to effectively manage network traffic during the process of calling microservices. For example, when a remote request calls a microservice, the application may send requests to the microservice multiple times due to network congestion and other reasons. To avoid the application from repeatedly sending too many requests, you can limit the number of times the same request is sent to the microservice.

Therefore, how to effectively manage the network traffic generated in the process of requesting microservices has become an important problem that needs to be solved urgently.

SUMMARY OF THE INVENTION

In view of this, the embodiment of the present application provides a configuration method for configuring a traffic management policy, so as to reduce the learning cost for technicians when configuring the network traffic management policy, and improve the configuration efficiency. The present application also provides corresponding apparatuses, devices, computer-readable storage media, and computer program products.

In a first aspect, an embodiment of the present application provides a traffic management method, which can be applied to a corresponding traffic management device, and the traffic management device can be used to manage the traffic of microservices in the application. Specifically, the traffic The management device may receive an access request to the microservice by the user of the application, and the access request of the user of the application to the microservice may be directly or indirectly triggered by the user; The target traffic characteristics are determined, and the identifier of the target business scenario is determined, wherein the business scenario represents an event when the user of the application uses the microservice; then, the traffic management device can search for the target traffic associated with the identifier of the target business scenario. management policy, and manage the network traffic belonging to the target business scenario according to the found target traffic management policy. In this way, in the process of requesting microservices by an application, the traffic management device can effectively manage the generated network traffic by using the traffic management policy corresponding to the business scenario, so as to avoid the problem of abnormal network traffic caused by unstable network communication.

In actual application, the application may generate various events in the process of requesting a microservice, that is, there may be various business scenarios in the process of requesting a microservice, so that the network generated when the application requests a microservice may be affected. traffic, the traffic management device can find out the traffic management policy corresponding to the business scenario to which the network traffic belongs to perform traffic management.

In a possible implementation manner, before receiving the access request to the micro-service from the user of the application, the traffic management apparatus may further obtain the traffic feature corresponding to the identifier of the business scenario and the identifier of the business scenario in advance, and use the identifier of the business scenario Associate with traffic management policies. In this way, in the process of configuring traffic management policies, technicians do not need to configure according to the microservices in the business system, that is, they do not need to know the microservice architecture of the backend of the business system in advance; at the same time, not only multiple microservices may There are the same business scenarios (such as user login scenarios, etc.), so the number of business scenarios where technicians configure traffic management policies is less than the number of microservices. Moreover, it is usually difficult for technicians to configure traffic management policies from the perspective of the business domain. also lower. In this way, the learning cost of configuring the traffic management policy by the technicians can be effectively reduced, and accordingly, the efficiency of configuring the traffic management policy by the technicians can also be improved.

Optionally, the traffic management device can also store the association between the established identification of the business scenario and the traffic management strategy, so that each time the management strategy for network traffic is determined, the identification and flow of the business scenario can be obtained locally. Manage associations between policies.

In a possible implementation, the target business scenario is a scenario that exists when requesting access to multiple microservices. In this way, for the network traffic generated when an application accesses multiple microservices, the same business scenario can be used. It can be managed by traffic management policies, which can effectively reduce the number of traffic management policies that technicians need to configure, and can effectively improve configuration efficiency while reducing the number of traffic management policies configured by technicians.

In a possible implementation manner, when determining the identifier of the target service scenario, the traffic management apparatus may specifically check whether there is an identifier of the target microservice that matches the target traffic feature included in the access request, and whether there is an identifier of the target microservice that matches the target traffic feature included in the access request. The traffic management policy associated with the identifier of the service. If there is no identifier of the target microservice that matches the target traffic characteristics, or there is no traffic management policy associated with the identifier of the target microservice, it is determined that the search fails. At this time, The traffic management apparatus may determine the identifier of the target service scenario matching the target traffic feature included in the access request, so as to further determine a traffic management policy for managing network traffic based on the identifier of the target service scenario.

In a possible implementation manner, if there is an identifier of the target microservice that matches the target traffic characteristics, and there is a traffic management policy associated with the identifier of the target microservice, the traffic management apparatus can use the successfully found The traffic management policy manages the network traffic generated by the application requesting microservices. In this way, for the existing traffic management device to determine the traffic management strategy based on the microservice identifier, changes to the existing traffic management device can be reduced as much as possible, and the flexibility and universality of the solution implementation can be improved.

In a possible implementation manner, before finding out the traffic management policy associated with the identifier of the microservice, the traffic management apparatus may further associate the identifier of the microservice with the traffic management policy in advance, and store the identifier of the microservice with the traffic management policy. The association between the second traffic management policies, so that the traffic management apparatus can also determine a traffic management policy for managing network traffic according to the microservice identifier.

In a possible implementation manner, when acquiring the identifier of the business scenario and the traffic characteristics corresponding to the identifier of the business scenario, the traffic management device may specifically present a business scenario input interface to the technician, and respond to the technical staff's specific request for the business scenario For the input operation, the identifier of the input business scenario and the traffic characteristics corresponding to the identifier of the business scenario are obtained. In this way, through the visualized business scenario input interface, it is convenient for technicians to input business scenarios and traffic characteristics.

In a possible implementation manner, when the traffic management device associates the identifier of the service scenario with the traffic management policy, it may specifically present a policy configuration interface to the technician, and respond to the technician's configuration operation for the traffic management policy, Associate the identifier of the business scenario with the traffic management policy. In this way, through the visualized policy configuration interface, it is convenient for technicians to configure traffic management policies corresponding to different business scenarios.

In a second aspect, an embodiment of the present application further provides a method for configuring a traffic management policy, the method is applied to a traffic management device, and the traffic management device obtains an access request to the first microservice from a user of the application before receiving the request. The identifier of the business scenario and the traffic feature corresponding to the identifier of the business scenario, associate the acquired identifier of the business scenario with the traffic management policy, and then store the established association between the identifier of the business scenario and the traffic management policy, The traffic management policy is used to manage the network traffic belonging to the service scenario corresponding to the service scenario identifier.

In this way, in the process of configuring traffic management policies, technicians do not need to configure according to the microservices in the business system, that is, they do not need to know the microservice architecture of the backend of the business system in advance; at the same time, not only multiple microservices may There are the same business scenarios (such as user login scenarios, etc.), so the number of business scenarios where technicians configure traffic management policies is less than the number of microservices. Moreover, it is usually difficult for technicians to configure traffic management policies from the perspective of the business domain. also lower. In this way, the learning cost of configuring the traffic management policy by the technicians can be effectively reduced, and accordingly, the efficiency of configuring the traffic management policy by the technicians can also be improved.

In a third aspect, an embodiment of the present application further provides a traffic management device. The traffic management device is used to manage the traffic of microservices in an application, and the device includes a parsing module, a matching module, and a traffic management module. Among them, the parsing module is used to receive the access request of the user of the application to the micro-service; the matching module is used to determine the identifier of the target business scenario according to the target traffic characteristics included in the access request, wherein the target business scenario indicates that the user of the application uses the micro-service. An event during service; the traffic management module is used to find the target traffic management policy associated with the identifier of the target business scenario, and manage the network traffic belonging to the target business scenario according to the target traffic management policy.

In a possible implementation manner, the apparatus further includes: a policy management module, configured to obtain the identifier of the business scenario and the traffic characteristics corresponding to the identifier of the business scenario before receiving the access request for the micro-service from the user of the application, and assign the service The identifier of the scene is associated with the traffic management policy.

Optionally, the apparatus may further include a policy storage module for storing the association between the identifier of the business scenario established by the policy management module and the traffic management policy.

In a possible implementation, the target business scenario is a scenario that exists when requesting access to multiple microservices.

In a possible implementation manner, the matching module is specifically configured to: find an identifier of the target microservice that matches the target traffic feature included in the access request of the microservice and a traffic management policy associated with the identifier of the target microservice; and , when the search fails, determine the identifier of the target business scenario according to the target traffic characteristics.

In a possible implementation, the policy management module is specifically configured to: present a business scenario input interface; and in response to an input operation for the business scenario, obtain an identifier of the business scenario and a traffic feature corresponding to the identifier of the business scenario.

In a possible implementation manner, the policy management module is specifically configured to: present a policy configuration interface; and in response to a configuration operation for the traffic management policy, associate the identifier of the service scenario with the traffic management policy.

In a fourth aspect, an embodiment of the present application further provides a traffic management device, the device includes a policy management module and a policy storage module. Among them, the policy management module is specifically used to obtain the identifier of the business scenario and the traffic characteristics corresponding to the identifier of the business scenario before receiving the access request of the user of the application to the microservice, and to associate the identifier of the business scenario with the traffic management policy; the policy The storage module is specifically used to store the association between the identifier of the service scenario and the traffic management policy, wherein the traffic management policy is used to manage the network traffic belonging to the service scenario corresponding to the service scenario identifier.

In a fifth aspect, the present application provides a computing device including a processor, a memory and a display. The processor and the memory communicate with each other. The processor is configured to execute instructions stored in the memory, so that the computing device executes the traffic management method according to the first aspect or any one of the implementations of the first aspect.

In a sixth aspect, the present application provides a computing device including a processor, a memory and a display. The processor and the memory communicate with each other. The processor is configured to execute instructions stored in the memory to cause the computing device to perform the method of configuring a traffic management policy as in the second aspect or any implementation manner of the second aspect.

In a seventh aspect, the present application provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, when the computer-readable storage medium is run on a computing device, the computing device is made to perform the first aspect or any of the first aspects. A traffic management method described in an implementation manner.

In an eighth aspect, the present application provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, which, when executed on a computing device, cause the computing device to perform the second aspect or any of the second aspects. A method for configuring a traffic management policy described in an implementation manner.

In a ninth aspect, the present application provides a computer program product containing instructions, which, when run on a computing device, enables the computing device to execute the traffic management method described in the first aspect or any implementation manner of the first aspect .

In a tenth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computing device, cause the computing device to perform the configuration traffic management described in the second aspect or any implementation manner of the second aspect. method of strategy.

On the basis of the implementation manners provided by the above aspects, the present application may further combine to provide more implementation manners.

Description of drawings

In order to illustrate the technical solutions in the embodiments of the present application more clearly, the following briefly introduces the accompanying drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some implementations described in the present application. For example, for those skilled in the art, other drawings can also be obtained from these drawings.

FIG. 1 is a schematic diagram of an exemplary system architecture of the application;

Fig. 2 is a specific example schematic diagram;

FIG. 3 is a schematic diagram of an exemplary application scenario provided by an embodiment of the present application;

4 is a schematic flowchart of a method for configuring a traffic management policy according to an embodiment of the present application;

5 is a schematic diagram of an exemplary business scenario input interface provided by an embodiment of the present application;

6 is a schematic diagram of an association relationship between a service scenario identifier and a first traffic feature provided by an embodiment of the present application;

7 is a schematic diagram of a configuration file provided by an embodiment of the present application;

8 is a schematic diagram of an exemplary policy configuration interface provided by an embodiment of the present application;

FIG. 9 is a schematic diagram of another configuration file provided by an embodiment of the present application;

10 is a schematic diagram of multiplexing a first traffic feature with a second traffic feature;

FIG. 11 is a schematic flowchart of an exemplary method for managing network traffic provided by an embodiment of the present application;

FIG. 12 is a schematic diagram of an exemplary system architecture provided by an embodiment of the present application;

13 is a schematic flowchart of another exemplary method for managing network traffic provided by an embodiment of the present application;

FIG. 14 is a schematic diagram of another exemplary system architecture provided by an embodiment of the present application;

FIG. 15 is a schematic diagram of a hardware structure of a computing device according to an embodiment of the present application.

Detailed ways

The solutions in the embodiments provided in this application will be described below with reference to the accompanying drawings in this application.

The terms "first", "second" and the like in the description and claims of the present application and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged under appropriate circumstances, and this is only a distinguishing manner adopted when describing objects with the same attributes in the embodiments of the present application.

As shown in FIG. 1 , it is a schematic diagram of an exemplary system architecture. As shown in FIG. 1 , the system includes a request device 100 , a traffic management device 200 and a service execution device 300 . Wherein the requesting device 100 is, for example, a client, etc., and can request access to any one or more from the business system through the seventh layer protocol (ie the application layer, Application Layer) in the Open System Interconnection Model (OSI) kind of microservices. Wherein, the traffic management device 200 can manage the network traffic generated in the process of accessing the microservice by the requesting device 100, which can include a parsing module 201, a matching module 202, a traffic management module 203, a policy storage module 204, and a policy management module 205; The service executing apparatus 300 is configured to execute a corresponding service according to the microservice requested by the requesting apparatus 100 . The aforementioned business system can be implemented as an application, and therefore, the application includes a plurality of microservices, and each microservice implements a specific function of the application. An application can be published and used, and when a user of the application uses the application, one or more microservices in the application are run to provide corresponding responses to the user of the application. The foregoing requesting apparatus 100 requests access to any one or more microservices from the business system, which may be directly or indirectly triggered by the user of the application when the user of the application uses the application.

During specific implementation, the parsing module 201 may parse the microservice access request sent by the requesting device 100 to obtain the microservice identifier, request method, user name and other contents carried in the microservice access request. For example, the microservice access request sent by the requesting device 100 may be a HyperText Transfer Protocol (HyperText Transfer Protocol, HTTP) message as shown in FIG. 2 , and the parsing module 201 parses the HTTP message to determine the microservice to be accessed. It is "CommentService" (evaluation service), the request method is "GET", and the user name (X-User) is "Jack", wherein the parsed information can be stored in the corresponding address and the pointer is used to indicate that the information is stored the address of.

Then, the matching module 202 finds the microservice indicated by the pointer in the pre-stored list of microservices, and further finds out the microservice that requests the microservice from the microservice list according to the found microservice and other information indicated by the pointer. The category to which the network traffic belongs. For example, in the example shown in FIG. 2, the matching module 202 finds the microservice in the list of microservices according to the microservice name "CommentService" indicated by the pointer, and determines the subset according to the user name "JACK" indicated by the pointer Named "Subset A". Among them, different subset names represent different types of network traffic, and each subset name has corresponding traffic characteristics. "Subset A" in Figure 2 represents that the network traffic comes from the user "JACK", while "Subset B" represents that the network traffic comes from the Chrome browser under the Linux operating system.

Next, the traffic management module 203 can determine the traffic management policy corresponding to the subset name of the network traffic by looking up the association table between the subset name and the traffic management policy according to the category (ie the subset) to which the found network traffic belongs, and based on the determination The corresponding management unit is used to manage the network traffic generated by requesting microservices. As shown in Figure 1, the retry unit 2031 is responsible for managing the number of retries for requesting microservices from the business system, and the timeout unit 2032 is responsible for managing The timeout when requesting microservices from the business system, and the current limiting module 2033 is responsible for managing the frequency of requesting microservices from the business system, etc. Still taking FIG. 2 as an example, the traffic management module 203 may search the pre-saved association table between the subset name and the traffic management policy according to the subset name “subset A” determined by the matching module 202, thereby determining the request microarray. The network traffic generated by the service "CommentService" is configured as a timeout judgment time threshold of 10s (seconds), and the maximum number of retries for request errors is 2 times. When requesting the microservice "CommentService" from the business system, if the business When the system does not respond for 10 seconds or the number of re-initiated requests to the business system reaches 2 times and there is still a request error, the retry unit 2031 or the timeout unit 2032 controls to stop the microservice request process of the requesting device 100 this time, so as to avoid the requesting device 100 The abnormal network traffic when requesting the micro-service this time causes a series of problems such as excessive network traffic in the network between the requesting device 100 and the business system, so as to achieve effective management of the network traffic.

The list of microservices stored in the matching module 202 and the association table between the subset names and the traffic management policies stored in the traffic management module 203 may be pulled from the policy storage module 204 in advance. The association table may also be pre-established by the policy management module 205 and sent to the policy storage module 204 for storage. In practical application, the policy management module 205 can also update the association table stored in the policy storage module 204 . Of course, in other possible implementations, the association table may be configured by a technician in advance and stored in the policy storage module 204 in a unified manner.

Therefore, when implementing the management of network traffic, the matching module 202 needs to be pre-configured with a microservice identifier and a traffic feature corresponding to the microservice identifier. Otherwise, when the microservice requested by the requesting device 100 does not have a corresponding microservice identifier in the matching module 202 to match, the traffic management device 200 cannot determine the corresponding traffic management policy for the microservice requested by the requesting device 100, Therefore, the problem of abnormal network traffic due to unstable network communication is prone to occur.

However, in practical applications, the functions of the business system are usually rich, which means that the business system includes a large number of microservices. Therefore, in order to avoid abnormal network traffic when requesting microservices from the business system as much as possible, technicians need to know in advance. The microservice architecture of the backend of the business system (that is, each microservice included in the business system), and the corresponding traffic management strategy is separately configured for each microservice, which makes the learning cost of technicians high, and configures the microservices one by one Traffic management strategies are less efficient.

To this end, in the embodiment of the present application, the network traffic generated when the application requests the micro-service can be managed from the dimension of the business scenario. Among them, the business scenario refers to an event generated by the application when requesting a microservice, and the application may generate a variety of events in the process of requesting a microservice, that is, there may exist in the process of requesting a microservice A variety of different business scenarios. For example, in the process of the application requesting the microservice "CommentService", there may be an event of the user logging in to the account, the event of feeding back comment information, and the event of the user logging out of the account. business scenarios, business scenarios for feedback information, and business scenarios for user logout, etc.

Specifically, before the application requests the microservice, the association between the identifier of the business scenario and the traffic management policy may be established. In this way, in the process of requesting the microservice by the application, the traffic management device determines the The identification of the business scenario can further determine the corresponding traffic management policy, so that the network traffic generated in the process of the application requesting the micro-service can be effectively managed based on the determined traffic management policy. In the process of configuring traffic management policies in advance by technicians (such as administrators of traffic management devices, etc.), there is no need to configure according to the microservices in the business system, so that the technicians do not need to understand the microservice architecture of the backend of the business system; and, a On the one hand, multiple microservices may have the same business scenarios (such as user login scenarios, etc.), so the number of business scenarios where technicians configure traffic management policies is less than the number of microservices. It is also generally less difficult to configure traffic management policies from a business domain perspective. In this way, the learning cost of configuring the traffic management policy can be effectively reduced, and accordingly, the efficiency of configuring the traffic management policy can be improved. At the same time, in the process of invoking the micro-service by the application, the traffic management device can also effectively manage the generated network traffic by using the traffic management policy corresponding to the business scenario, so as to avoid the problem of abnormal network traffic caused by unstable network communication.

As an example, the embodiment of the present application may be applied to the application scenario shown in FIG. 3 . In this scenario, the front-end application 303 may invoke one or more microservices (not shown in FIG. 3 ). The technician 301 can call the traffic management service through a language development framework such as Java/Go or a service grid, and the traffic management service can be implemented by the above-mentioned traffic management device 200. At the same time, the technician 301 also calls the front-end or back-end application program. The interface (application programming interface, API) implements policy configuration for the network traffic generated when the front-end application 303 requests the microservice. Specifically, when calling the front-end API interface to configure and manage network traffic, the front-end application 303 can present a user interface (UI) for human-computer interaction to the technician 301, and the technician 201 can perform operations on the UI interaction interface. For the corresponding configuration and management operations, for example, the technician 301 inputs the identifier of the above-mentioned service scenario, the traffic characteristics and the traffic management policy on the UI interaction interface, and completes the corresponding configuration. Alternatively, the technician 301 may also configure the traffic management policy by calling the back-end API interface, for example, the policy configuration may be completed by means of a command line or the like.

In practical application, the above-mentioned traffic management device 200 may be deployed in the cloud as a cloud service. Then, the technician 301 calls the traffic management device 200 in the cloud through a programming language development framework or a service mesh to perform corresponding operations on network traffic. Policy configuration. Alternatively, the traffic management apparatus 200 may also be deployed locally, such as in a local server. Accordingly, the technician 301 can implement policy configuration of network traffic by invoking the traffic management apparatus 200 on the local server. Of course, in other possible implementations, different modules in the traffic management apparatus 200 may be deployed in the cloud and locally, respectively. For example, the policy storage module 204 and the policy management module 205 in the traffic management apparatus 200 may be deployed in the cloud and stored in the cloud. The cloud saves the association relationship between the traffic management policy configured by the technician 301 and the service scenario identifier; and the parsing module 201, the matching module 202 and the traffic management module 203 in the traffic management device 200 can be deployed locally, and the matching module 202 may pre-fetch the association relationship between the service scenario identifier and the traffic feature from the cloud, and the traffic management module 203 may pre-fetch the association relationship between the service scenario ID and the traffic management policy from the cloud. It should be understood that the above deployment manners are only used for exemplary description, and are not intended to be limiting, and other possible deployment manners may also be used to deploy the traffic management apparatus 200 in practical applications.

After the technician 301 completes the policy configuration through the traffic management device, the user 302 can directly or indirectly trigger the front-end application 303 to call one or more microservices. For example, the user 302 performs an operation of browsing the evaluation information of a certain product on the front-end application 303 , the front-end application 303 may request the microservice “CommentService” to obtain the product evaluation information to be presented to the user 302 . During the process that the front-end application 303 requests the micro-service, the traffic management apparatus 200 can manage the network traffic generated when the front-end application 303 requests the micro-service according to the configured traffic management policy.

Next, various non-limiting embodiments of object recognition are described in detail.

Referring to FIG. 4 , it is a schematic flowchart of a method for configuring a traffic management policy in an embodiment of the present application. This method can be applied to the traffic management apparatus 200 shown in FIG. 1, and of course, it can also be applied to a separately configured apparatus, which is not limited in this embodiment. For the convenience of description, the configuration is performed by the traffic management apparatus 200 below. The method of traffic management policy is described as an example. The method for configuring a traffic management policy shown in FIG. 4 may specifically include:

S401: The traffic management apparatus 200 acquires an identifier of a service scenario and a first traffic feature corresponding to the identifier of the service scenario, where the first traffic feature is used to describe network traffic in a service scenario corresponding to the identifier of the service scenario.

In this embodiment, a traffic management policy can be configured for network traffic from the perspective of the business domain, and different business scenarios can be distinguished by using corresponding business scenario identifiers, and the network traffic in the business scenario can be described according to the traffic characteristics of the business scenario . The business scenario refers to an event generated when a user of the application (the user 302 shown in FIG. 3 ) uses the microservice, such as the above-mentioned user login event, user logout event, and the like. In addition, when the application accesses multiple different microservices, there may be the same business scenarios. For example, when the application accesses multiple microservices such as the microservices "CommentService" and "CreateResource", there may be business scenarios in which users log in. In this way, when configuring traffic management policies based on business scenarios, only one traffic management policy can be configured for the same business scenario that appears in multiple microservices, thereby reducing the number of traffic management policies configured by technicians.

In the process of configuring the traffic management policy, the traffic management policy 200 may first obtain the service scenario identifier and the first traffic feature corresponding to the service scenario identifier, so as to configure the corresponding traffic management policy for the network traffic in the service scenario.

As an exemplary specific implementation manner, when a technician configures a corresponding traffic management policy for network traffic through a language development framework (such as a Go language development framework, a Java language development framework) or a service mesh, the language development framework or service mesh The network can call the traffic management apparatus 200, and the traffic management apparatus 200 can present a service scenario input interface to the technician, so that the technician can input the corresponding service scenario identifier and traffic characteristics on the service scenario input interface. For example, the service scenario input interface presented to the technician by the traffic management apparatus 200 may be as shown in FIG. 5 , and the technician may input a service scenario name (used as a service scenario identifier) on the service scenario input interface, and when requesting a microservice The request method, request path, user name (used as the traffic feature to describe the network traffic in this business scenario), etc. In this way, the traffic management apparatus 200 acquires the service scenario identifier and the corresponding traffic characteristics according to the input operation performed by the technician.

Among them, in FIG. 5, the business scenario name is used as the business scenario identifier as an example for illustrative illustration. "(UserActivity), "VIP UserActivity" (VIPUserActivity), etc.

In practical application, the traffic management apparatus 200 may also combine the business scenario name and other information as the business scenario identifier, for example, the business scenario name "create resource" and the specific resource object "order" or "account" ) as a business scenario identifier, at this time, creating an order and creating an account belong to different business scenarios; or, the traffic management device 200 may combine the business scenario name, the name of the network environment (such as cellular data network, WIFI network, etc.) for requesting microservices and The application name of the requesting microservice is used as the business scenario identifier. In this case, business scenarios with the same business scenario name but different application names are different business scenarios; or, the traffic management policy 200 may associate the business scenario name with user behavior, request source, and resource Any information in the operation is combined to define different types of business scenarios. In this way, more fine-grained division of business scenarios can be achieved. Of course, other information may also be used as the service scenario identifier, which is not limited in this embodiment.

In addition, the above traffic characteristics are not limited to the request method, request path and user name shown in FIG. 5, but can be any of these information, or can also be other information that can be used to describe network traffic, such as The name of the communication protocol used when requesting the micro-service, the header including which browser, mobile phone model, and any information in the operating system that the network traffic originates from, etc. The specific implementation of the traffic characteristics in this embodiment does not be limited.

In this embodiment, when acquiring the service scenario identifier and the first traffic feature, the traffic management apparatus 200 may establish an association between the service scenario identifier and the first traffic feature, so that when the network traffic requesting the microservice has the first traffic feature , the traffic management apparatus 200 may determine that the network traffic belongs to a service scenario associated with the first traffic feature. For example, the business scenario identifier input by the technician may include coarse-grained business scenario descriptions, such as "create resources" and "user activity", and the technician may further input fine-grained business scenario descriptions under the coarse-grained business scenario description. The name of the business scenario, such as "create order", "create account" and "login", and the traffic characteristics entered by the technician are the request path "/v1/order", the request path "/v1/account", And the request method is "POST/login". Then, the traffic management policy 200 may establish an association relationship as shown in FIG. 6 based on the service scenario identifier input by the technician and the first traffic feature.

In practical application, the traffic management policy 200 may specifically generate a corresponding configuration file when establishing the relationship between the service scenario identifier and the first traffic feature. For example, for the association relationship shown in FIG. 6 , the traffic management policy 200 may generate the configuration file shown in FIG. 7 . The configuration file on the left side of Figure 7 indicates the relationship between the business scenario identifier "create resource" and its corresponding traffic characteristics, and the configuration file on the right side of Figure 7 indicates the business scenario identifier "user activity" and its corresponding traffic characteristics relationship between.

S402: The traffic management apparatus 200 associates the service scenario identifier with a first traffic management policy, where the first traffic management policy is used to manage network traffic belonging to the service scenario corresponding to the service scenario identifier.

S403: The traffic management apparatus 200 stores the association between the service scenario identifier and the traffic management policy.

For network traffic in various service scenarios, the traffic management apparatus 200 can configure corresponding traffic management policies for management, so as to avoid abnormal network traffic as much as possible.

In an exemplary implementation, the traffic management apparatus 200 may present a policy configuration interface to the technician, so that the technician can configure the corresponding first traffic management policy for each service scenario on the policy configuration interface. For example, the policy configuration interface presented by the traffic management apparatus 200 may be as shown in FIG. 8 , and the technician may input the corresponding traffic management policy according to the business scenarios and traffic characteristics presented on the policy configuration interface, as shown in FIG. 8 . , the traffic management policy input by the technician for the business scenario A and the traffic feature a includes: the request timeout time is 10s, and the upper limit of the number of retries for a request error is 2 times. Then, the traffic management apparatus 200 may establish an association relationship between the first traffic management policy input by the technician and the service scenario identifier. In this way, for the network traffic in the service scenario, the first traffic management policy associated therewith can be used for traffic management. As an example, the traffic management apparatus 200 may specifically establish the association relationship between the service scenario identifier and the first traffic management policy in the form of a configuration file. For example, assuming that the service scenario identifiers are "UserActivity.login" and "create.order", and the first traffic management policy is the upper limit of the number of retries (retry) when the request is incorrect, then the association between the service identifier and the first traffic management policy The configuration file of the relationship is shown in Figure 9, that is, when the business scenario is that a user logs in or creates an order, the maximum number of error retries (MaxAttempts) of its network traffic is 3 times.

In practical application, the policy configuration interface shown in FIG. 8 can also be combined with the business scenario input interface shown in FIG. 5 into one interface, so that technicians can complete the definition of business scenarios and the corresponding business scenarios on the configuration interface at the same time. Configuration of traffic management policies. In this way, in the process of configuring the traffic management strategy, technicians can configure the traffic management strategy from the perspective of the business domain, without knowing the microservice architecture under the business system, realizing the decoupling between the configuration traffic management strategy and the microservice architecture. Thereby, the learning cost of technicians can be effectively reduced, and the configuration efficiency can be improved.

In a further possible implementation manner, the traffic management apparatus 200 may further configure a traffic management policy for the microservice. Specifically, in the process of configuring the corresponding traffic management policy according to the business scenario, the traffic management apparatus 200 may also obtain the micro-service identifier and the second traffic feature corresponding to the micro-service identifier at the same time, where the second traffic feature is used to describe the request for the The network traffic generated during the microservice, and then, the traffic management device 200 can associate the microservice identifier with the second traffic management policy, so that the traffic management device 200 can use the second traffic management policy to The network traffic of the corresponding microservice is managed.

In this way, when the requesting apparatus 100 requests a microservice, the traffic management apparatus 200 may, according to the association between the microservice identifier and the second traffic management policy, find out whether the microservice requested by the requesting apparatus 100 has the corresponding second traffic management policy , if found, the network traffic generated by requesting the micro-service can be managed directly based on the found second traffic management policy, and if not found, the device 100 can request the network traffic of the micro-service according to the traffic characteristics of the micro-service , determine the business scenario to which the network traffic belongs, and further according to the relationship between the business scenario identifier and the first traffic management strategy, find out the first traffic management strategy corresponding to the business scenario, and based on the found first traffic management strategy Policies govern this network traffic. In this way, changes to the existing traffic management device 200 can be minimized, and the flexibility and universality of solution implementation can be improved.

Since both the second traffic feature and the first traffic feature are used to describe the network traffic generated when the microservice is requested, in some embodiments, some or all of the second traffic feature associated with the microservice identifier may be the same as the first traffic feature. Traffic characteristics are the same. At this time, when the traffic management apparatus 200 establishes an association relationship between the microservice identifier and the second traffic feature, it may specifically establish an association relationship between the microservice identifier and the indication information of the second traffic feature, wherein the second traffic feature The indication information of the traffic feature is used to indicate the first traffic feature associated with the service scenario identifier. In this way, the traffic management device 200 can reuse the feature description of the first traffic feature without re-pasting the same feature description as the first traffic feature for the microservice identifier, thereby reducing the storage burden and maintenance cost of the traffic management device 200. Reduce redundant configuration. For example, assuming that the association relationship (configuration file) between the business scenario identifier (UserActivity) and the first traffic feature (Jack, that is, the user name is Jack) is shown on the left side of FIG. 10 , the traffic management apparatus 200 associates the microservice The configuration file generated when identifying ("CommentService") and the second traffic feature can be shown on the right side of Figure 10, where "refer: UserActivity.Jack" in the configuration file is used to indicate the feature description of the second traffic feature The feature descriptions that reuse the first traffic feature all refer to the user name "Jack" of the network traffic.

In the above-mentioned embodiments, the technical solutions of the embodiments of the present application are described in detail mainly from the perspective of configuring a traffic management policy by the traffic management device 200 . Below, the network will perform network processing on the microservice access request sent by the traffic management device 200 to the requesting device 100 . The specific implementation process of traffic management is exemplarily described.

As shown in FIG. 11 , it is a schematic flowchart of an exemplary method for managing network traffic. The process can be applied to the system architecture shown in FIG. 12 , and the process can specifically include:

S1101: The matching module 202 pulls the association relationship between the service scenario identifier and the first traffic feature from the policy storage module 204, and the traffic management module 203 pulls the relationship between the service scenario identifier and the first traffic management policy from the policy storage module 204 association relationship.

The two association relationships stored in the policy storage module 204 may be established by the policy management module 205 according to the input operation by the technician on the corresponding interface, and the established association relationship is stored in the policy storage module 204 . Wherein, for the specific implementation of how the policy management module 205 realizes the establishment of the association relationship between the service scenario identifier and the first traffic feature and the first traffic management policy, please refer to the description of the relevant part in the foregoing embodiment, and will not be described here. Repeat. Of course, in other examples, the above-mentioned association relationship may also be pre-established by a technician and stored in the policy storage module 204 .

It should be understood that, in other embodiments, the above step S1101 may not be executed, for example, the matching module 202 and the traffic management module 203 may pre-store the correlation between the corresponding business scenario identifiers and traffic characteristics, as well as the business scenario identifiers and traffic management. The association relationship between policies does not need to be re-pulled from the policy management module 204 every time the network traffic is managed; alternatively, the association relationship stored in the matching module 202 and the traffic management module 203 can also be pre-defined by the technical personnel Static configuration is performed without obtaining from the policy storage module 204 or the like.

S1102: The requesting apparatus 100 sends an access request for the microservice.

In this embodiment, when accessing the target microservice to the business system, the requesting device 100 may send a microservice access request, and the access request carries the target traffic characteristics representing the network traffic generated by requesting the target microservice. In practical application, The access request may also include the identifier of the target microservice. Exemplarily, the requesting apparatus 100 may send a network packet based on the HTTP protocol, where the network packet includes information such as the name of the target microservice "CommentService", the target traffic feature "POST/login" (request method).

In this embodiment, the requesting apparatus 100 may be, for example, an application that needs to call a microservice, such as a browser. The requesting apparatus 100 may generate an access request for the target microservice under the direct or indirect trigger of the user, and send it to the traffic management apparatus 200 .

S1103: The parsing module 201 parses the received access request, and stores information such as target traffic characteristics obtained by parsing, wherein the address where the information is stored is indicated by a pointer.

Exemplarily, the parsing module 201 may run a corresponding parsing model, and through the parsing model, contents such as the name of the target microservice, the target traffic feature, etc. in the data access request can be parsed. The parsing module 201 can store the information obtained by parsing in a corresponding storage area, and use a pointer to indicate a storage address where the information is stored.

S1104: The matching module 202 determines the target service scenario identifier corresponding to the target traffic feature by searching for the correlation between the service scenario identifier and the first traffic feature according to the information indicated by the pointer.

Still taking the above-mentioned target traffic feature as "POST/login" as an example, it is assumed that the relationship between the business scenario identifier and the first traffic feature may include "UserActivity" (business scenario identifier) and "POST/login" as shown in Figure 12. ” (the first traffic feature), the matching module 202 can determine the target business scenario identifier as “UserActivity” by looking up the correlation according to the target traffic feature “POST/login” indicated by the pointer.

S1105: The traffic management module 203 determines a target traffic management policy corresponding to the target service scenario identifier by searching for the association relationship between the service scenario identifier and the first traffic management policy according to the determined target service scenario identifier.

Assuming that the relationship between the service scenario identifier and the first traffic management policy may include "UserActivity" as shown in Figure 12, the timeout time is 10s, and the maximum number of retries is 2 (the first traffic management policy), then the traffic management Module 203 determines, according to the target business scenario identifier "UserActivity" determined in step S1004, that the target traffic management policy is the timeout period of 10s and the upper limit of the number of retries is 2, so as to request the requesting device 100 for microservices using the found target traffic management policy. The network traffic generated during the service is managed.

S1106: The traffic management module 203 manages the network traffic generated when the service execution apparatus 300 requests the micro-service according to the determined target traffic management policy.

For example, when the target traffic management policy is that the upper limit of the number of retries is 2, after the service execution device 300 has a request error and the number of retries reaches 2, if a request error still occurs, the traffic management module 203 controls the service execution device 300 Terminate requests for microservices from the business system. For another example, when the target traffic management policy is to limit the current to 50 times per second, the traffic management module 203 controls the service execution device 300 to request microservices from the service system within a unit time (for example, 1 second), which can be limited within 50 times, etc. .

In practical application, there may be multiple target business scenario identifiers determined by the matching module 202 according to the target traffic characteristics, such as including a coarse-grained business scenario description "CreateResource" (create resources) and a fine-grained business scenario name "CreateResource.order". ” (creating an order), correspondingly, the number of target traffic management policies determined by the traffic management module 203 for multiple business scenario identifiers of different granularities is also multiple. At this time, the traffic management module 203 is managing the network traffic. At the time, the network traffic can be managed according to the target traffic management policy corresponding to the fine-grained service scenario identifier, for example, the network traffic is managed according to the target traffic management policy corresponding to "CreateResource.order".

In this way, in this embodiment, the traffic management device 200 may determine a traffic management policy according to the business scenario described by the network traffic in the process of requesting the microservice by the requesting device 100, and use the traffic management policy to implement the traffic management policy generated by the requesting microservice. Efficient management of network traffic.

In the above-mentioned embodiment shown in FIG. 11 , the association relationship saved in the matching module 202 may only be the association relationship between the service scenario identifier and the traffic feature, while in other possible embodiments, the matching module 202 may save the service scenario at the same time. The relationship between identity and traffic characteristics, and the relationship between microservice identity and traffic characteristics. At this time, the specific implementation process of the traffic management apparatus 200 processing the microservice access request sent by the requesting apparatus 100 may be as shown in FIG. 13 , and the process may be applied to the system architecture shown in FIG. 14 . Wherein, different from the system architecture shown in FIG. 12 , in the system architecture shown in FIG. 14 , the traffic management device 200 also has an association relationship between the identification of the business scenario and the traffic management strategy, as well as the identification of the microservice and the traffic management relationship between strategies. Specifically, the process can include:

S1301: The matching module 202 pulls the association between the business scenario identifier and the first traffic feature and the association between the microservice identifier and the second traffic feature from the policy storage module 204, and the traffic management module 203 retrieves the association from the policy storage module 204. Pull the association between the business scenario identifier and the first traffic management policy and the association between the microservice identifier and the second traffic management policy.

The association relationship stored in the policy storage module 204 may be established by the policy management module 205 according to the input operation by the technician on the corresponding interface, and the established association relationship is stored in the policy storage module 204 . Wherein, as to how the policy management module 205 realizes the establishment of the association relationship between the business scenario identifier and the first traffic feature and the first traffic management policy, and the association between the microservice identifier and the second traffic feature and the second traffic management policy, respectively For the specific implementation of the relationship, reference may be made to the description of the relevant parts in the foregoing embodiments, which will not be repeated here. Moreover, in other examples, the association relationship stored in the policy storage module 204 may also be imported into the policy storage module 204 in advance by a technician, which is not limited in this embodiment.

It is worth noting that, in other embodiments, the above step S1301 may not be executed, for example, the matching module 202 and the traffic management module 203 may store the corresponding associations in advance, and there is no need to obtain them from the policy storage module 204; The association relationship stored in the module 202 and the traffic management module 203 may also be statically configured by a technician in advance, and does not need to be acquired from the policy storage module 204 or the like.

S1302: The requesting apparatus 100 sends an access request for the microservice.

S1303: The parsing module 201 parses the received access request, and stores information such as the target traffic characteristics obtained by parsing, wherein the address where the information is stored is indicated by a pointer.

S1304: The matching module 202 searches for the association relationship between the microservice identifier and the second traffic feature according to the information indicated by the pointer, and determines whether there is a target microservice identifier matching the target traffic feature.

S1305: When there is a target microservice identifier, the traffic management module 203 searches for a target traffic management policy associated with the target microservice identifier according to the association relationship between the microservice identifier and the second traffic management policy.

S1306: The traffic management module 203 manages the network traffic generated when the target microservice is requested according to the determined target traffic management policy.

S1307: When the target microservice identifier does not exist, the matching module 202 searches for the association relationship between the business scenario identifier and the first traffic feature according to the information indicated by the pointer, and determines the target business scenario identifier matching the target traffic feature.

S1308: The traffic management module 203 searches for the target traffic management policy associated with the target service scenario identifier according to the association relationship between the service scenario identifier and the first traffic management policy.

S1309: The traffic management module 203 manages the network traffic generated when the microservice is requested according to the determined target traffic management policy.

It should be noted that, for the specific implementation manner of each step in this embodiment, reference may be made to the description of the relevant part in the foregoing embodiment, which will not be repeated here.

The method for configuring a traffic management policy provided by the embodiments of the present application is described above with reference to FIGS. 1 to 14 . Next, the computing device for implementing the functions of the traffic management apparatus 200 provided by the embodiments of the present application is described with reference to the accompanying drawings.

Figure 15 provides a computing device. As shown in FIG. 15 , the computing device 1500 may be specifically configured to implement the functions of the traffic management apparatus 200 in the embodiments shown in FIGS. 2 , 11 to 15 .

Computing device 1500 includes bus 1501 , processor 1502 and memory 1503 . The processor 1502 and the memory 1503 communicate through the bus 1501 .

The bus 1501 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is shown in FIG. 15, but it does not mean that there is only one bus or one type of bus.

The processor 1502 may be a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP), etc. any one or more of the devices.

The memory 1503 may include volatile memory, such as random access memory (RAM). The memory 1503 may also include non-volatile memory (non-volatile memory), such as read-only memory (ROM), flash memory, hard drive drive (HDD) or solid state drive (solid state drive) , SSD).

Executable program code is stored in the memory 1503, and the processor 1502 executes the executable program code to execute the traffic management method and/or the method for configuring the traffic management policy performed by the aforementioned traffic management apparatus 200.

Embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium may be any available medium that a computing device can store, or a data storage device such as a data center that contains one or more available media. The usable media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid state drives), and the like. The computer-readable storage medium includes instructions, the instructions instruct the computing device to execute the traffic management method executed by the traffic management apparatus 200 described above.

The embodiments of the present application further provide another computer-readable storage medium. The computer-readable storage medium may be any available medium that a computing device can store, or a data storage device such as a data center that contains one or more available media. The usable media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid state drives), and the like. The computer-readable storage medium includes instructions, the instructions instruct the computing device to execute the method for configuring a traffic management policy performed by the traffic management apparatus 200 described above.

The embodiments of the present application also provide a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on the computing device, all or part of the processes or functions described in the embodiments of the present application are generated.

The computer instructions may be stored in or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted over a wire from a website site, computer or data center. (eg coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (eg infrared, wireless, microwave, etc.) to another website site, computer or data center.

The computer program product can be a software installation package, which can be downloaded and executed on a computing device if any one of the aforementioned object recognition methods needs to be used.

The descriptions of the processes or structures corresponding to each of the above-mentioned drawings have their own emphasis, and for the parts that are not described in detail in a certain process or structure, reference may be made to the related descriptions of other processes or structures.

Claims

A traffic management method, characterized in that, the method is applied to a traffic management device, and the traffic management device is used to manage the traffic of microservices in the application, and the method includes:

Receive an access request to the microservice from the user of the application;

Determine the identifier of the target business scenario according to the target traffic feature included in the access request, wherein the target business scenario represents an event when the user of the application uses the microservice;

Find the target traffic management policy associated with the identifier of the target business scenario;

The network traffic belonging to the target service scenario is managed according to the target traffic management policy.
The method according to claim 1, wherein, before receiving an access request for a microservice from a user of the application, the method further comprises:

Obtain the identifier of the business scenario and the traffic characteristics corresponding to the identifier of the business scenario;

Associating the identifier of the service scenario with the traffic management policy.
The method according to claim 2, wherein the target business scenario is a scenario that exists when requesting access to multiple microservices.
The method according to any one of claims 1 to 3, wherein the determining the identifier of the target service scenario according to the target traffic feature included in the access request comprises:

Find the identifier of the target microservice that matches the target traffic feature included in the access request of the microservice and the traffic management policy associated with the identifier of the target microservice;

When the search fails, the identifier of the target service scenario is determined according to the target traffic feature.
The method according to claim 2 or 3, wherein the acquiring an identifier of a business scenario and a traffic feature corresponding to the identifier of the business scenario comprises:

Present the business scenario input interface;

In response to an input operation for a business scenario, an identifier of the business scenario and a traffic feature corresponding to the identifier of the business scenario are acquired.
The method according to any one of claims 2 to 4, wherein the associating the identifier of the service scenario with the traffic management policy comprises:

Present the policy configuration interface;

In response to the configuration operation for the traffic management policy, the identification of the business scenario is associated with the traffic management policy.
A method for configuring a traffic management policy, wherein the method is applied to a traffic management device, and before receiving an access request to a microservice by a user of the application, the method includes:

Obtain the identifier of the business scenario and the traffic characteristics corresponding to the identifier of the business scenario;

associating the identifier of the business scenario with the traffic management policy;

The association between the identifier of the service scenario and the traffic management policy is stored, wherein the traffic management policy is used to manage the network traffic belonging to the service scenario corresponding to the service scenario identifier.
The method according to claim 7, wherein the target business scenario is a scenario that exists when requesting access to multiple microservices.
A traffic management device, characterized in that the traffic management device is used to manage the traffic of microservices in an application, and the device comprises:

a parsing module, configured to receive an access request to the microservice from the user of the application;

a matching module, configured to determine the identifier of the target business scenario according to the target traffic feature included in the access request, wherein the target business scenario represents an event when the user of the application uses the microservice;

A traffic management module, configured to search for a target traffic management policy associated with the identifier of the target service scenario, and manage network traffic belonging to the target service scenario according to the target traffic management policy.
The apparatus according to claim 9, wherein the apparatus further comprises:

The policy management module is used to obtain the identifier of the business scenario and the traffic characteristics corresponding to the identifier of the business scenario before receiving the access request to the micro-service from the user of the application, and associate the identifier of the business scenario with the traffic Manage policies to establish associations.
The apparatus according to claim 10, wherein the target business scenario is a scenario that exists when requesting to access multiple microservices.
The device according to any one of claims 9 to 11, wherein the matching module is specifically used for:

Find the identifier of the target microservice that matches the target traffic feature included in the access request of the microservice and the traffic management policy associated with the identifier of the target microservice;

When the search fails, the identifier of the target service scenario is determined according to the target traffic feature.
The device according to claim 10 or 11, wherein the policy management module is specifically configured to:

Present the business scenario input interface;

In response to an input operation for a business scenario, an identifier of the business scenario and a traffic feature corresponding to the identifier of the business scenario are acquired.
The device according to any one of claims 10 to 12, wherein the policy management module is specifically configured to:

Present the policy configuration interface;

In response to the configuration operation for the traffic management policy, the identification of the business scenario is associated with the traffic management policy.
A traffic management device, characterized in that the device includes a policy management module and a policy storage module, and the policy management module is used to obtain the identifier of the business scenario and the description of the The traffic characteristics corresponding to the identifiers of the business scenarios, and the identifiers of the business scenarios are associated with the traffic management policies; the policy storage module is used to store the association between the identifiers of the business scenarios and the traffic management policies, Wherein, the traffic management policy is used to manage the network traffic belonging to the service scenario corresponding to the service scenario identifier.
The apparatus according to claim 15, wherein the target business scenario is a scenario that exists when requesting access to multiple microservices.
A computing device, comprising a processor and a memory;

The processor is configured to execute instructions stored in the memory to cause the computing device to perform the method of any one of claims 1 to 6, or to perform the method of claim 7 or 8.
A computer-readable storage medium comprising instructions that, when run on a computing device, cause the computing device to perform the method of any one of claims 1 to 6, or to perform the method as claimed in claim 1 The method of 7 or 8.