CN114726789A

CN114726789A - Method, device, equipment and medium for traffic management and traffic management policy configuration

Info

Publication number: CN114726789A
Application number: CN202110008946.2A
Authority: CN
Inventors: 田晓亮; 薛腾飞; 郭勇良; 刘宝
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2021-01-05
Filing date: 2021-01-05
Publication date: 2022-07-08
Also published as: WO2022148050A1

Abstract

The application provides a method, a device, equipment and a medium for flow management, wherein the flow management device receives an access request of an application user to a micro service, and determines an identifier of a target service scene according to a target flow characteristic included in the access request, wherein the service scene represents an event when the application user uses the micro service; then, the traffic management device searches for a target traffic management policy associated with the identifier of the target service scenario, and manages the network traffic belonging to the target service scenario according to the searched target traffic management policy. In this way, in the process of requesting the micro-service by the application, the traffic management device effectively manages the generated network traffic by using the traffic management policy corresponding to the service scene, so as to avoid the problem of abnormal network traffic caused by unstable network communication.

Description

Method, device, equipment and medium for traffic management and traffic management policy configuration

Technical Field

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

Background

Micro service pattern (micro service pattern) refers to splitting an application into a set of services cooperating with each other, and each service may be responsible for a specific function, such as: in practical application, the shopping mall background system can comprise a plurality of micro services such as commodity evaluation service, commodity description service, commodity recommendation service and the like; and, the services are loosely coupled (i.e. the degree of interdependence between the services is low) and can be deployed independently. When a developer implements an application in a micro service mode, a requesting device (e.g., a client such as a browser) usually generates corresponding network traffic, such as traffic requesting an evaluation service, in a process of requesting to invoke a micro service in the application. In practical applications, network communication when the micro-service is invoked remotely is often complex and unstable, and therefore, the network traffic needs to be managed effectively during the invocation of the micro-service. For example, when the remote request invokes the micro service, the application may send the request to the micro service multiple times due to network congestion or the like, and in order to avoid too many requests repeatedly sent by the application, the number of times of sending the same request to the micro service may be limited.

Therefore, how to effectively manage the network traffic generated in the process of requesting the micro-service becomes an important problem to be solved urgently.

Disclosure of Invention

In view of this, the embodiments of the present application provide a configuration method for configuring a traffic management policy, so as to reduce the learning cost for technicians when configuring a network traffic management policy and improve the configuration efficiency. Corresponding apparatus, devices, computer-readable storage media, and computer program products are also provided.

In a first aspect, an embodiment of the present application provides a traffic management method, which may be applied to a corresponding traffic management device, where the traffic management device may be configured to manage traffic of a micro service in an application, and specifically, the traffic management device may receive an access request of an application user to the micro service, where the access request of the application user to the micro service may be generated by direct or indirect triggering of the user; then, the traffic management device may determine, according to a target traffic feature included in the received access request, an identifier of a target service scenario, where the service scenario represents an event when a user of the application uses the microservice; then, the traffic management device may search for a target traffic management policy associated with the identifier of the target service scenario, and manage the network traffic belonging to the target service scenario according to the searched target traffic management policy. In this way, in the process of requesting the micro service by the application, the traffic management device can effectively manage the generated network traffic by using the traffic management policy corresponding to the service scene, so that the problem of network traffic abnormality caused by unstable network communication can be avoided.

In practical application, various events may be generated in the process of requesting one micro service, that is, various different service scenarios may exist in the process of requesting one micro service, so that for network traffic generated when the application requests the micro service, the traffic management device may find out a traffic management policy corresponding to the service scenario to which the network traffic belongs to perform traffic management.

In a possible implementation manner, before receiving an access request of an application user to a micro service, the traffic management device may further obtain traffic characteristics corresponding to the identifier of the service scenario and the identifier of the service scenario in advance, and associate the identifier of the service scenario with the traffic management policy. Therefore, in the process of configuring the flow management strategy, a technician does not need to configure according to the micro-service in the service system, namely, the technician does not need to know the micro-service architecture at the rear end of the service system in advance; meanwhile, not only may multiple microservices have the same service scenario (for example, all have user login scenario, etc.), so that the number of service scenarios for the technician to configure the traffic management policy is smaller than that of microservices, but also the difficulty for the technician to configure the traffic management policy from the view point of the service field is generally lower. Therefore, the learning cost of the technical personnel for configuring the flow management strategy can be effectively reduced, and correspondingly, the efficiency of the technical personnel for configuring the flow management strategy can be improved.

Optionally, the traffic management device may further store the association between the identifier of the established service scenario and the traffic management policy, so that the association between the identifier of the service scenario and the traffic management policy may be obtained locally each time the management policy for the network traffic is determined.

In a possible implementation manner, the target service scenario is a scenario existing when multiple microservices are requested to be accessed, and thus, for network traffic generated when multiple microservices are accessed by an application, the network traffic can be managed by using traffic management policies corresponding to the same service scenario, so that the number of traffic management policies required to be configured by a technician can be effectively reduced, the configuration efficiency can be effectively improved while the configuration of the traffic management policies by the technician is reduced.

In a possible implementation manner, when determining the identifier of the target service scenario, the traffic management device may specifically search whether there is an identifier of the target micro service matching the target traffic feature included in the access request and a traffic management policy associated with the identifier of the target micro service, and if there is no identifier of the target micro service matching the target traffic feature or there is no traffic management policy associated with the identifier of the target micro service, the traffic management device determines that the search fails, and at this time, the traffic management device may determine the identifier of the target service scenario matching the target traffic feature according to the target traffic feature included in the access request, so as to further determine the traffic management policy for managing network traffic based on the identifier of the target service scenario.

