Dynamic route management method, device, equipment and storage medium

Abstract

Embodiments of the application disclose a dynamic route management method, device and equipment and a storage medium, wherein the method comprises: in response to receiving an access request of a user, obtaining an interface request log recorded by a gateway; wherein the interface request log is used to represent request operation information of the user on all resources in the application system; the request operation information is a standard HTTP request method; determining a key resource in the application system within a preset time period; the processing priority of the key resource is higher than that of other resources in the application system; dynamically managing route information in the gateway according to a preset management strategy; the gateway at least includes dynamic route information generated for providing access to the key resource. Thus, the access speed to the key resource is accelerated, and the problem of service unavailability caused by the collapse of downstream microservices is reduced.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of computer application technology, and in particular to a dynamic routing management method, apparatus, device, and storage medium. Background Technology

[0002] Distributed applications employ a microservices architecture, breaking down the application into multiple microservice modules and exposing interfaces through a gateway service. These interfaces can be designed in a RESTful style, making them easier for external systems to call. When an external request reaches the gateway, it is forwarded to the specific microservice module based on the routing information configured in the gateway. After a series of inter-service calls, the final result is returned to the user.

[0003] As the number of microservices increases, the call chain of a single request may traverse multiple microservices before finally obtaining a response, increasing the interface response time. Furthermore, while the microservice architecture avoids the "one problem affects the whole system" drawback of monolithic services, the complex inter-service call relationships mean that if a microservice module fails, it will trigger the service circuit breaker mechanism, resulting in a failure to provide a normal response and impacting the system's user experience. Summary of the Invention

[0004] In view of this, embodiments of this application provide a dynamic routing management method, apparatus, device, and storage medium, which at least solves the problem of slow resource access speed and service unavailability caused by the crash of a downstream microservice.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] On one hand, embodiments of this application provide a dynamic routing management method applied to the gateway of an application system, the method comprising:

[0007] In response to receiving a user's access request, the system retrieves the interface request logs recorded by the gateway; wherein the interface request logs are used to characterize the user's request operation information for all resources in the application system; the request operation information is a standard HTTP request method;

[0008] Based on the interface request logs, key resources in the application system are identified within a preset time period; the processing priority of these key resources is higher than that of other resources in the application system.

[0009] The routing information in the gateway is dynamically managed according to a preset management strategy; the gateway includes at least dynamic routing information generated to provide access to the key resources.

[0010] On the other hand, embodiments of this application provide a dynamic routing management device applied to a gateway of an application system, the device comprising:

[0011] The log acquisition module is used to acquire the interface request logs recorded by the gateway in response to receiving a user's access request; wherein, the interface request logs are used to characterize the user's request operation information for all resources in the application system; the request operation information is a standard HTTP request method;

[0012] The resource filtering module is used to identify key resources in the application system within a preset time period; the processing priority of the key resources is higher than that of other resources in the application system.

[0013] The routing management module dynamically manages the routing information in the gateway according to a preset management strategy; the gateway includes at least dynamic routing information generated to provide access to the key resources.

[0014] In another aspect, embodiments of this application provide a computer device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the program to implement some or all of the steps in the above-described method.

[0015] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method.

[0016] The embodiments of this application have at least the following technical effects:

[0017] In this embodiment, the gateway records interface request logs to dynamically identify key resources. Dynamic routing information is then generated for these key resources within the gateway, and this routing information is dynamically managed according to a preset management strategy. This way, access requests reaching the gateway do not need to call multiple microservice modules; they are directly forwarded through the gateway using the dynamically generated routing information for the key resources. This reduces interface response time, and the shortened request path lowers the probability of microservice module failures, thereby improving system stability.

[0018] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this disclosure. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0020] Figure 1 A schematic diagram of an optional flow of the dynamic routing management method provided in an embodiment of this application;

[0021] Figure 2 A schematic diagram of an optional flow of the dynamic routing management method provided in an embodiment of this application;

[0022] Figure 3 A schematic diagram of an optional flow of the dynamic routing management method provided in an embodiment of this application;

[0023] Figure 4 A schematic diagram of the system framework for a dynamic routing management method provided in this application embodiment;

[0024] Figure 5 This is a schematic diagram of the composition structure of a dynamic routing management device provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0028] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0030] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0031] Currently, most backend services of large-scale distributed systems adopt a microservice architecture, which is more flexible in development and deployment compared to the traditional monolithic architecture. Traditional microservice architectures typically set up a gateway service at the system's entry point. After a request reaches the gateway service, it is forwarded to the corresponding backend microservice based on the routing information configured on the gateway.

