Request processing method, apparatus, system, storage medium, and electronic device

Abstract

The present disclosure provides a request processing method, a request processing device, a request processing system, a computer readable storage medium and an electronic device, and belongs to the technical field of computers. The method comprises: receiving an access request sent by a client; in a pre-configured upgrade rule library, searching for an upgrade rule of a target application associated with the access request; matching the access request and the upgrade rule of the target application to determine a target server of the access request, the target server comprising an upgrade server having deployed an upgrade application of the target application and a non-upgrade server not having deployed the upgrade application of the target application; sending the access request to the target server and processing the access request through the target server. The present disclosure can improve the stability of micro-service application running and simplify the upgrade process of micro-service application.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a request processing method, a request processing device, a request processing system, a computer-readable storage medium, and an electronic device. Background Art

[0002] With the advancement of computer technology, microservices architecture, a service-oriented software development technique, has gained widespread adoption due to its advantages such as high development efficiency and strong scalability. Each service developed using a microservices architecture has its own processing and lightweight communication mechanisms and can be deployed on a single or multiple servers.

[0003] To optimize service processing capabilities and enhance the user experience, microservice applications often need to be upgraded. However, traditional upgrade methods require stopping services for updates, which directly impacts user experience, preventing access requests from being processed properly and resulting in a poor user experience.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute prior art known to ordinary technicians in the field. Summary of the Invention

[0005] The present disclosure provides a request processing method, a request processing device, a request processing system, a computer-readable storage medium, and an electronic device, thereby at least to a certain extent improving the problem in the prior art of being unable to properly process access requests during microservice application upgrades.

[0006] Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by practice of the present disclosure.

[0007] According to a first aspect of the present disclosure, a request processing method is provided, the method comprising: receiving an access request sent by a client; searching for an upgrade rule of a target application associated with the access request in a preconfigured upgrade rule library; matching the access request with the upgrade rule of the target application to determine a target server for the access request, the target server comprising an upgraded server on which the upgraded application of the target application has been deployed and a non-upgraded server on which the upgraded application of the target application has not been deployed; sending the access request to the target server, and processing the access request through the target server.

[0008] In an exemplary embodiment of the present disclosure, after receiving an access request sent by a client, the method further includes: searching for an upgrade rule of a target application associated with the access request from any one or more upgrade rules in the upgrade rule library cached by a distributed configuration center.

[0009] In an exemplary embodiment of the present disclosure, when searching for an upgrade rule of a target application associated with the access request, the method further includes: if no upgrade rule of the target application is found, determining that the target server of the access request is the non-upgraded server.

[0010] In an exemplary embodiment of the present disclosure, matching the access request with the upgrade rules of the target application to determine the target server of the access request includes: parsing request parameters of the access request and determining whether the request parameters match the upgrade rules; when it is determined that the request parameters match the upgrade rules of the target application, determining that the target server of the access request is the upgraded server; and when it is determined that the request parameters do not match the upgrade rules of the target application, determining that the target server of the access request is the non-upgraded server.

[0011] In an exemplary embodiment of the present disclosure, the access request includes an HTTP request. After determining that the target server of the access request is the upgrade server, the method further includes: sending the HTTP request to the upgrade server according to the domain name of the upgrade server.

[0012] In an exemplary embodiment of the present disclosure, the access request API gateway request, after determining that the target server of the access request is the upgrade server, the method further includes: sending the API gateway request to the upgrade server according to the group name of the upgrade server, where the group name is the unique identifier of the upgrade server.

[0013] In an exemplary embodiment of the present disclosure, when processing the access request through the target server, the method further includes: when an exception occurs when processing the access request through the upgraded server, sending the access request to the non-upgraded server; and processing the access request through the non-upgraded server.

[0014] According to a second aspect of the present disclosure, a request processing device is provided, which is applied to a request processing system, and the device includes: a receiving module for receiving an access request sent by a client; a searching module for searching for an upgrade rule of a target application associated with the access request in a preconfigured upgrade rule library; a matching module for matching the access request with the upgrade rule of the target application to determine a target server for the access request, wherein the target server includes an upgraded server for an upgraded application where the upgraded target application has been deployed and a non-upgraded server for an upgraded application where the upgraded target application has not been deployed; a sending module for sending the access request to the target server and processing the access request through the target server.

[0015] In an exemplary embodiment of the present disclosure, after receiving an access request sent by a client, the device is further configured to search for an upgrade rule of a target application associated with the access request from any one or more upgrade rules in the upgrade rule library cached by a distributed configuration center.

[0016] In an exemplary embodiment of the present disclosure, when searching for an upgrade rule of a target application associated with the access request, the apparatus is further configured to determine that the target server of the access request is the non-upgraded server if no upgrade rule of the target application is found.

[0017] In an exemplary embodiment of the present disclosure, the matching module is used to parse the request parameters of the access request and determine whether the request parameters match the upgrade rules. When it is determined that the request parameters match the upgrade rules of the target application, the target server of the access request is determined to be the upgraded server; and when it is determined that the request parameters do not match the upgrade rules of the target application, the target server of the access request is determined to be the non-upgraded server.