In one possible implementation, if there is an identifier of the target micro service matching the target traffic characteristic and there is a traffic management policy associated with the identifier of the target micro service, the traffic management device may manage the network traffic generated by the application requesting micro service using the successfully found traffic management policy. Therefore, the implementation mode of determining the flow management strategy according to the micro service identifier by the existing flow management device can reduce the change of the existing flow management device as much as possible and improve the flexibility and universality of implementation of the scheme.

In a possible embodiment, before finding out the traffic management policy associated with the identifier of the micro service, the traffic management device may further associate the identifier of the micro service with the traffic management policy in advance, and store an association between the identifier of the micro service and the second traffic management policy, so that the traffic management device may further determine the traffic management policy for managing the network traffic according to the identifier of the micro service.

In a possible implementation manner, when acquiring the identifier of the service scenario and the traffic feature corresponding to the identifier of the service scenario, the traffic management apparatus may specifically present a service scenario input interface to a technician, and acquire the identifier of the service scenario input by the technician and the traffic feature corresponding to the identifier of the service scenario in response to an input operation of the technician for the service scenario input. Therefore, through the visual service scene input interface, the technical personnel can conveniently input the service scene and the flow characteristics.

In a possible implementation manner, when associating the identifier of the service scenario with the traffic management policy, the traffic management apparatus may specifically present a policy configuration interface to a technician, and associate the identifier of the service scenario with the traffic management policy in response to a configuration operation of the technician for the traffic management policy. Therefore, through the visual strategy configuration interface, technicians can conveniently configure the flow management strategies corresponding to different service scenes.

In a second aspect, an embodiment of the present application further provides a method for configuring a traffic management policy, where the method is applied to a traffic management device, and before receiving an access request of an applied user to a first micro service, the traffic management device obtains an identifier of a service scenario and a traffic feature corresponding to the identifier of the service scenario, associates the obtained identifier of the service scenario with the traffic management policy, and stores an association relationship between the established identifier of the service scenario and the traffic management policy, where the traffic management policy is used to manage network traffic belonging to the service scenario corresponding to the identifier of the service scenario.

Therefore, in the process of configuring the flow management strategy, a technician does not need to configure according to the micro-service in the service system, namely, the technician does not need to know the micro-service architecture at the rear end of the service system in advance; meanwhile, the same service scenes (such as user login scenes) may exist in a plurality of micro services, so that the number of service scenes for the technical staff to configure the traffic management policy is smaller than that of the micro services, and the difficulty for the technical staff to configure the traffic management policy from the service field perspective is generally lower. Therefore, the learning cost of the technical personnel for configuring the flow management strategy can be effectively reduced, and correspondingly, the efficiency of the technical personnel for configuring the flow management strategy can be improved.

In a third aspect, an embodiment of the present application further provides a traffic management device, where the traffic management device is configured to manage traffic of a microservice in an application, and the device includes an analysis module, a matching module, and a traffic management module. The analysis module is used for receiving an access request of an application user to the micro service; the matching module is used for determining the identifier of a target service scene according to the target flow characteristics included in the access request, wherein the target service scene represents an event when the user of the application uses the micro-service; and the flow management module is used for searching a target flow management strategy associated with the identifier of the target service scene and managing the network flow belonging to the target service scene according to the target flow management strategy.

In one possible embodiment, the apparatus further comprises: and the policy management module is used for acquiring the identifier of the service scene and the traffic characteristics corresponding to the identifier of the service scene before receiving the access request of the user of the application to the micro service, and establishing association between the identifier of the service scene and the traffic management policy.

Optionally, the apparatus may further include a policy storage module configured to store an association between the identifier of the service scenario established by the policy management module and the traffic management policy.

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

In a possible implementation, the matching module is specifically configured to: searching for an identifier of a target micro service matched with a target flow characteristic included in an access request of the micro service and a flow management strategy associated with the identifier of the target micro service; and when the search fails, determining the identifier of the target service scene according to the target flow characteristics.

In a possible implementation manner, the policy management module is specifically configured to: presenting a service scene input interface; and responding to the input operation aiming at the service scene, and acquiring the identification of the service scene and the flow characteristics corresponding to the identification of the service scene.

In a possible implementation manner, the policy management module is specifically configured to: presenting a strategy configuration interface; and responding to the configuration operation aiming at the flow management strategy, and establishing association between the identification of the service scene and the flow management strategy.

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

In a fifth aspect, the present application provides a computing device comprising a processor, a memory, and a display. The processor and the memory are in communication with each other. The processor is configured to execute instructions stored in the memory to cause the computing device to perform a method of traffic management as in the first aspect or any implementation of the first aspect.

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

In a seventh aspect, the present application provides a computer-readable storage medium, which stores instructions that, when executed on a computing device, cause the computing device to perform the traffic management method according to the first aspect or any implementation manner of the first aspect.

In an eighth aspect, the present application provides a computer-readable storage medium having stored therein instructions, which, when run on a computing device, cause the computing device to perform the method for configuring a traffic management policy according to the second aspect or any implementation manner of the second aspect.

In a ninth aspect, the present application provides a computer program product comprising instructions which, when run on a computing device, cause the computing device to perform the traffic management method according to 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 that, when run on a computing device, cause the computing device to perform a method of configuring a traffic management policy as set forth in the second aspect or any implementation of the second aspect.

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

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.

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

FIG. 2 is a schematic diagram of an embodiment;

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

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

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

fig. 6 is a schematic diagram of an association relationship between a service scenario identifier and a first traffic characteristic provided in an embodiment of the present application;