[0032] Different microservices typically have different network addresses, and external clients may need to call the interfaces of multiple services to fulfill a single business requirement. For example, a movie ticketing app might call movie category microservices, user microservices, payment microservices, and so on. A microservice gateway acts as an intermediary layer between the client and server; all external requests first pass through the microservice gateway. The microservice gateway does not handle specific business logic; it only performs basic functions such as load balancing, security protection, traffic control, and routing.

[0033] Microservices is a design style in system architecture that advocates breaking down an originally independent system into multiple small services. These small services run in their own independent processes and communicate and collaborate with each other based on lightweight communication mechanisms such as HTTP RESTful APIs.

[0034] RESTful (Representative Stateful) is an architectural and design style that focuses on defining resources or objects within an application, with operations on these resources expressed through standard HTTP request methods (GET, POST, DELETE, PUT). RESTful APIs can be designed to be more concise and hierarchical. It has been adopted by many microservice applications as an interface design specification, exposing these interfaces to external systems via gateways.

[0035] An API gateway employing a RESTful design style exposes interfaces whose functionality is intuitively understood through the request URL and HTTP method. For example, an API for querying product information could have a URL of ` / api / products` with a GET request method, rather than ` / api / getProducts`. The former clearly indicates that the resource to be manipulated is `products`, and the specific operation is a GET request. Exposing RESTful interfaces at the gateway allows callers to quickly understand the meaning of the interface, thereby improving development speed.

[0036] This application provides a dynamic routing management method, which can be executed by the processor of a computer device. The computer device refers to a device with dynamic routing management capabilities, such as a server, laptop, tablet, desktop computer, smart TV, set-top box, or mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device). Figure 1 The following is a schematic diagram of an optional flow of the dynamic routing management method provided in the embodiments of this application, such as... Figure 1 As shown, the method includes the following steps S110 to S120:

[0037] Step S110: In response to receiving a user's access request, obtain the interface request log recorded by the gateway.

[0038] Here, the interface request log is used to characterize the user's request operation information for all resources in the application system; the request operation information is the standard HTTP request method, such as the query (GET) method, the create (POST) method, the delete (DELETE) method, and the modify (PUT) method.

[0039] A gateway is the entry point for an application system. After an access request reaches the gateway, it is forwarded to the downstream microservice module for processing based on the routing information configured in the gateway. Since all requests pass through the gateway, it can be used to log interface request requests.

[0040] In some implementations, for each request, the interface request log may record at least one of the following information: user identifier, standard HTTP request method, URI request path, timestamp information of the request arriving at the gateway, and time spent processing each request. In some implementations, based on the URI request path and standard HTTP request method recorded in the interface request log for each request, the correspondence between resource information in the application system and request URIs is determined and recorded in the interface request log. For example, for the resource "book" in an image management system, which includes request methods such as GET, POST, PUT, and DELETE, this resource can correspond to four request URIs.

[0041] It's important to note that API gateways employing a RESTful design style expose interfaces whose functionality is readily apparent from the request URL and HTTP method. For instance, an API for querying product information could have its URL designed as ` / api / products` with a GET request method, rather than ` / api / getProducts`. The former clearly indicates that the resource being manipulated is `products`, and the specific operation is a GET request. Exposing RESTful interfaces at the gateway allows callers to quickly understand the interface's meaning, thereby improving development speed.

[0042] For example, for the main resource in the library management system, namely the book class, the corresponding API gateway interface may include: GET / api / book?author=zhangsan to query book information with author zhangsan; POST / api / book (with book information passed in the HTTP body) to create a new book; DELETE / api / book?name=bookname to delete book information with the book name bookname; PUT / api / book?name=bookname to modify book information with the book name bookname.

[0043] Step S120: Based on the interface request log, determine the key resources in the application system within a preset time period.

[0044] Here, the preset time period is a fixed period of time in the past set according to the actual frequency of access, such as the past hour or day. This application embodiment does not limit this.

[0045] The processing priority of these key resources is higher than that of other resources in the application system, such as resources with high access frequency or resources with long request processing times. Here, a resource is understood as a network data object or service identified by a URI. This application embodiment aims to filter these key resources by adding dynamic routing to requests for these resources at the gateway, reducing request response time and improving the user experience of the application system.