[0018] In an exemplary embodiment of the present disclosure, the access request includes an Http request. After determining that the target server of the access request is the upgrade server, the sending module is further configured to send the Http request to the upgrade server according to the domain name of the upgrade server.

[0019] In an exemplary embodiment of the present disclosure, the access request API gateway request, after determining that the target server of the access request is the upgrade server, the sending module is also used to send the API gateway request to the upgrade server according to the group name of the upgrade server, and the group name is the unique identifier of the upgrade server.

[0020] In an exemplary embodiment of the present disclosure, when the access request is processed by the target server, the sending module is further used to send the access request to the non-upgraded server when an exception occurs in processing the access request by the upgraded server, and process the access request by the non-upgraded server.

[0021] According to a third aspect of the present disclosure, a request processing system is provided, the system comprising: a client, for generating an access request and sending the access request to a server; a server, the server comprising: a receiving unit, for receiving the access request sent by the client; a rule management unit, for storing upgrade rules in a pre-configured upgrade rule library; a matching unit, for searching the upgrade rule of a target application associated with the access request in the upgrade rule library, and matching the access request with the upgrade rule of the target application to determine a target server for the access request, the target server comprising an upgraded server on which the upgraded application of the target application has been deployed and a non-upgraded server on which the upgraded application of the target application has not been deployed; and a target server, for processing the access request.

[0022] In an exemplary embodiment of the present disclosure, the rule management unit includes: a configuration management unit, which is used to store the upgrade rules in the upgrade rule library; and a distributed configuration center, which is used to cache any one or more upgrade rules in the upgrade rule library when publishing the any one or more upgrade rules, so that the matching unit can search for the upgrade rules of the target application associated with the access request according to the any one or more upgrade rules.

[0023] In an exemplary embodiment of the present disclosure, the access request includes an Http request, and the matching unit includes: an interceptor, which is used to search the upgrade rule of the target application associated with the Http request in the upgrade rule library, and match the Http request and the upgrade rule to determine the target server of the Http request.

[0024] In an exemplary embodiment of the present disclosure, the access request includes an API gateway request, and the matching unit includes: a filter for searching the upgrade rules of the target application associated with the API gateway request in the upgrade rule library, and matching the API gateway request and the upgrade rules to determine the target server of the API gateway request.

[0025] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, any one of the above-mentioned request processing methods is implemented.

[0026] According to a fifth aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute any one of the above-mentioned request processing methods by executing the executable instructions.

[0027] The present disclosure has the following beneficial effects:

[0028] According to the request processing method, request processing apparatus, request processing system, computer-readable storage medium, and electronic device in this exemplary embodiment, upon receiving an access request from a client, the upgrade rule of the target application associated with the access request can be searched in a pre-configured upgrade rule library, and by matching the access request with the upgrade rule of the target application, the target server of the access request can be determined, thereby sending the access request to the target server to process the access request through the target server, wherein the target server includes an upgrade server for an upgraded application that has deployed the target application and a non-upgraded server for an upgraded application that has not deployed the target application. On the one hand, by determining the target server of the access request, the access request can be sent to the corresponding server, such as the upgraded server or the non-upgraded server, without affecting the normal operation of the user during the application upgrade, avoiding the possibility of rollback or retesting and online when problems arise in the application upgrade and online, thereby improving the operational stability of the application; on the other hand, by pre-configuring the upgrade rules, the application upgrade process can be simplified, and the operator can choose the application upgrade time by himself, thereby improving the efficiency and flexibility of the application upgrade.

[0029] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification, serve to explain the principles of the present disclosure. Obviously, the drawings described below are only some embodiments of the present disclosure, and it is possible for a person skilled in the art to derive other drawings based on these drawings without inventive effort.

[0031] Figure 1 An architectural diagram illustrating a request processing system used in this exemplary embodiment;

[0032] Figure 2 A schematic diagram of an interface of a configuration management unit in this exemplary embodiment is shown;

[0033] Figure 3 A schematic diagram illustrating the release of an upgrade rule in this exemplary embodiment is shown;

[0034] Figure 4 An architectural diagram illustrating another request processing system used in this exemplary embodiment;

[0035] Figure 5 A flowchart showing a request processing method in this exemplary embodiment is shown;

[0036] Figure 6A sub-flowchart showing a request processing method in this exemplary embodiment;

[0037] Figure 7 A flowchart showing another request processing method in this exemplary embodiment;

[0038] Figure 8 A structural block diagram of a request processing device according to this exemplary embodiment is shown;

[0039] Figure 9 A computer-readable storage medium for implementing the above method in this exemplary embodiment is shown;

[0040] Figure 10 An electronic device for implementing the above method in this exemplary embodiment is shown. DETAILED DESCRIPTION

[0041] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0042] Figure 1 A schematic diagram showing an exemplary system architecture to which the technical solutions in the exemplary embodiments of the present disclosure can be applied is shown.