FIG. 7 is a schematic diagram of a configuration file provided in an embodiment of the present application;

FIG. 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 yet another configuration file provided by an embodiment of the present application;

FIG. 10 is a schematic illustration of a second flow characteristic multiplexing a first flow characteristic;

fig. 11 is a flowchart illustrating an exemplary method for managing network traffic according to an embodiment of the present disclosure;

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

fig. 13 is a flowchart illustrating a further exemplary method for managing network traffic according to an embodiment of the present application;

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

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

Detailed Description

The scheme in the embodiments provided in the present application will be described below with reference to the drawings in the present application.

The terms "first," "second," and the like in the description and in the claims of the present application and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances and are merely descriptive of the various embodiments of the application and how objects of the same nature can be distinguished.

Fig. 1 is a schematic diagram of an exemplary system architecture. As shown in fig. 1, the system includes a requesting device 100, a traffic management device 200, and a service execution device 300. The requesting device 100 is, for example, a client or the like, and may request the business System to access any one or more microservices through a seventh Layer protocol (i.e., Application Layer) in an Open System Interconnection Model (OSI). The traffic management device 200 may manage network traffic generated during the process of accessing the microservice by the requesting device 100, and may include an analyzing module 201, a matching module 202, a traffic management module 203, a policy storage module 204, and a policy management module 205; the service execution device 300 is configured to execute a corresponding service according to the micro service requested by the request device 100. The business system described above may be implemented as an application, and thus, the application includes a plurality of microservices, each microservice implementing a particular function of the application. The application can be published and used, and when the user of the application uses the application, one or more micro-services in the application are operated to provide corresponding responses to the user of the application. The aforementioned request device 100 requests the business system to access any one or more microservices, which may be triggered directly or indirectly by the user of the application when the user of the application uses the application.

In specific implementation, the parsing module 201 may parse the micro-service access request sent by the requesting device 100, and obtain the contents, such as the micro-service identifier, the request mode, and the user name, carried in the micro-service access request. For example, the micro service access request sent by the requesting device 100 may be, as shown in fig. 2, a HyperText Transfer Protocol (HTTP) message, the parsing module 201 parses the HTTP message, and determines that the micro service to be accessed is a "commenting service", the request mode is "GET", and the User name (X-User) is "Jack", where the parsed information may be stored in a corresponding address and the address where the information is stored is indicated by a pointer.

Then, the matching module 202 finds out the micro service indicated by the pointer from a pre-stored micro service list, and further finds out the category to which the network traffic requesting the micro service belongs from the micro service list according to the found out micro service and other information indicated by the pointer. For example, in the example shown in fig. 2, the matching module 202 finds the microservice in the microservice list according to the microservice name "commenservice" indicated by the pointer, and determines the subset name "subset a" according to the username "JACK" indicated by the pointer. Wherein different subset names represent different classes of network traffic and each subset name has a corresponding traffic characteristic. As in fig. 2, "subset a" characterizes the network traffic as coming from the user "JACK", while "subset B" characterizes the network traffic as coming from the Chrome browser under the Linux operating system.

Next, the traffic management module 203 may determine a traffic management policy corresponding to the subset name of the network traffic by searching the subset name and traffic management policy association table according to the category (i.e., the subset) to which the found network traffic belongs, and manage the network traffic generated by requesting the micro service by using a corresponding management unit based on the determined traffic management policy, for example, the retry unit 2031 in fig. 1 is responsible for managing retry times of requesting the micro service to the service system, the timeout unit 2032 is responsible for managing timeout time when requesting the micro service to the service system, and the current limiting module 2033 is responsible for managing frequency of requesting the micro service to the service system. Still taking fig. 2 as an example, the traffic management module 203 may search the pre-stored association table of the subset name "subset a" determined by the matching module 202, so as to determine that the time threshold of the configuration of the network traffic generated by the request micro service "commenting service" is 10s (seconds) for the timeout determination, and the upper limit of the number of times of the request error retries is 2, when the micro service "commenting service" is requested to the service system, if the service system does not respond for 10 seconds or the number of times of re-initiating the request to the service system reaches 2 and there is still a request error, the retry unit 1 or the timeout unit 2032 controls to stop the micro service request process of the request device 100, so as to avoid the series of problems 2032 that the network traffic between the request device 100 and the service system is too large due to the abnormal network traffic when the request device 100 requests the micro service this time, and the effective management of the network flow is realized.

The micro service list stored in the matching module 202 and the association table of the subset name and the traffic management policy stored in the traffic management module 203 may be pulled from the policy storage module 204 in advance. The association table may be pre-established by the policy management module 205 and sent to the policy storage module 204 for storage. In actual application, the policy management module 205 may also update the association table stored in the policy storage module 204. Of course, in other possible embodiments, the association table may be configured in advance by a technician and stored in the policy storage module 204 in a unified manner.

Therefore, when the management of the network traffic is implemented, the matching module 202 needs to be configured with the micro service identifier and the traffic characteristic corresponding to the micro service identifier in advance. Otherwise, when the micro service requested by the requesting device 100 does not have the corresponding micro service identifier matching with the micro service identifier in the matching module 202, the traffic management device 200 cannot determine the corresponding traffic management policy for the micro service requested by the requesting device 100, so that the problem of abnormal network traffic due to unstable network communication is likely to occur.