[0046] Step S130: Dynamically manage the routing information in the gateway according to the preset management strategy.

[0047] Here, the gateway includes at least dynamic routing information generated to provide access to the key resources. The client sends an access request to the application system's gateway. Upon receiving the request, the gateway matches the request path, request header, and request method (POST / GET) based on the dynamic routing information configured in the gateway, and forwards the request to the corresponding microservice application. The gateway implements its core routing forwarding function according to the dynamic routing rules.

[0048] Since the frequently accessed or time-consuming resource information in the application system is not static, the dynamic routing management service provided in this application embodiment needs to dynamically update the dynamic routing information generated for key resources and use appropriate strategies to add and delete it.

[0049] In some implementations, dynamic routing information can be added to the gateway for selected key resources. Subsequent requests that need to access these key resources will directly respond to the interface request through this dynamic routing information. In other implementations, dynamic routing information corresponding to key resources is dynamically added or deleted to update the routing information in the gateway.

[0050] In this embodiment, the gateway records interface request logs to dynamically identify key resources. Dynamic routing information is then generated for these key resources within the gateway, and this routing information is dynamically managed according to a preset management strategy. This way, access requests reaching the gateway do not need to call multiple microservice modules; they are directly forwarded through the gateway using the dynamically generated routing information for the key resources. This reduces interface response time, and the shortened request path lowers the probability of microservice module failures, thereby improving system stability.

[0051] Figure 2 The following is a schematic diagram of an optional flow of the dynamic routing management method provided in the embodiments of this application, such as... Figure 2 As shown, the method includes the following steps S210 to S250:

[0052] Step S210: In response to receiving a user's access request, obtain the interface request log recorded by the gateway;

[0053] Step S220: Based on the interface request log, determine the key resources in the application system within a preset time period;

[0054] Here, steps S210 to S220 correspond to steps S110 to S120, respectively. In practice, the specific implementation of steps S110 to S120 can be referred to.

[0055] Step S230: If the access request is a query request for the key resource, generate a converged microservice that provides access to the key resource;

[0056] Here, the integrated microservices primarily provide external access to GET requests for this key resource.

[0057] In some embodiments, step S230 may include steps S231 to S232 as follows:

[0058] Step S231: If the access request is a query request for the key resource, generate a code module for the key resource using the resource query code template;

[0059] Here, the resource query code template refers to the basic operation function of querying the database or persistence layer in a common computer processing application system, that is, mainly providing the GET request method for key resources.

[0060] Step S232: Create the integrated microservice corresponding to the code module in the application system through the automated deployment platform.

[0061] Here, the converged microservice is primarily used to access resources added to the dynamic routing, while simultaneously maintaining a mirror image of the underlying data identical to that in the original service. This embodiment of the application automatically generates converged microservices for accessing key resources while adding dynamic routing information for critical resources to the gateway.

[0062] It is worth noting that, according to the conventional request processing method in microservice systems, querying information about a resource may involve multiple microservices processing the request before finally returning a result to the user. In this embodiment, the process that originally required accessing multiple microservices to obtain a result is now completed by an automatically generated new microservice, namely the merged microservice. Thus, the merged microservice replaces the resource query function originally provided by multiple microservice modules that offered access to key categories.

[0063] Step S240: Add dynamic routing information for the converged microservice to the gateway;

[0064] Here, the dynamic routing information includes access path, access method, and other information. Through this dynamic routing information, access requests can be directly forwarded to the corresponding converged microservice.

[0065] Step S250: If the access request is a non-query request for the key resource, delete the dynamic routing information in the gateway.

[0066] Here, non-query requests refer to POST, PUT, or DELETE requests. For these requests, in addition to being routed through the gateway to the downstream microservice normally, the dynamic route information for the critical resource needs to be temporarily removed from the routing table managed by the gateway. This is because non-query requests may modify the information of the original resource, while the mirror data does not contain corresponding modifications. If the resource information continues to be accessed through dynamic routing, it is very likely that the information will be obtained before the modification.

[0067] In this embodiment, all interface request logs are recorded in the application service gateway. This dynamically identifies frequently accessed or time-consuming key resources in the application system, generates dynamic routing information for these key resources, and constructs a converged microservice to provide access to these resources, thereby improving interface response speed. Furthermore, the dynamic routing information is dynamically deleted upon receiving subsequent non-query requests for these key resources. This allows for dynamic management of routing information in the gateway, reducing errors.