[0043] like Figure 1As shown, the request processing system 100 may include a client 110 and a server 120, wherein the server 120 includes a receiving unit 121, a rule management unit 122, a matching unit 123, and a target server 124. The client 110 is a terminal device used by a user initiating an access request, such as a computer or mobile phone. The client 110 can connect to the server 120 via a network 130 and send an access request to the server 120. The server 120 can be configured to receive and process the access request sent by the client. Specifically, in the server 120, the receiving unit 121 can be configured to receive the access request from the client, the rule management unit 122 can be configured to store all upgrade rules in a pre-configured upgrade rule library, and the matching unit 123 can be configured to search the upgrade rule library for the target application associated with the access request and match the access request with the upgrade rules of the target application to determine the target server for the access request. The target server 124 is a backend server configured to process the access request. In this exemplary embodiment, the target server 124 may include an upgraded server on which the upgraded application of the target application has been deployed and a non-upgraded server on which the upgraded application of the target application has not been deployed, wherein the target application is a microservice application associated with the client's access request. Compared with the target application, the upgraded application may be a more complete software, for example, it may be an application that fixes some vulnerabilities in the target application, or it may be an application that adds new functions.

[0044] It should be understood that Figure 1 The number of clients and servers, such as receiving units, rule management units, matching units, and target servers, is merely illustrative. Any number of clients and servers may be used as needed. For example, the target server in the server may be a server cluster consisting of multiple servers.

[0045] In an optional embodiment, the rule management unit 122 may include a configuration management unit and a distributed configuration center. The configuration management unit is a program environment that provides rule configuration and storage services, and can be used to store upgrade rules in a pre-configured upgrade rule base; the distributed configuration center can be a distributed system that supports multiple environments (or multiple groups), and can be used to cache any one or more upgrade rules in the upgrade rule base when publishing any one or more upgrade rules, so that the matching unit can search for the upgrade rules of the target application associated with the access request according to any one or more upgrade rules. For example, refer to Figure 2 As shown, users can Figure 2Configure the upgrade rules for each microservice application in the configuration management unit interface shown. After completing the configuration, you can select the upgrade rule publishing function in the configuration management unit interface to complete the one-click publishing of the upgrade rules. At the same time, you can generate a URL (Uniform Resource Locator) based on the system information and system key of the business system that needs to be upgraded in the upgrade rule, as well as the domain name of the distributed configuration center and the namespace it creates. Then, encapsulate the request parameters through the put method in the Http protocol (Hyper Text Transfer Protocol) to execute a push request, and push the upgrade rules to the distributed configuration center, so that the matching unit can directly search for the upgrade rules of the target application associated with the access request from the distributed configuration center.

[0046] By caching the published upgrade rules in the distributed configuration center, the speed of determining the upgrade rules of the target application can be improved, thereby improving the processing efficiency of access requests; at the same time, since users can pre-configure upgrade rules in the configuration management platform and choose the appropriate time to publish the upgrade rules, the preparation work and publication work before the application upgrade are independent of each other, and operators can choose to upgrade the application at any time, thus improving the flexibility and convenience of application upgrades.

[0047] For further reference, Figure 3 As shown, according to the content of the data stored in the configuration management unit and the functions of each module, the configuration management unit may include a system management subunit, a rule management subunit, and an upgrade rule publishing subunit. Among them, the system management subunit may store the system information of one or more business systems in the microservice application to be upgraded, such as the system number, system name, system person in charge, operator and operation time, current version number and other attribute information; the rule management subunit may store the upgrade rules, which may be specifically set according to the business content of the microservice application; the upgrade rule publishing subunit may be used to publish the system information and rule information of the business system to be upgraded, for example, it may include the task name of the upgrade task released this time, the system information of the business system to be upgraded and its corresponding upgrade rule information. When publishing the upgrade rules, the system information and rule information of the business system to be upgraded may be pushed to the distributed configuration center through an Http request through the upgrade rule publishing subunit.

[0048] In an optional embodiment, the client's access request may include an HTTP request, i.e., an access request initiated by an application installed on the client. In this case, the matching unit may include an interceptor for searching an upgrade rule library for the target application associated with the HTTP request, matching the HTTP request with the upgrade rule, and determining the target server for the HTTP request. In this exemplary embodiment, the interceptor may be generated using Struts2 (a web application framework based on the MVC design pattern) and may intercept an object before or after an action is executed.

[0049] In an optional embodiment, the client's access request may also be an API gateway request, i.e., an access request received through a unified entry point at the system boundary that provides external access to internal interface services. In this case, the matching unit may include a filter for searching the upgrade rule library for the target application associated with the API gateway request, matching the API gateway request with the upgrade rule, and determining the target server for the API gateway request.

[0050] Figure 4 A schematic diagram of another request processing system in this exemplary embodiment is shown. As shown in the figure, the request processing system 100 may include: a client 110, a server 120, and a domain name resolution node 140. The client 110 can be used to send an access request to the server 120, and the domain name resolution node 140 can be used to send the access request to the server 120 based on information such as the domain name of the access request. The server 120 can be used to receive and process the access request. As shown in the figure, the server 120 may also include: a virtual IP address node 410, a first gateway node 420, a filter 430, an upgraded server 440, a non-upgraded server 450, a reverse proxy server 460, a second gateway node 470, and an interceptor 480. Among them, the virtual IP address node 410 can send the access request to the corresponding node according to the type of access request, such as Http request or API gateway request; the first gateway node 420 and the second gateway node 470 can be used to forward the access request to the corresponding matching unit according to the corresponding request type, such as a filter or interceptor; the filter 430 can be used to determine whether the received API gateway request matches the upgrade rule of the target application, and determine the target server of the API gateway request; the reverse proxy server 460 can be an Nginx proxy server (a high-performance Http server / reverse proxy server and email proxy server), which can be used to forward the access request; the interceptor 480 can be used to determine whether the received Http request matches the upgrade rule of the target application, and determine the target server of the Http request.