However, in practical applications, the functions of the service system are usually rich, which means that the number of micro services included in the service system is large, and therefore, in order to avoid network traffic abnormality when requesting micro services from the service system as much as possible, a technician needs to know the micro service architecture at the back end of the service system (i.e., each micro service included in the service system) in advance, and configure a corresponding traffic management policy for each micro service individually, which makes the learning cost of the technician high, and the efficiency of configuring traffic management policies for the micro services one by one is low.

Therefore, in the embodiment of the application, the network traffic generated when the application requests the micro service can be managed from the service scene dimension. The service scenario refers to an event generated when an application requests a micro service, and the application may generate a plurality of events in the process of requesting a micro service, that is, a plurality of different service scenarios may exist in the process of requesting a micro service at a time. For example, in the process of requesting the microservice "commenting service", there may be an event of a user logging in an account, an event of feeding back comment information, an event of a user logging out an account, and the like, and when the microservice "commenting service" is requested this time, there are a service scenario of the user logging in, a service scenario of the feedback information, a service scenario of the user logging out, and the like.

Specifically, before the application requests the micro service, the association between the identifier of the service scenario and the traffic management policy may be established, so that, in the process of requesting the micro service, the traffic management device may further determine the corresponding traffic management policy by determining the identifier of the service scenario existing in the process of requesting the micro service, thereby effectively managing the network traffic generated in the process of requesting the micro service by the application based on the determined traffic management policy. In the process that a technician configures a flow management strategy in advance (such as an administrator of a flow management device), the configuration is not required to be carried out according to the micro-service in the service system, so that the technician is not required to know the micro-service architecture at the rear end of the service system; moreover, on one hand, the same service scenes (such as user login scenes) may exist in all the micro services, so that the number of the service scenes for the technician to configure the traffic management policy is smaller than that of the micro services, and on the other hand, the difficulty for the technician to configure the traffic management policy from the perspective of the service field is generally lower. Therefore, the learning cost of the technical personnel for configuring the flow management strategy can be effectively reduced, and correspondingly, the efficiency for configuring the flow management strategy can be improved. Meanwhile, in the process of calling the micro-service by the application, the traffic management device can also effectively manage the generated network traffic by using the traffic management strategy corresponding to the service scene, so that the problem of abnormal network traffic caused by unstable network communication is avoided.

As an example, the embodiment of the present application may be applied to an application scenario as 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 may call a traffic management service through a Java/Go language development framework or a service grid, where the traffic management service may be specifically implemented by the traffic management device 200, and meanwhile, the technician 301 also implements policy configuration on network traffic generated when the front-end application 303 requests a microservice by calling an Application Programming Interface (API) of the front end or the back end. Specifically, when the front-end API interface is called to configure and manage the network traffic, the front-end application 303 may present a User Interface (UI) for human-computer interaction to the technician 301, and the technician 201 may perform corresponding configuration and management operations on the UI interaction interface, for example, the technician 301 inputs the identifier of the service scene, the traffic characteristics, and the traffic management policy on the UI interaction interface and completes the corresponding configuration. Alternatively, the technician 301 may configure the traffic management policy by calling the backend API interface, for example, may complete policy configuration by a command line or the like.

In practical applications, the traffic management device 200 may be deployed in a cloud as a cloud service, and then the technician 301 calls the traffic management device 200 in the cloud through a programming language development framework or a service grid to perform corresponding policy configuration on network traffic. Alternatively, the traffic management apparatus 200 may be deployed locally, such as in a local server, and accordingly, the technician 301 may implement policy configuration of the network traffic by invoking the traffic management apparatus 200 on the local server. Of course, in other possible embodiments, different modules in the traffic management apparatus 200 may be deployed in the cloud and the local, 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 store the association relationship between the traffic management policy and the service scene identifier configured by the technician 301 in the cloud; the parsing module 201, the matching module 202, and the traffic management module 203 in the traffic management apparatus 200 may be deployed locally, and the matching module 202 may pull, in advance, an association between the service scenario identifier and the traffic feature from the cloud, and the traffic management module 203 pulls, in advance, an association between the service scenario identifier and the traffic management policy from the cloud. It should be understood that the above deployment manner is only used for exemplary illustration and is not used for limitation, and other possible deployment manners may be adopted to deploy the traffic management device 200 in practical applications.

After the technician 301 completes the policy configuration through the traffic management device, the user 302 may directly or indirectly trigger the front-end application 303 to invoke one or more micro services, for example, when the user 302 performs an operation of browsing evaluation information of a certain commodity on the front-end application 303, the front-end application 303 may request the micro service "commensaliservice" to acquire the commodity evaluation information to be presented to the user 302. In the process that the front-end application 303 requests the micro service, the traffic management device 200 may correspondingly manage the network traffic generated when the front-end application 303 requests the micro service according to the configured traffic management policy.

Various non-limiting embodiments of object recognition are described in detail below.

Fig. 4 is a schematic flowchart of a method for configuring a traffic management policy according to an embodiment of the present application. This method may be applied to the traffic management device 200 shown in fig. 1, or may be applied to a device configured separately, which is not limited in this embodiment, and for convenience of description, a mode in which the traffic management device 200 performs configuration of a traffic management policy will be described as an example. The method for configuring the traffic management policy shown in fig. 4 may specifically include:

s401: the traffic management device 200 obtains an identifier of a service scenario and a first traffic characteristic corresponding to the identifier of the service scenario, where the first traffic characteristic is used to describe network traffic in the service scenario corresponding to the identifier of the service scenario.