[0068] In some embodiments, the converged microservice cache contains a data mirror of the application system; the method further includes the following steps S260 to S270:

[0069] Step S260: If the access request is a query request for the key resource, the query request is forwarded to the converged microservice through the dynamic routing information;

[0070] Here, when a user requests the dynamic routing information generated by the gateway, the gateway will route the query request to the aggregated microservice, which will then directly query the image data and return the result.

[0071] Step S270: Obtain query results by accessing the data mirror stored in the converged microservice.

[0072] Here, since the underlying data in the data mirror and the original application service is the same, it can be obtained directly.

[0073] In the above embodiments, query requests for key resources are directly forwarded to the generated converged microservices through the dynamic routing information generated by the gateway. Thus, the entire query request only needs one converged microservice to return the results to the user, avoiding the risk of request latency and service crashes caused by accessing multiple microservice modules.

[0074] In some embodiments, the method further includes the following steps: re-determining the key resources at fixed intervals and generating new converged microservices for the key resources.

[0075] Here, the fixed period is an update period set according to the time access situation, so as to realize dynamic management of the dynamic routing information generated in the gateway and the corresponding converged microservices.

[0076] In some embodiments, the interface request log includes at least one of the following: user identifier, standard HTTP request method, URI request path, resource representation of the request, timestamp information of the request arriving at the gateway, and processing time of the request; wherein, the standard HTTP request method includes query method, creation method, deletion method, and modification method; the resource representation of the request is used to characterize the correspondence between resource information in the application system and the request URI. Figure 3 The following is a schematic diagram of an optional flow of the dynamic routing management method provided in the embodiments of this application, such as... Figure 3 As shown, step S120 above, "based on the interface request log, determine the key resources in the application system within a preset time period," may include the following steps S310 to S330:

[0077] Step S310: Based on the URI request path, the timestamp information, and the processing time, determine the access duration of each resource in the application system within the preset time period;

[0078] Step S320: Based on the URI request path, the timestamp information, and the resource representation of the request, determine the number of times each resource is accessed within the preset time period;

[0079] Step S330: The resources with the following access duration and / or the following access frequency as the preset percentage are designated as key resources in the application system.

[0080] In the above embodiments, based on the interface request logs recorded by the gateway, key resources with high access frequency or long processing time in the application system are identified. Then, the microservice modules that provide access to these key resources are integrated, and dynamic routing information is generated in the gateway, so that access requests for these key resources can return results more quickly.

[0081] The above dynamic routing management method will be described below with reference to a specific embodiment. However, it is worth noting that this specific embodiment is only for better illustration of this application and does not constitute an improper limitation of this application.

[0082] This application provides a dynamic routing management method applicable to gateways using RESTful API designs. For application systems using RESTful APIs, various resource information and operations on those resources can be quickly categorized. In a typical microservice system, querying a resource might involve multiple microservices processing the request before returning a result to the user. By logging user operations on all resources in the gateway, resources with frequent queries can be dynamically identified. The microservice modules providing access to these resources can then be integrated, and routing information can be dynamically generated in the gateway. Query requests for these resources can be directly forwarded to the new routing information, accelerating resource access and reducing service unavailability issues caused by downstream microservice crashes.

[0083] First, the interface adopts a RESTful design, requiring the identification of key resource information and their main attributes within the application. The API interface primarily performs various operations on the application's resources, using standard HTTP request methods to represent these operations. Specifically: the GET method queries the server-side resource object, supporting queries on specific resource attributes; the POST method creates a new resource object on the server; the DELETE method deletes a resource object on the server; and the PUT method modifies an existing resource object on the server.

[0084] For example, in a common library management system, the main resource is the book class. The main attributes of this resource include title, author, and price. The RESTful interface of this system can be designed as follows:

[0085] GET / api / book?author=zhangsan This command retrieves information about books authored by zhangsan.

[0086] POST / api / book (with book information in the HTTP body) creates a new book.

[0087] DELETE / api / book?name=bookname deletes the information for the book whose name is "bookname".

[0088] The command `PUT / api / book?name=bookname` modifies the information of a book whose title is `bookname`.

[0089] Similar scenarios include the Item class in a warehouse management system and the Person class in a human resources management system.