[0051] When the client 120 sends an access request to the server 120, the domain name resolution node 410 can resolve the access request, determine the target address of the access request, and transmit the access request to the server 120 via the network. The virtual IP address node 410 can send the API gateway request to the first gateway node 430 and the HTTP request to the reverse proxy server 460 according to the type of access request, and perform the following processing:

[0052] After the first gateway node 420 receives the API gateway request, the API gateway request can be sent to the filter 430, so that the filter 430 determines whether the API gateway request matches the upgrade rules of the target application, and when it is determined that the API gateway request matches the upgrade rules of the target application, the API gateway request is sent to the upgrade server 440 for processing. When it is determined that the API gateway request does not match the upgrade rules of the target application, the API gateway request is sent to the non-upgraded server 450 for processing.

[0053] After receiving the Http request, reverse proxy server 460 can determine the server with the lower current load based on the load status of the upgraded server and the non-upgraded server, and send the Http request to second gateway node 470 corresponding to the server with the lower load. Second gateway node 470 can send the received Http request to interceptor 480, which determines whether the Http request matches the upgrade rules of the target application. If it is determined that the Http request matches the upgrade rules of the target application, interceptor 480 sends the Http request to upgraded server 440 for processing. If it is determined that the Http request does not match the upgrade rules of the target application, interceptor 480 sends the Http request to non-upgraded server 450 for processing.

[0054] Through the above-mentioned request processing system, when the receiving unit receives an access request, the target server of the access request, such as the upgraded server and the non-upgraded server, can be determined through the matching unit, so as to process the above-mentioned access request through the target server, thereby realizing flexible deployment of application upgrades, and maintaining normal use of the application during the application upgrade process.

[0055] With the increasing number of business scenarios, it's sometimes necessary to upgrade the same microservice application according to different rules. For example, based on the region of the accessing user, an application upgrade might be performed first for users in a specific area, followed by a full upgrade for all other users, effectively upgrading the microservice application for all users. Traditionally, upgrade rules can be configured within the existing business logic code to perform application upgrades. However, this approach still involves service downtime, impacting user experience. Furthermore, since the existing code logic is altered, each code modification during testing requires testing the correctness of the entire code logic, resulting in low upgrade efficiency and high maintenance costs.

[0056] In view of one or more of the aforementioned problems, exemplary embodiments of the present disclosure further provide a request processing method applied to a request processing system. Figure 5 A process of the request processing method is shown, which may include the following steps S510 to S540:

[0057] Step S510: receiving an access request sent by a client.

[0058] Among them, an access request can be a request sent by a user through a client to obtain certain business content. The access request can include multiple types according to the business content. For example, an access request can be a request for a user to access a certain resource, or it can be a request for a specific business application made by a user using an application, such as a request for the publication and use of network resources.

[0059] When a user initiates an access request through a client, the server can receive the access request, parse the access request, obtain the message data in the access request, and determine the information of the client initiating the request and the resource information requested by the client based on the message data.

[0060] Step S520: Searching for an upgrade rule of the target application associated with the access request in a pre-configured upgrade rule library.

[0061] The upgrade rule library can be a rule database that stores operator-preconfigured upgrade rules for each microservice application. Each microservice application can include multiple business systems, each of which can be used to perform specific tasks. For example, a microservice application can include a query business system, a business processing system, a customer service system, and so on. In this case, the upgrade rules for each microservice application can also include upgrade rules for one or more business systems. The target application can be the microservice application requested by the client.

[0062] By searching the preconfigured upgrade rule library for the target application associated with the access request and its upgrade rules, it is possible to predetermine whether the target application has undergone a version update. Furthermore, compared to the existing method of modifying business logic code to upgrade applications, configuring upgrade rules simplifies the application upgrade process, avoiding the need for rollbacks or retesting and re-launching when issues arise during the application upgrade, thereby improving application upgrade efficiency. Furthermore, since all upgrade rules for microservice applications are centrally stored in the upgrade rule library, unified management and maintenance of all upgrade rules is possible, further improving application upgrade efficiency.

[0063] In an optional embodiment, after receiving an access request from a client, the upgrade rule for the target application associated with the access request can be searched from any one or more upgrade rules in the upgrade rule library cached by the distributed configuration center. By obtaining the upgrade rules for the target application from the distributed configuration center, the efficiency of obtaining upgrade rules can be improved.

[0064] Step S530: Match the access request with the upgrade rule of the target application to determine the target server of the access request.

[0065] The target servers can include upgraded servers that have the upgraded application of the target application deployed, and non-upgraded servers that have not yet deployed the upgraded application of the target application. Both upgraded and non-upgraded servers are components of the microservice application server and can be used to process client access requests. The difference is that upgraded servers can process access requests through the upgraded application, while non-upgraded servers can only process access requests through the target application, that is, the non-upgraded application.