In this embodiment, a traffic management policy may be configured for the network traffic from the perspective of the service field, and different service scenarios may be distinguished by using corresponding service scenario identifiers, and the network traffic in the service scenario is described according to the traffic characteristics of the service scenario. The service scenario refers to an event generated when a user of an application (e.g., the user 302 shown in fig. 3) uses a microservice, such as the user login event, the user logout event, and the like. Moreover, when an application accesses a plurality of different micro services, the same service scenario may exist, for example, when the application accesses a plurality of micro services such as "commenting service" and "CreateResource", the service scenario for the user to log in may exist. In this way, when the traffic management policy is configured based on the service scenario, only one traffic management policy may be configured for the same service scenario in which a plurality of micro services appear, so that the number of technicians configuring the traffic management policy may be reduced.

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

As an exemplary specific implementation, when a technician configures a corresponding traffic management policy for network traffic through a language development framework (e.g., Go language development framework, Java language development framework) or a service grid, the language development framework or the service grid may invoke the traffic management apparatus 200, and the traffic management apparatus 200 may present a service scenario input interface to the technician so that the technician inputs a corresponding service scenario identifier and a traffic characteristic on the service scenario input interface. For example, a service scenario input interface presented by the traffic management device 200 to a technician 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 a request mode, a request path, a user name (used as a traffic feature describing network traffic in the service scenario) when requesting a micro service, and the like. In this way, the traffic management device 200 obtains the service scenario identifier and the corresponding traffic characteristics according to the input operation performed by the technician.

In fig. 5, a service scene name is taken as a service scene identifier for example to be exemplarily illustrated, and the service scene name may be, for example, "create resource" (CreateResource), "VIP user create resource" (VIP user create resource), "user activity" (user activity), "VIP user activity" (VIP user activity), and the like.

In practical application, the traffic management device 200 may also combine the service scene name and other information as a service scene identifier, for example, the service scene name "create resource" and a specific resource object "order" (order) or "account" (account) may be used as the service scene identifier, and at this time, the create order and the create account belong to different service scenes; or, the traffic management device 200 may combine the service scene name, the name of the network environment (such as a cellular data network, a WIFI network, etc.) requesting the micro service, and the application name requesting the micro service as the service scene identifier, where the service scenes with the same service scene name and different application names are different service scenes; alternatively, the traffic management policy 200 may combine the service scenario name with any one of the user behavior, the request source, and the resource operation to define different types of service scenarios. Thus, finer-grained division of the service scene can be realized. Of course, other information may also be used as the service scene identifier, which is not limited in this embodiment.

In addition, the traffic characteristics are not limited to the request mode, the request path, and the user name shown in fig. 5, and may be any one of these information, or may also be other information that can be used to describe the network traffic, such as a communication protocol name used when requesting the micro service, a header (header) that includes information describing which browser, mobile phone model, and any information in the operating system the network traffic originates from, and the like.

In this embodiment, when the traffic management device 200 acquires the service scenario identifier and the first traffic characteristic, the service scenario identifier and the first traffic characteristic may be associated with each other, so that when the network traffic requesting the micro service has the first traffic characteristic, the traffic management device 200 may determine that the network traffic belongs to the service scenario associated with the first traffic characteristic. For example, the service scenario identification input by the technician may include a coarse-grained service scenario description, such as: "create resources" and "user activities", and the technician can further input fine-grained business scenario names under coarse-grained business scenario description, such as: "create order", "create account", and "login", and the traffic characteristics entered by the technician are the request path "/v 1/order", the request path "/v 1/account", and the request mode "POST/login", respectively. Then, the traffic management policy 200 may establish an association relationship as shown in fig. 6 based on the service scenario identifier and the first traffic characteristics input by the technician.

In actual application, when the traffic management policy 200 establishes the association relationship between the service scene identifier and the first traffic characteristic, a corresponding configuration file may be specifically generated. For example, traffic management policy 200 may generate a configuration file as shown in fig. 7 for the association shown in fig. 6. The configuration file on the left side of fig. 7 indicates the association between the service scenario identifier "create resource" and its corresponding traffic feature, and the configuration file on the right side of fig. 7 indicates the association between the service scenario identifier "user activity" and its corresponding traffic feature.

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 a service scenario corresponding to the service scenario identifier.

S403: the traffic management device 200 stores an association between the service scenario identification and the traffic management policy.

For network traffic in various service scenarios, the traffic management device 200 may configure a corresponding traffic management policy for the network traffic to manage, so as to avoid the network traffic from being abnormal as much as possible.

In an exemplary embodiment, the traffic management device 200 may present a policy configuration interface to a technician to facilitate the technician configuring a corresponding first traffic management policy for each traffic scenario on the policy configuration interface. For example, a policy configuration interface presented by the traffic management apparatus 200 may be as shown in fig. 8, and a technician may input a corresponding traffic management policy according to a service scenario and a traffic characteristic presented on the policy configuration interface, where as shown in fig. 8, the traffic management policy input by the technician for the service scenario a and the traffic characteristic a includes: the request timeout time is 10s, the upper limit of the number of request error retries is 2, and the like. Then, the traffic management device 200 may associate the first traffic management policy input by the technician with the service scenario identifier. Thus, for the network traffic in the service scenario, the traffic management can be performed by using the first traffic management policy associated with the network traffic. As an example, the traffic management apparatus 200 may specifically establish an 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 "user activity.logic" and "create.order", and the first traffic management policy is an upper limit of retry (retry) times when an error is requested, a configuration file of an association relationship between the service identifier and the first traffic management policy is as shown in fig. 9, that is, when the service scenario is a user login or an order is created, the maximum error retry times (MaxAttempts) of network traffic is 3 times.