[0090] A gateway is the entry point for an application system. Once a request reaches the gateway, it is forwarded to the downstream microservice module for processing via the routing information configured within the gateway. Because all requests pass through the gateway, it is well-suited for logging API request requests. The content recorded in the API request log mainly includes:

[0091] 1) User identification: For interfaces that require login access, user-related information can be recorded in the gateway; for interfaces that do not require login access, anonymous user identification can be recorded uniformly.

[0092] 2) Standard HTTP request methods, including GET, POST, PUT, DELETE, etc.

[0093] 3) URI request path: Records the URI path for each request.

[0094] 4) Resource representation: Prepare the mapping between resource information in the system and request URIs in advance. Note that multiple URIs may correspond to the same resource information. For example, in the example scenario above, there are four listed request URIs for the book class resource. Similar mappings exist for other resource information in the system.

[0095] 5) Request the timestamp information of arrival at the gateway.

[0096] 6) The time spent processing each request is the time consumed.

[0097] Figure 4 This is a schematic diagram of the system framework of the dynamic routing management method provided in the embodiments of this application, such as... Figure 4 As shown, gateway 41 is the request entry point for an application system. After a request reaches gateway 41, it is forwarded to multiple downstream microservices 42 through the routing information configured in the gateway to handle the specific request, such as database storage, Elasticsearch storage, and object storage. The dynamic routing management module 43 manages the dynamic routes in gateway 41 based on the interface request logs recorded by gateway 41.

[0098] When accessing a resource in the system, it often requires the cooperation of multiple microservices to return a result. This process, which previously required accessing multiple microservices to obtain a result, is now handled by a newly generated, integrated microservice 44. This integrated microservice 44 is configured with a unified resource query code template and caches a copy of the original application system's mirror data 45. When a user request arrives at the dynamically generated routing information on the gateway 41, the gateway 41 routes the request to the integrated microservice 44 to access the mirror data 45, which has the same underlying data as the original application service. In other words, this embodiment only requires a single integrated microservice 44 to return the result to the user, avoiding the request latency and service crash risks associated with accessing multiple microservice modules.

[0099] The dynamic routing management module 43 manages dynamic routes in the gateway based on the interface request logs recorded by the gateway. Assume there are n types of predefined resources in the application (this depends on the business system itself; list all resource types related to the business system), denoted as R1, R2, ..., R... n Two strategies can be designed as follows: In some implementations, the resource categories with the highest number of accesses in the past hour are identified, and query requests for these resources are dynamically routed in the gateway, eliminating the need to access the original microservices to obtain results. In other implementations, the resource categories with the lowest access times in the past hour are identified, and these time-consuming requests are added to the gateway's dynamic routes to reduce request response time.

[0100] For non-query requests (POST, PUT, and DELETE requests), such as a POST request to create new resource information, this request will not only pass through gateway 41 to the downstream microservice normally, but will also be sent to the dynamic routing management module 43. Upon receiving a non-query request for a resource, the dynamic routing management module 43 will temporarily remove the route information for that resource from the routing table. This is because non-query requests may modify resource information, and if the mirror data 45 does not contain corresponding modifications, continuing to access resource information through dynamic routing might result in receiving the information before the modification.

[0101] Accessing a resource in a system often requires the collaboration of multiple microservices to return a result. The concept of converged microservices is to automate the process of accessing multiple microservices to obtain a result by automatically generating a new microservice. This converged microservice is configured with a unified resource query code template and caches a data mirror from the original system. The detailed process of generating the converged microservice is described below:

[0102] Step 1: Use the resource query code template (which mainly provides the GET request method for resources) to generate code modules for key resources, and configure the data source as a mirror data source.

[0103] Step 2: Using an automated deployment platform, create a merged microservice in the system that is the code module generated in Step 1. This merged microservice mainly provides GET requests to key resources.

[0104] Step 3: The dynamic routing management module adds the routing information of the microservices generated in step 2 to the gateway, so that GET requests for specific resources will be directly routed to the newly generated microservices.

[0105] When a user requests a dynamically generated route from the gateway, the gateway routes the request to an automatically generated converged microservice. This converged microservice directly queries the mirrored data and returns the result. The entire request only requires a single converged microservice to return the result to the user, avoiding the request latency and service crash risks associated with accessing multiple microservice modules.

[0106] This application embodiment records all interface request logs in the service gateway, dynamically identifies frequently accessed system resources as key resources, merges the relevant microservice modules to construct a new merged microservice module, and dynamically adds access routing information to the gateway for accessing the merged microservice module. Subsequent requests that need to access this key resource are directly routed to the merged microservice module, quickly responding to interface requests. Furthermore, due to the shortened request path, the probability of microservice module failure is reduced, improving system stability.