[0066] After obtaining the upgrade rules of the target application, the access request and the upgrade rules of the target application can be matched to determine whether the two match, and the target server of the access request can be determined based on the result of the judgment. For example, the request address of the access request can be used to determine whether the address matches the address information in the upgrade rule. When a match is determined, the target server of the access request is determined to be an upgraded server. Otherwise, the target server of the access request is determined to be a non-upgraded server. It should be noted that, according to business needs, the upgrade of the target application can include a variety of upgrade strategies, such as a local upgrade for users in a region, or an upgrade for a specific resource type. Therefore, whether the access request matches the upgrade rules of the target application can also be achieved based on whether the address of the access request matches the address of the upgrade rule, or based on whether the resource content requested by the access request matches the resource content in the upgrade rule. This exemplary embodiment does not make any special restrictions on this.

[0067] In an optional embodiment, referring to Figure 6 As shown, step S530 can be implemented by following the steps S610 to S630:

[0068] Step S610 parses the request parameters of the access request and determines whether the request parameters match the escalation rules. The request parameters may be key information in the access request used to identify the target server. Depending on the specific content of the escalation rules, the parameter information may vary. For example, in escalation rules configured by region, the request parameters may be the address information of the access request.

[0069] By parsing the request parameters of the access request, the request parameters associated with the upgrade rule in the access request can be extracted, and the request parameters are matched with the upgrade rule to obtain a matching result.

[0070] Step S620: When it is determined that the request parameter matches the upgrade rule of the target application, the target server of the access request is determined to be an upgrade server.

[0071] When the request parameters of the access request match the upgrade rules of the target application, it means that the access request meets the configuration requirements of the upgrade rules, and the access request can be processed by the upgraded microservice application. Therefore, it can be determined that the target server of the access request is the upgraded server.

[0072] Step S630: When it is determined that the request parameter does not match the upgrade rule of the target application, it is determined that the target server of the access request is a non-upgraded server.

[0073] When the request parameters of the access request do not match the upgrade rules of the target application, it means that the access request does not meet the configuration requirements of the upgrade rules. Only the microservice application before the upgrade is allowed to process the access request. Therefore, it can be determined that the target server of the access request is a non-upgraded server.

[0074] Through the above steps S610 to S630, it can be determined whether the target server of the access request is an upgraded server or a non-upgraded server based on the access request and the upgrade rules. This not only meets the upgrade requirements of the application, but also meets the normal access of the user, thereby improving the operating stability of the application.

[0075] Depending on the way the client sends the access request, the access request may include any one of an Http request and an API gateway request, and for different types of access requests, the method of determining the target server of the access request may also be different. For example, for the above-mentioned Http request, that is, the access request initiated by the application installed on the client, the upgrade rules of the target application can be read through the distributed configuration center, and the parameter information related to the upgrade rules in each business system of the target application can be obtained, and it can be matched with the request parameters in the Http request to determine the target server of the Http request; for another example, for the above-mentioned API gateway request, that is, the access request received through the unified entrance provided to the external access internal interface service on the system boundary, the remote procedure service call request service can be used to read the upgrade rules of the target application and the parameter information related to the upgrade rules in each business system of the target application from the distributed configuration center, and it can be matched with the request parameters in the API gateway request to determine the target server of the API gateway request.

[0076] Furthermore, in an optional embodiment, after determining that the target server of the HTTP request is the upgrade server, the HTTP request can be sent to the upgrade server based on the domain name of the upgrade server. Specifically, the header information of the HTTP request can be transparently transmitted, and the IP address (Internet Protocol Address) of the HTTP request can be determined by routing, and the HTTP request can be sent to the upgrade server.

[0077] In an optional embodiment, after determining that the target server of the API gateway request is the upgrade server, the API gateway request can be sent to the upgrade server according to the group name of the upgrade server. The group name can be a unique identifier of the upgrade server and can be composed of numbers, characters, etc. For example, the API gateway request can be sent to the upgrade server using a generalized call technology of a specific remote procedure call protocol. Specifically, the generalized call technology of the remote procedure call protocol can include the following process:

[0078] (1) Instantiate the generalized service, create a user configuration object, and set the user configuration object's properties, including the class name, registration configuration information, protocol type, and the group name of the remote procedure call service's upgrade server. The generalized call flag is set to true, and then the user configuration object is called to complete the service instantiation. The upgrade server's group name and the specific type of the remote procedure call service request can form a unique identifier representing a specific remote procedure call service, and this unique identifier can be stored using a hash structure.

[0079] (2) Obtain the requested method name, parameter type, and parameter value from the message object of the remote procedure call service request, pass these parameter information to the instantiated generalized service, and obtain the initial result value of the service response.

[0080] (3) According to the class object name in the user configuration object, use the Class.forName method to load the class object in the user configuration object, initialize this class object, convert the initial result value of the service response into this class object, then convert this class object into an object, and finally return the response result to the requester.

[0081] In an optional embodiment, when searching for the upgrade rules of the target application associated with the above access request, if no upgrade rules are found for the target application, it means that the target application has not been upgraded yet. Therefore, it can be determined that the target server of the access request is a non-upgraded server.