In practical application, the policy configuration interface shown in fig. 8 may also be combined with the service scenario input interface shown in fig. 5 to form an interface, so that a technician can simultaneously complete the definition of a service scenario and the configuration of a traffic management policy corresponding to the service scenario on the configuration interface. Therefore, in the process of configuring the flow management strategy, a technician can configure the flow management strategy from the perspective of the service field without knowing the micro service architecture under the service system, and the decoupling between the configured flow management strategy and the micro service architecture is realized, so that the learning cost of the technician can be effectively reduced, and the configuration efficiency is improved.

In a further possible embodiment, the traffic management device 200 may also configure traffic management policies for microservices. Specifically, in the process of configuring the corresponding traffic management policy according to the service scenario, the traffic management device 200 may further obtain the microservice identifier and a second traffic characteristic corresponding to the microservice identifier at the same time, where the second traffic characteristic is used to describe the network traffic generated when the microservice is requested, and then the traffic management device 200 may associate the microservice identifier with the second traffic management policy, so that the traffic management device 200 may use the second traffic management policy to manage the network traffic belonging to the microservice corresponding to the microservice identifier.

Thus, when the requesting device 100 requests a micro service, the traffic management device 200 may search whether the micro service requested by the requesting device 100 has a corresponding second traffic management policy according to an association relationship between the micro service identifier and the second traffic management policy, if the micro service requested by the requesting device 100 has the corresponding second traffic management policy, the network traffic generated by requesting the micro service may be directly managed based on the searched second traffic management policy, and if the micro service has not been searched, the traffic scenario to which the network traffic belongs may be determined according to the traffic characteristics of the network traffic for which the device 100 requests the micro service, and further, the first traffic management policy corresponding to the traffic scenario may be searched according to the association relationship between the traffic scenario identifier and the first traffic management policy, and the network traffic may be managed based on the searched first traffic management policy. Thus, the modification of the existing traffic management device 200 can be reduced as much as possible, and the flexibility and universality of implementation of the scheme can be improved.

Since both the second traffic characteristics and the first traffic characteristics are used to describe network traffic generated when the microservice is requested, in some embodiments, some or all of the second traffic characteristics associated with the microservice identification may be the same as the first traffic characteristics. At this time, when establishing the association relationship between the micro service identifier and the second traffic characteristic, the traffic management device 200 may specifically establish the association relationship between the micro service identifier and the indication information of the second traffic characteristic, where the indication information of the second traffic characteristic is used to indicate the first traffic characteristic associated with the service scene identifier. In this way, the traffic management apparatus 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 micro service identifier, so that the storage burden and maintenance cost of the traffic management apparatus 200 can be reduced, and the redundant configuration can be reduced. For example, assuming that the association relationship (configuration file) between the service scenario identifier (user activity) and the first traffic characteristic (Jack, namely, the user name is Jack) is shown in the left side of fig. 10, the configuration file generated when the traffic management device 200 associates the micro service identifier ("CommentService") with the second traffic characteristic may be shown in the right side of fig. 10, where "refer: jack "is used to indicate that the feature description of the second traffic feature multiplexes the feature description of the first traffic feature, and both refer to the user of the network traffic as" Jack ".

In the foregoing embodiment, the technical solution of the embodiment of the present application is mainly described in detail in terms of configuring the traffic management policy by the traffic management device 200, and a specific implementation process of performing network traffic management on the micro service access request sent by the traffic management device 200 to the request device 100 is described in the following.

As shown in fig. 11, which is a schematic flowchart of an exemplary method for managing network traffic, the flow may be applied to the system architecture shown in fig. 12, and the flow specifically may include:

s1101: the matching module 202 pulls the association between the service scenario identifier and the first traffic characteristic from the policy storage module 204, and the traffic management module 203 pulls the association between the service scenario identifier and the first traffic management policy from the policy storage module 204.

The two association relations stored in the policy storage module 204 may be established by the policy management module 205 according to an input operation of a technician on a corresponding interface, and the established association relations are stored in the policy storage module 204. For how to implement the specific implementation of how to establish the association relationship between the service scenario identifier and the first traffic characteristic and the association relationship between the service scenario identifier and the first traffic management policy by the policy management module 205, reference may be made to the description of relevant parts in the foregoing embodiments, which is not described herein again. Of course, in other examples, the association relationship may be established in advance by a technician and stored in the policy storage module 204.

It should be understood that, in other embodiments, the step S1101 may not be executed, for example, the matching module 202 and the traffic management module 203 may store the association relationship between the corresponding service scenario identifier and the traffic feature and the association relationship between the service scenario identifier and the traffic management policy in advance, and do not need to pull the association relationship from the policy management module 204 each time the network traffic is managed; alternatively, the association relationship stored in the matching module 202 and the traffic management module 203 may be statically configured in advance by a technician, and need not be acquired from the policy storage module 204.

S1102: the requesting device 100 sends an access request for a microservice.

In this embodiment, when accessing a target microservice to a service system, a requesting device 100 may send a microservice access request, where the access request carries a target traffic characteristic representing a network traffic generated by the requested target microservice, and when actually applying, the access request may further include an identifier of the target microservice. For example, the requesting device 100 may send a network packet based on the HTTP protocol, where the network packet includes a target microservice name "commenservice" and target traffic characteristics "POST/logic" (request mode).

In this embodiment, the requesting device 100 may be, for example, an application that needs to invoke a microservice, such as a browser. The requesting device 100 may generate an access request for a target microservice and transmit the access request to the traffic management device 200, directly or indirectly by a user.

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