[0107] Simultaneously, the integrated microservices are dynamically managed, allowing for the dynamic addition and deletion of integrated microservice modules. Since frequently accessed resource information in the application system is not static, this management service needs to dynamically update the integrated microservices, employing appropriate strategies for addition and deletion.

[0108] The embodiments of this application have at least the following technical advantages:

[0109] On the one hand, for API interfaces designed in a RESTful style, by pre-determining the resource information defined in the system and recording the request details of the interface, the dynamic routing management module can dynamically add routing information to the gateway, so that requests for key resources can return results more quickly.

[0110] On the other hand, after adding dynamic routing for key resources, a microservice module for resource access also needs to be automatically generated. This microservice module is mainly used to access the key resources added to the dynamic routing, and at the same time, it saves a mirror data that is the same as the underlying data in the original service. Requests that originally required accessing multiple microservices to get the result can now be directly routed to the merged microservice module through dynamic routing, thereby accessing the mirror data and then returning it to the user.

[0111] Based on the foregoing embodiments, this application provides a dynamic routing management device, which includes the included modules, as well as the sub-modules and units included in each module. It can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0112] Figure 5 This is a schematic diagram of the composition structure of a dynamic routing management device provided in an embodiment of this application, as shown below. Figure 5 As shown, the dynamic routing management device 500 includes: a log acquisition module 510 and a routing management module 520, wherein:

[0113] The log acquisition module 510 is used to acquire the interface request logs recorded by the gateway in response to receiving a user's access request; wherein, the interface request logs are used to characterize the user's request operation information for all resources in the application system; the request operation information is a standard HTTP request method;

[0114] The resource filtering module 520 is used to identify key resources in the application system within a preset time period; the processing priority of the key resources is higher than that of other resources in the application system.

[0115] The routing management module 530 dynamically manages the routing information in the gateway according to a preset management strategy; the gateway includes at least dynamic routing information generated to provide access to the key resources.

[0116] In some possible embodiments, the routing management module 530 includes a generation submodule and a route addition submodule; wherein, the generation submodule is used to generate a converged microservice that provides access to the key resource when the access request is a query request for the key resource; the converged microservice includes at least the query code of at least one microservice in the application system that provides services for the key resource; the route addition submodule is used to add dynamic routing information of the converged microservice to the gateway.

[0117] In some possible embodiments, the routing management module 530 further includes a route deletion submodule, used to delete the dynamic routing information in the gateway when the access request is a non-query request for the key resource.

[0118] In some possible embodiments, the interface request log includes at least one of the following information: user identifier, standard HTTP request method, URI request path, requested resource representation, timestamp information of the request arriving at the gateway, and processing time of the request; wherein, the standard HTTP request method includes query method, creation method, deletion method, and modification method; the requested resource representation is used to characterize the correspondence between resource information in the application system and the request URI; the resource filtering module 520 includes a first determining unit, a second determining unit, and a third determining unit, wherein: the first determining unit is used to determine the access duration of each resource in the application system within the preset time period based on the URI request path, the timestamp information, and the processing time; the second determining unit is used to determine the number of times each resource is accessed within the preset time period according to the URI request path, the timestamp information, and the requested resource representation; the third determining unit is used to select resources with a preset percentage of later access duration and / or a preset percentage of earlier access counts as key resources in the application system.

[0119] In some possible embodiments, the generation submodule includes a generation unit and a creation unit, wherein: the generation unit is used to generate a code module for the key resource using a resource query code template when the access request is a query request for the key resource; the creation unit is used to create the integrated microservice corresponding to the code module in the application system through an automated publishing platform.

[0120] In some possible embodiments, the converged microservice caches the data mirror of the application system; the routing management module further includes a forwarding submodule and a query submodule; wherein, the forwarding submodule is used to forward the query request to the converged microservice through the dynamic routing information when the access request is a query request for the key resource; the query submodule is used to obtain query results by accessing the data mirror stored in the converged microservice.

[0121] In some possible embodiments, the routing management module further includes an update submodule for re-determining the key resources at fixed intervals and generating new converged microservices for the key resources.