[0082] By determining the target server of the access request, it is possible to distinguish whether the processing server to which the access request applies is an upgraded server or a non-upgraded server, ensuring that users can normally access the target application even when the application is upgraded.

[0083] Step S540: Send the access request to the target server group so that the target server group processes the access request.

[0084] In this exemplary embodiment, the target server may include an upgraded server and a non-upgraded server. Therefore, the access request can be processed by the upgraded server or the non-upgraded server. That is to say, even during the application upgrade process, the client's access request can be received and processed normally, and the stability of the system can be improved.

[0085] In order to improve the access success rate of the client, in an optional implementation, when the target server processes the access request, the following method may also be executed:

[0086] If an exception occurs while processing an access request through the upgraded server, the request is sent to the non-upgraded server, which then handles the request. This allows the non-upgraded server to handle the request even if the upgraded application encounters a problem and can't process the request. This approach allows access requests to be promptly switched to the non-upgraded application if a problem arises after the upgraded application is launched, ensuring normal user access during the application upgrade process.

[0087] Figure 7 The flowchart of another request processing method in this exemplary embodiment is shown, as shown in the figure, which may include the following steps S701 to S711:

[0088] Step S701: During the process of running a target application on the server, an access request sent by a client is received, wherein the target application refers to an application program before being upgraded.

[0089] The server can run the target application by calling the package file of the target application, such as a War package (a file packaged by a JavaScript program), to run the target application.

[0090] In step S702, the server obtains the upgrade rules in the upgrade rule library cached by the distributed configuration center, and searches for the upgrade rules of the target application associated with the access request.

[0091] In step S703, the server determines the type of the access request according to the received access request. For example, the server may determine the source of the access request according to the sending address of the access request, thereby determining the type of the access request.

[0092] In step S704, the server determines that the access request is an HTTP request.

[0093] In step S705 , the server determines that the access request is an API gateway request.

[0094] In step S706, the server determines whether the HTTP request matches the upgrade rule of the target application. If so, step S708 is executed. If not, the access request is sent to the target application, that is, the application before the upgrade, for processing.

[0095] In step S707, the server determines whether the API gateway request matches the upgrade rules of the target application. If so, step S709 is executed. If not, the access request is sent to the target application, that is, the application before the upgrade, for processing.

[0096] Specifically, in step S706 and step S707, the server determines whether the access request matches the upgrade rules of the target application by parsing the request parameters in the access request, such as the address, port number, etc., and matching the request parameters with the upgrade rules of the target application to determine whether the two match.

[0097] In step S708 , the server determines that the target server of the Http request is the upgrade server, and executes step S710 to process the Http request through the upgrade server.

[0098] In step S709 , the server determines that the target server of the API gateway request is the upgrade server, and executes step S711 to process the API gateway request through the upgrade server.

[0099] Step S710: Process the HTTP request through the upgrade server.

[0100] Step S711: Process the API gateway request through the upgrade server.

[0101] After the processing is completed, the upgrade server can send the processing result of the access request, such as the above-mentioned Http request or API gateway request, to the client, so that it can display the corresponding page or perform the corresponding operation according to the processing result.

[0102] In summary, according to the request processing method in this exemplary embodiment, when receiving an access request from a client, the upgrade rule of the target application associated with the access request can be searched in the pre-configured upgrade rule library, and by matching the access request with the upgrade rule of the target application, the target server of the access request can be determined, thereby sending the access request to the target server to process the above access request through the target server, wherein the target server includes an upgrade server for an upgraded application that has deployed the target application and a non-upgraded server for an upgraded application that has not deployed the target application. On the one hand, by determining the target server of the access request, the access request can be sent to the corresponding server, such as an upgraded server or a non-upgraded server, without affecting the normal operation of the user during the application upgrade, avoiding the possibility of rollback or retesting and online when problems arise in the application upgrade and online, thereby improving the operational stability of the application; on the other hand, by pre-configuring the upgrade rules, the application upgrade process can be simplified, and the operator can choose the application upgrade time by himself, thereby improving the efficiency and flexibility of the application upgrade.

[0103] This exemplary embodiment also provides a request processing device, which can be applied to a request processing system. Figure 8 As shown, the request processing device 800 may include: a receiving module 810, which can be used to receive an access request sent by a client; a search module 820, which can be used to search for an upgrade rule of a target application associated with the access request in a pre-configured upgrade rule library; a matching module 830, which can be used to match the access request with the upgrade rule of the target application, and determine the target server of the access request, the target server including an upgraded server of an upgraded application where the upgraded target application has been deployed and a non-upgraded server of an upgraded application where the upgraded target application has not been deployed; a sending module 840, which can be used to send the access request to the target server and process the access request through the target server.

[0104] In an exemplary embodiment of the present disclosure, after receiving an access request sent by a client, the request processing device 800 can also be used to search for an upgrade rule of a target application associated with the access request from any one or more upgrade rules in an upgrade rule library cached by a distributed configuration center.

[0105] In an exemplary embodiment of the present disclosure, when searching for an upgrade rule of a target application associated with an access request, the request processing device 800 may also be configured to determine that the target server of the access request is a non-upgraded server if no upgrade rule of the target application is found.