Illustratively, a corresponding parsing model (model) may be run in the parsing module 201, and the name of the target micro service, the target traffic characteristics, and the like in the data access request may be parsed through the parsing model. The parsing module 201 may store the parsed information 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 a target traffic scene identifier corresponding to the target traffic characteristic by searching for an association relationship between the traffic scene identifier and the first traffic characteristic according to the information indicated by the pointer.

Still taking the above-mentioned target traffic characteristic "POST/location" as an example, assuming that the association between the service scenario identifier and the first traffic characteristic may include an association between "user activity" (service scenario identifier) and "POST/location" (first traffic characteristic) as shown in fig. 12, the matching module 202 may determine that the target service scenario identifier is "user activity" by looking up the association according to the target traffic characteristic "POST/location" indicated by the pointer.

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

Assuming that the association relationship between the service scenario identifier and the first traffic management policy may include "user activity" and timeout time 10S as shown in fig. 12, and the upper limit of the retry time is 2 times (the first traffic management policy), the traffic management module 203 determines that the target traffic management policy is the timeout time 10S and the upper limit of the retry time is 2 times according to the target service scenario identifier "user activity" determined in step S1004, so as to manage the network traffic generated when the requesting device 100 requests the micro service by using the searched target traffic management policy.

S1106: the traffic management module 203 manages the network traffic generated when the service execution device 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 retry number is 2, after the service execution device 300 has a request error and the retry number reaches 2 times, if the request error still occurs, the traffic management module 203 controls the service execution device 300 to terminate the request of the micro service to the service system. For another example, when the target traffic management policy is to limit the flow for 50 times per second, the traffic management module 203 may limit the number of times that the traffic execution device 300 requests the micro service from the traffic system within a unit time (e.g., 1 second) to be within 50 times, and the like.

In actual application, the matching module 202 may determine multiple target service scene identifiers according to the target traffic characteristics, for example, the target service scene identifiers include coarse-grained service scene descriptions "CreateResource" (creation resources) and fine-grained service scene names "CreateResource order"), and correspondingly, the traffic management module 203 determines multiple target traffic management policies for the multiple service scene identifiers of different granularities, at this time, when the traffic management module 203 manages the network traffic, the traffic management module may manage the network traffic according to the target traffic management policies corresponding to the fine-grained service scene identifiers, for example, manage the network traffic according to the target traffic management policies corresponding to the "CreateResource order".

In this way, in the present embodiment, the traffic management device 200 can determine the traffic management policy according to the traffic scenario of the network traffic in the process of requesting the micro service by the requesting device 100, and use the traffic management policy to realize effective management of the network traffic generated by the requesting micro service.

In the embodiment shown in fig. 11, the association stored in the matching module 202 may be only the association between the service scene identifier and the traffic feature, and in other possible embodiments, the association between the service scene identifier and the traffic feature and the association between the micro-service identifier and the traffic feature may be stored in the matching module 202 at the same time. At this time, a specific implementation process of the traffic management device 200 for processing the microservice access request sent by the requesting device 100 may be as shown in fig. 13, and the flow may be applied to the system architecture shown in fig. 14. In the system architecture shown in fig. 14, the traffic management device 200 has an association relationship between the identifier of the service scenario and the traffic management policy, and an association relationship between the identifier of the micro service and the traffic management policy at the same time. The process may specifically include:

s1301: the matching module 202 pulls the association between the service scene identifier and the first traffic characteristic and the association between the micro-service identifier and the second traffic characteristic from the policy storage module 204, and the traffic management module 203 pulls the association between the service scene identifier and the first traffic management policy and the association between the micro-service identifier and the second traffic management policy from the policy storage module 204.

The association relationship stored in the policy storage module 204 may be established by the policy management module 205 according to an input operation of a technician on a corresponding interface, and the established association relationship is stored in the policy storage module 204. For how to implement the specific implementation of how to establish the association relationship between the service scenario identifier and the first traffic characteristic and the association relationship between the micro-service identifier and the second traffic characteristic and the second traffic management policy by the policy management module 205, reference may be made to the description of relevant parts in the foregoing embodiments, which is not described herein again. In other examples, the association relationship stored in the policy storage module 204 may be pre-imported into the policy storage module 204 by a technician, which is not limited in this embodiment.

It is to be noted that, in other embodiments, the step S1301 may not be executed, for example, the matching module 202 and the traffic management module 203 may store the corresponding association relationship in advance, and do not need to obtain the association relationship from the policy storage module 204; alternatively, the association relationship stored in the matching module 202 and the traffic management module 203 may be statically configured in advance by a technician, and need not be acquired from the policy storage module 204.

S1302: the requesting device 100 sends an access request for a microservice.

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

S1304: the matching module 202 searches for an association relationship between the micro-service identifier and the second traffic characteristic according to the information indicated by the pointer, and determines whether a target micro-service identifier matching the target traffic characteristic exists.

S1305: when the target micro service identifier exists, the traffic management module 203 searches for a target traffic management policy associated with the target micro service identifier according to the association relationship between the identifier of the micro service 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 micro service identifier does not exist, the matching module 202 searches for the association relationship between the service scene identifier and the first traffic characteristic according to the information indicated by the pointer, and determines the target service scene identifier matched with the target traffic characteristic.

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

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

It should be noted that, for specific implementation manners of each step in this embodiment, reference may be made to descriptions of relevant parts in the foregoing embodiments, and details are not described herein.

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

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

Computing device 1500 includes a bus 1501, a processor 1502, and memory 1503. The processor 1502 and the memory 1503 communicate with each other via a bus 1501.

The bus 1501 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 15, but this is not intended to represent only one bus or type of bus.

The processor 1502 may be any one or more of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Micro Processor (MP), a Digital Signal Processor (DSP), and the like.