[0122] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this disclosure can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0123] It should be noted that, in the embodiments of this application, if the above-described dynamic routing management method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0124] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0125] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0126] This application provides a computer program including computer-readable code, wherein when the computer-readable code is run in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0127] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0128] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0129] It should be noted that, Figure 6 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 6 As shown, the hardware entity of the computer device 600 includes: a processor 601, a communication interface 602, and a memory 603, wherein:

[0130] Processor 601 typically controls the overall operation of computer device 600.

[0131] Communication interface 602 enables computer devices to communicate with other terminals or servers via a network.

[0132] The memory 603 is configured to store instructions and applications executable by the processor 601, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 601 and various modules in the computer device 600. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 601, the communication interface 602, and the memory 603 can be performed via bus 604.

[0133] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

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

[0135] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0136] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0137] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0138] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0139] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0140] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A dynamic routing management method, characterized in that, The method, applied to a gateway in an application system, includes: In response to receiving a user's access request, the interface request log recorded by the gateway is obtained; wherein, the interface request log is used to characterize the user's request operation information for all resources in the application system; the request operation information is the standard Hypertext Transfer Protocol (HTTP) request method; Based on the interface request logs, key resources in the application system are identified within a preset time period; the processing priority of these key resources is higher than that of other resources in the application system. The routing information in the gateway is dynamically managed according to a preset management strategy; the gateway includes at least dynamic routing information generated to provide access to the key resources. The dynamic management of routing information in the gateway according to a preset management strategy includes: When the access request is a query request for the key resource, a converged microservice is generated to provide access to the key resource; the converged microservice includes at least the query code of at least one microservice in the application system that provides services for the key resource; the converged microservice caches the data mirror of the application system; Add dynamic routing information for the converged microservice to the gateway; The method further includes: If the access request is a query request for the key resource, the query request is forwarded to the converged microservice through the dynamic routing information; The query results are obtained by accessing the data mirror stored in the converged microservice.

2. The method according to claim 1, characterized in that, The interface request log includes at least the following information: user identifier, standard HTTP request method, Uniform Resource Identifier (URI) request path, requested resource representation, timestamp information of the request arriving at the gateway, and processing time of the request; wherein, the standard HTTP request method includes query method, creation method, deletion method, and modification method; the requested resource representation is used to characterize the correspondence between resource information in the application system and the request URI; The step of determining key resources in the application system within a preset time period based on the interface request logs includes: Based on the URI request path, the timestamp information, and the processing time, the access duration of each resource in the application system within the preset time period is determined. Based on the URI request path, the timestamp information, and the resource representation of the request, determine the number of times each resource is accessed within the preset time period; The resources that account for a predetermined percentage of the access duration and / or a predetermined percentage of the access frequency are designated as key resources in the application system.

3. The method according to claim 2, characterized in that, The dynamic management of routing information in the gateway according to a preset management strategy further includes: If the access request is a non-query request for the key resource, the dynamic routing information is deleted from the gateway.

4. The method according to claim 2, characterized in that, When the access request is a query request for the key resource, the process of generating a converged microservice to provide access to the key resource includes: When the access request is a query request for the key resource, a code module for the key resource is generated using the resource query code template; The automated deployment platform creates the integrated microservices corresponding to the code modules in the application system.

5. The method according to any one of claims 2 to 4, characterized in that, The method further includes: The key resources are redefined at fixed intervals, and new integrated microservices for the key resources are generated.

6. A dynamic routing management device, characterized in that, A gateway for an application system, the device comprising: The log acquisition module is used to acquire the interface request logs recorded by the gateway in response to receiving a user's access request; wherein, the interface request logs are used to characterize the user's request operation information for all resources in the application system; the request operation information is a standard HTTP request method; The resource filtering module is used to identify key resources in the application system within a preset time period; the processing priority of the key resources is higher than that of other resources in the application system. The routing management module dynamically manages the routing information in the gateway according to a preset management strategy. The gateway includes at least dynamic routing information generated to provide access to the key resource. The dynamic management of the routing information in the gateway according to the preset management strategy includes: generating a converged microservice to provide access to the key resource when the access request is a query request for the key resource; the converged microservice includes at least query code for at least one microservice in the application system that provides services for the key resource; the converged microservice caches the data mirror of the application system; adding dynamic routing information of the converged microservice to the gateway; and forwarding the query request to the converged microservice through the dynamic routing information when the access request is a query request for the key resource; and obtaining the query result by accessing the data mirror stored in the converged microservice.

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

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

Images