[0106] In an exemplary embodiment of the present disclosure, the matching module 830 can be used to parse the request parameters of the access request and determine whether the request parameters match the upgrade rules. When it is determined that the request parameters match the upgrade rules of the target application, the target server of the access request is determined to be an upgraded server; and when it is determined that the request parameters do not match the upgrade rules of the target application, the target server of the access request is determined to be a non-upgraded server.

[0107] In an exemplary embodiment of the present disclosure, the access request includes an HTTP request. After determining that the target server of the access request is the upgrade server, the sending module 840 can also be used to send the HTTP request to the upgrade server according to the domain name of the upgrade server.

[0108] In an exemplary embodiment of the present disclosure, an access request is made to an API gateway. After determining that the target server of the access request is an upgrade server, the sending module 840 can also be used to send the API gateway request to the upgrade server according to the group name of the upgrade server, where the group name is a unique identifier of the upgrade server.

[0109] In an exemplary embodiment of the present disclosure, when processing an access request through the target server, the sending module 840 can also be used to send the access request to the non-upgraded server when an exception occurs in processing the access request through the upgraded server, and process the access request through the non-upgraded server.

[0110] The specific details of each module in the above device have been described in detail in the implementation method part. The details of the undisclosed scheme can be found in the implementation method part, so they will not be repeated here.

[0111] Those skilled in the art will appreciate that various aspects of the present disclosure may be implemented as systems, methods, or program products. Therefore, various aspects of the present disclosure may be implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which may be collectively referred to herein as "circuits," "modules," or "systems."

[0112] The exemplary embodiments of the present disclosure further provide a computer-readable storage medium having stored thereon a program product capable of implementing the methods described above in this specification. In some possible implementations, various aspects of the present disclosure may also be implemented in the form of a program product comprising program code that, when executed on a terminal device, causes the terminal device to execute the steps described in the "Exemplary Methods" section above according to various exemplary embodiments of the present disclosure.

[0113] refer to Figure 9 As shown, a program product 900 for implementing the above method according to an exemplary embodiment of the present disclosure is described. The program product 900 may be a portable compact disc read-only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0114] Program product 900 can employ any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0115] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0116] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0117] Program code for performing the operations of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and the like, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a stand-alone software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0118] The exemplary embodiment of the present disclosure also provides an electronic device capable of implementing the above method. Figure 10 1000 according to this exemplary embodiment of the present disclosure will be described. Figure 10 The electronic device 1000 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0119] like Figure 10 As shown, the electronic device 1000 may be implemented as a general-purpose computing device. Components of the electronic device 1000 may include, but are not limited to, the at least one processing unit 1010, the at least one storage unit 1020, a bus 1030 connecting various system components (including the storage unit 1020 and the processing unit 1010), and a display unit 1040.

[0120] The storage unit 1020 stores program codes, which can be executed by the processing unit 1010, so that the processing unit 1010 performs the steps described in the "Exemplary Method" section of this specification according to various exemplary embodiments of the present disclosure. For example, the processing unit 1010 can execute Figures 5 to 7 The method steps shown, etc.

[0121] The storage unit 1020 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 1021 and / or a cache memory unit 1022 , and may further include a read-only memory unit (ROM) 1023 .

[0122] The storage unit 1020 may also include a program / utility 1024 having a set (at least one) of program modules 1025, such program modules 1025 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0123] Bus 1030 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0124] The electronic device 1000 can also communicate with one or more external devices 1100 (e.g., a keyboard, a pointing device, a Bluetooth device, etc.), one or more devices that enable a user to interact with the electronic device 1000, and / or any device that enables the electronic device 1000 to communicate with one or more other computing devices (e.g., a router, a modem, etc.). Such communication can occur via an input / output (I / O) interface 1050. Furthermore, the electronic device 1000 can also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network such as the Internet) via a network adapter 1060. As shown, the network adapter 1060 communicates with other modules of the electronic device 1000 via a bus 1030. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 1000, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0125] It should be noted that although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the exemplary embodiments of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0126] Furthermore, the figures above are merely illustrative of the processes included in the methods according to exemplary embodiments of the present disclosure and are not intended to be limiting. It is readily understood that the processes illustrated in the figures above do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0127] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the exemplary embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the exemplary embodiments of the present disclosure.

[0128] Other embodiments of the present disclosure will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and embodiments are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the claims.

Claims

1. A request processing method, characterized in that: Applied to a request processing system, the method includes: Receive access requests sent by clients; Searching for upgrade rules for the target application associated with the access request in a pre-configured upgrade rule library cached in a distributed configuration center; configuring the upgrade rules in the upgrade rule library to the distributed configuration center in the following manner: generating a uniform resource locator (URL) based on the system information and system key of the business system to be upgraded, the domain name of the distributed configuration center, and the created namespace, and encapsulating request parameters through the put method in the Hypertext Transfer Protocol (Http) and executing a push request to push the upgrade rules to the distributed configuration center; the upgrade rule library includes upgrade rules corresponding to multiple microservice applications, and the upgrade rules of each microservice application include upgrade rules for one or more business systems; matching the access request with the upgrade rules of the target application, and determining a target server for the access request, wherein the target server includes an upgraded server on which the upgraded application of the target application has been deployed and a non-upgraded server on which the upgraded application of the target application has not been deployed; the upgraded server is configured to process access requests that match the upgrade rules of the target application, and the non-upgraded server is configured to process access requests that do not match the upgrade rules of the target application; The access request is sent to the target server, and the access request is processed by the target server.