The memory 1503 may include a volatile memory (RAM), such as a Random Access Memory (RAM). The memory 1503 may also include a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory, a hard drive (HDD) or a Solid State Drive (SSD).

The memory 1503 stores executable program codes, and the processor 1502 executes the executable program codes to perform the traffic management method and/or the method for configuring the traffic management policy performed by the traffic management device 200.

The embodiment of the application also provides a computer readable storage medium. The computer-readable storage medium can 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 medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), among others. The computer-readable storage medium includes instructions that instruct a computing device to perform the traffic management method performed by the traffic management apparatus 200 described above.

The embodiment of the application also provides another computer readable storage medium. The computer-readable storage medium can 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 medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), among others. The computer-readable storage medium includes instructions that direct a computing device to perform the method for configuring traffic management policies performed by the traffic management apparatus 200 described above.

The embodiment of the application also provides a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computing device, cause the processes or functions described in accordance with embodiments of the application to occur, in whole or in part.

The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

The computer program product may be a software installation package which may be downloaded and executed on a computing device in the event that any of the aforementioned object recognition methods are required.

The description of the flow or structure corresponding to each of the above drawings has emphasis, and a part not described in detail in a certain flow or structure may refer to the related description of other flows or structures.

Claims

1. A traffic management method is applied to a traffic management device, and the traffic management device is used for managing the traffic of micro-services in an application, and the method comprises the following steps:

receiving an access request of a user of the application to the micro service;

determining an identifier of a target business scene according to the target flow characteristics included in the access request, wherein the target business scene represents an event when the user of the application uses the micro service;

searching a target flow management strategy associated with the identifier of the target service scene;

and managing the network traffic belonging to the target service scene according to the target traffic management strategy.

2. The method of claim 1, wherein prior to receiving a request for access to a microservice by a user of the application, the method further comprises:

acquiring an identifier of a service scene and a flow characteristic corresponding to the identifier of the service scene;

and establishing association between the identifier of the service scene and the flow management strategy.

3. The method of claim 2, wherein the target business scenario is a scenario that exists when access to multiple microservices is requested.

4. The method according to any one of claims 1 to 3, wherein the determining an identity of a target service scenario according to a target traffic characteristic included in the access request comprises:

searching for an identifier of a target micro service matched with a target traffic characteristic included in an access request of the micro service and a traffic management policy associated with the identifier of the target micro service;

and when the search fails, determining the identifier of the target service scene according to the target flow characteristics.

5. The method according to claim 2 or 3, wherein the obtaining of the service scenario identifier and the traffic characteristic corresponding to the service scenario identifier comprises:

presenting a service scene input interface;

responding to an input operation aiming at a service scene, and acquiring the identifier of the service scene and the flow characteristics corresponding to the identifier of the service scene.

6. The method according to any of claims 2 to 4, wherein associating the identity of the traffic scenario with the traffic management policy comprises:

presenting a strategy configuration interface;

and responding to configuration operation aiming at the traffic management strategy, and establishing association between the identification of the service scene and the traffic management strategy.

7. A method for configuring a traffic management policy, the method being applied to a traffic management device, and the method comprising, before receiving a request for access to a microservice by a user of an application:

establishing association between the identifier of the service scene and the flow management strategy;

and storing the association between the identifier of the service scene and the traffic management policy, wherein the traffic management policy is used for managing the network traffic belonging to the service scene corresponding to the service scene identifier.

8. The method of claim 7, wherein the target business scenario is a scenario that exists when access to multiple microservices is requested.

9. A traffic management device configured to manage traffic of a microservice in an application, the device comprising:

the analysis module is used for receiving an access request of a user of the application to the micro-service;

the matching module is used for determining the identifier of a target business scene according to the target flow characteristics included in the access request, wherein the target business scene represents an event when the user of the application uses the micro-service;

and the flow management module is used for searching a target flow management strategy associated with the identifier of the target service scene and managing the network flow belonging to the target service scene according to the target flow management strategy.

10. The apparatus of claim 9, further comprising:

and the policy management module is used for acquiring the identification of the service scene and the flow characteristics corresponding to the identification of the service scene before receiving the access request of the user of the application to the micro service, and establishing the association between the identification of the service scene and the flow management policy.

11. The apparatus of claim 10, wherein the target business scenario is a scenario that exists when access to multiple microservices is requested.

12. The apparatus according to any one of claims 9 to 11, wherein the matching module is specifically configured to:

13. The apparatus according to claim 10 or 11, wherein the policy management module is specifically configured to:

presenting a service scene input interface;

14. The apparatus according to any one of claims 10 to 12, wherein the policy management module is specifically configured to:

presenting a strategy configuration interface;

15. The device is characterized by comprising a policy management module and a policy storage module, wherein the policy management module is used for acquiring an identifier of a service scene and traffic characteristics corresponding to the identifier of the service scene before receiving an access request of an application user to a micro service, and associating the identifier of the service scene with a traffic management policy; the policy storage module is configured to store an association between the identifier of the service scenario and the traffic management policy, where the traffic management policy is configured to manage network traffic belonging to the service scenario corresponding to the service scenario identifier.

16. The apparatus of claim 15, wherein the target business scenario is a scenario that exists when access to multiple microservices is requested.

17. A computing device comprising a processor, a memory;

the processor is configured to execute instructions stored in the memory to cause the computing device to perform the method of any of claims 1 to 6, or to perform the method of claim 7 or 8.

18. A computer-readable storage medium comprising instructions that, when executed on a computing device, cause the computing device to perform the method of any of claims 1 to 6, or perform the method of claim 7 or 8.