2. The method according to claim 1, characterized in that When searching for an upgrade rule of a target application associated with the access request, the method further includes: When no upgrade rule for the target application is found, it is determined that the target server of the access request is the non-upgraded server.

3. The method according to claim 1, characterized in that The matching of the access request with the upgrade rule of the target application to determine the target server of the access request includes: parsing request parameters of the access request and determining whether the request parameters match the upgrade rule; When it is determined that the request parameter matches the upgrade rule of the target application, determining that the target server of the access request is the upgrade server; and When it is determined that the request parameter does not match the upgrade rule of the target application, the target server of the access request is determined to be the non-upgraded server.

4. The method according to claim 3, characterized in that The access request includes an HTTP request. After determining that the target server of the access request is the upgrade server, the method further includes: According to the domain name of the upgrade server, the Http request is sent to the upgrade server.

5. The method according to claim 3, characterized in that The access request includes an API gateway request. After determining that the target server of the access request is the upgrade server, the method further includes: The API gateway request is sent to the upgrade server according to the group name of the upgrade server, where the group name is a unique identifier of the upgrade server.

6. The method according to claim 1, characterized in that When processing the access request by the target server, the method further includes: When an exception occurs in processing the access request by the upgraded server, sending the access request to the non-upgraded server; The access request is processed by the non-upgraded server.

7. A request processing device, characterized in that: Applied to a request processing system, the device comprises: A receiving module, configured to receive an access request sent by a client; A search module is configured to search for upgrade rules for a target application associated with the access request in a pre-configured upgrade rule library cached in a distributed configuration center; the upgrade rules in the upgrade rule library are configured to the distributed configuration center in the following manner: based on the system information and system key of the business system to be upgraded, as well as the domain name of the distributed configuration center and the uniform resource locator URL created by the namespace, and encapsulating request parameters through the put method in the Hypertext Transfer Protocol (Http) protocol and executing a push request to push the upgrade rules to the distributed configuration center; the upgrade rule library includes upgrade rules corresponding to multiple microservice applications, and the upgrade rules of each microservice application include upgrade rules for one or more business systems; a matching module configured to match the access request with the upgrade rules of the target application and determine a target server for the access request, wherein the target server includes an upgraded server on which the upgraded application of the target application has been deployed and a non-upgraded server on which the upgraded application of the target application has not been deployed; the upgraded server is configured to process access requests that match the upgrade rules of the target application, and the non-upgraded server is configured to process access requests that do not match the upgrade rules of the target application; The sending module is used to send the access request to the target server, and process the access request through the target server.

8. A request processing system, characterized in that: The system comprises: The client is used to generate an access request and send the access request to the server; The server includes: A receiving unit, configured to receive an access request sent by the client; A rule management unit is configured to store upgrade rules in a pre-configured upgrade rule library cached in a distributed configuration center; the upgrade rules in the upgrade rule library are configured to the distributed configuration center in the following manner: based on the system information and system key of the business system to be upgraded, as well as the domain name of the distributed configuration center and the uniform resource locator URL created by the namespace, and encapsulating request parameters through the put method in the Hypertext Transfer Protocol (Http) protocol and executing a push request to push the upgrade rules to the distributed configuration center; the upgrade rule library includes upgrade rules corresponding to multiple microservice applications, and the upgrade rules of each microservice application include upgrade rules for one or more business systems; a matching unit configured to search the upgrade rule of the target application associated with the access request in the upgrade rule library, and match the access request with the upgrade rule of the target application to determine a target server for the access request, wherein the target server includes an upgraded server on which the upgraded application of the target application has been deployed and a non-upgraded server on which the upgraded application of the target application has not been deployed; the upgraded server is configured to process access requests that match the upgrade rule of the target application, and the non-upgraded server is configured to process access requests that do not match the upgrade rule of the target application; The target server is configured to process the access request.

9. The system according to claim 8, characterized in that The rule management unit includes: A configuration management unit, configured to store the upgrade rules in the upgrade rule library; The distributed configuration center is used to cache any one or more upgrade rules in the upgrade rule library when publishing the any one or more upgrade rules, so that the matching unit can search for the upgrade rules of the target application associated with the access request according to the any one or more upgrade rules.

10. The system according to claim 8, wherein: The access request includes an HTTP request, and the matching unit includes: The interceptor is used to search the upgrade rule of the target application associated with the Http request in the upgrade rule library, and match the Http request with the upgrade rule to determine the target server of the Http request.

11. The system according to claim 8, wherein: The access request includes an API gateway request, and the matching unit includes: The filter is used to search the upgrade rule of the target application associated with the API gateway request in the upgrade rule library, and match the API gateway request with the upgrade rule to determine the target server of the API gateway request.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

13. An electronic device, characterized in that: include: processor; as well as a memory for storing executable instructions of the processor; The processor is configured to perform the method according to any one of claims 1 to 6 by executing the executable instructions.

Images