A Microservice Request Processing Method, Device, and Storage Medium

Abstract

An embodiment of the present application discloses a microservice request processing method, which includes: receiving a service request sent by a client device; parsing the service request to determine n requested services included in the service request; determining the service types of the n requested services to obtain n service types; if the n service types include p first preset types and n - p second preset types, based on the p first preset types, performing conversion processing on the service request to obtain p target requests; sending each of the target requests to a first service device associated with the first preset type; sending the service request to a second service device associated with the second preset type; wherein, the service request is used to enable the second service device to provide corresponding services. An embodiment of the present application also discloses a gateway device and a storage medium.

Description

Technical Field

[0001] This application relates to the field of computer application technologies, and in particular, to a method, device, and storage medium for processing microservice requests. Background Art

[0002] With the rapid development of computer technologies, more and more technologies are applied in the financial field, and traditional finance is gradually transforming into financial technology (Fintech). However, due to the security and real-time requirements of the financial industry, higher requirements are also imposed on technologies. As a cloud-native architecture approach, microservices consist of many loosely coupled and independently deployable smaller components or services, and have been widely used due to advantages such as enabling easy code updates, allowing teams to use different stacks and components for different components, being able to scale independently of each other, and reducing waste and costs caused by having to scale the entire application. Currently, in order to prevent client devices from knowing the existence of multiple microservices on the server side, an Application Programming Interface (API) gateway is set up between the client device and the server device. In this way, after the client device sends a service request to the API gateway, the API gateway looks up the microservice address corresponding to the service request according to user configuration. If matching routing information for the service request is found, after processing such as authenticating and authorizing the request information, the API gateway forwards the service request to the corresponding microservice on the server device according to the matching routing information, so that the server device can provide the service corresponding to the service request for the client device.

[0003] However, currently, since the service requests sent by client devices are based on the HyperText Transfer Protocol (HTTP) or the Hyper Text Transfer Protocol over Secure Socket Layer (HTTPS), when the API gateway forwards service requests, it can only forward them to microservices that provide HTTP / HTTPS access interfaces. Correspondingly, when the microservice provides a service interface based on a non-HTTP / HTTPS protocol, the microservice needs to convert the provided service interface into a service interface in the HTTP / HTTPS protocol format, resulting in low forwarding efficiency of the current API gateway.

[0004] Content of the Application

[0005] To solve the above technical problems, an embodiment of the present application expects to provide a microservice request processing method, device, and storage medium, which solve the problem that the current API gateway cannot send requests including non-HTTP / HTTPS protocols to the corresponding microservices, and implement a technical solution in which the API gateway can directly forward requests with non-HTTP / HTTPS protocols to the corresponding microservices, effectively improving the forwarding efficiency of the API gateway.

[0006] The technical solution of the present application is implemented as follows:

[0007] In a first aspect, a microservice request processing method, the method includes:

[0008] Receiving a service request sent by a client device;

[0009] Parsing the service request to determine n requested services included in the service request; where n is an integer greater than or equal to 1;

[0010] Determining the service types of the n requested services to obtain n service types;

[0011] If the n service types include p first preset types and n - p second preset types, based on the p first preset types, performing conversion processing on the service request to obtain p target requests; where the first preset type is a service type other than the second preset type, p is an integer greater than or equal to 1 and less than n, and the value of n - p is greater than or equal to 1;

[0012] Sending each of the target requests to a first service device associated with the first preset type;

[0013] Sending the service request to a second service device associated with the second preset type; where the service request is used to enable the second service device to provide the corresponding service.

[0014] In a second aspect, a gateway device, the device includes a memory, a processor, and a communication bus; where:

[0015] The memory is used to store executable instructions;

[0016] The communication bus is used to implement a communication connection between the processor and the memory;

[0017] The processor is used to execute the microservice request processing program stored in the memory to implement the steps of the microservice request processing method described in any one of the above.

[0018] In a third aspect, a storage medium stores a microservice request processing program, and when the microservice request processing program is executed by a processor, the steps of the microservice request processing method as described in any one of the above are implemented.

[0019] In the embodiments of the present application, after the gateway device receives a service request sent by a client device, it parses the service request, determines n requested services included in the service request, and determines the service types of the n requested services to obtain n service types. If the n service types include p first preset types and n - p second preset types, based on the p first preset types, the service request is converted to obtain p target requests, and each target request is sent to a first service device associated with the first preset type, and the service request is sent to a second service device associated with the second preset type. In this way, the gateway device determines whether to perform conversion processing on the service request according to the service types of the requested services included in the service request. When it is determined that conversion processing is required for the service request, it is converted into a corresponding target request and forwarded to the corresponding service device. When conversion processing is not required for the service request, the service request is directly forwarded to the corresponding service device, solving the problem that the current API gateway cannot provide service interfaces for non-HTTP / HTTPS protocols to directly conduct business with microservices using non-HTTP / HTTPS protocols, resulting in low forwarding efficiency, and implementing the technical solution that the API gateway can directly forward requests for non-HTTP / HTTPS protocols to the corresponding microservices, effectively improving the forwarding efficiency of the API gateway and enriching the functions of the API gateway. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a flowchart of a microservice request processing method provided by an embodiment of the present application;

[0021] Figure 2 It is a flowchart of another microservice request processing method provided by an embodiment of the present application;

[0022] Figure 3 It is a schematic structural diagram of a microservice architecture provided by an embodiment of the present application;

[0023] Figure 4 It is a flowchart of yet another microservice request processing method provided by an embodiment of the present application;

[0024] Figure 5 It is a flowchart of a microservice request processing method provided by another embodiment of the present application;

[0025] Figure 6 It is a flowchart of another microservice request processing method provided by another embodiment of the present application;

[0026] Figure 7 A schematic flowchart of another microservice request processing method provided by another embodiment of this application;

[0027] Figure 8 A schematic flowchart of a microservice request processing method provided by another embodiment of this application;

[0028] Figure 9 A schematic structural diagram of a gateway device provided by an embodiment of this application. Detailed implementation manners

[0029] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application.

[0030] An embodiment of this application provides a microservice request processing method. Referring to Figure 1 as shown, the method is applied to a gateway device, and the method includes the following steps:

[0031] Step 101: Receive a service request sent by a client device.

[0032] In the embodiment of this application, the gateway device in the microservice architecture is used to manage and control the microservices provided for the client device and the server device. That is, the client device interacts with the gateway device, and the gateway device realizes the invocation of microservices based on the service request sent by the client device. In addition to the microservice invocation service, the gateway device may also have some other functions, such as authenticating, authorizing, monitoring, caching, load balancing, traffic control, and routing forwarding for the client device, etc. The gateway device may be a virtual gateway device or a physical gateway device. The client device may be a device used by a user, such as a smart mobile device or a computer device, etc., which has the function of being able to access the Internet.

[0033] Step 102: Parse the service request to determine n requested services included in the service request.

[0034] Wherein, n is an integer greater than or equal to 1.

[0035] In the embodiment of this application, after the gateway device receives the service request sent by the client device, the gateway device parses the service request, and parses to obtain n requested services included in the request header of the service request. n is at least 1. The requested service is the service that the client device hopes the server device provides.

[0036] Step 103: Determine the service types of the n requested services to obtain n service types.

[0037] In an embodiment of the present application, the service type of each of the n requested services is determined, thereby obtaining n service types. Exemplarily, assuming that a service request includes two requested services A and B, two service types can be determined, namely the service type of requested service A and the service type of requested service B. It should be noted that there may be the same service types among the n included service types, that is, when n is greater than or equal to 2, there may be two or more identical service types among the n service types.

[0038] Step 104: If the n service types include p first preset types and n - p second preset types, based on the p first preset types, the service request is converted to obtain p target requests.

[0039] Among them, the first preset type is a service type other than the second preset type, p is an integer greater than or equal to 1 and less than n, and the value of n - p is greater than or equal to 1.

[0040] In an embodiment of the present application, when n is an integer greater than 1 and the n service types include both the first preset type and the second preset type, based on the first preset types among the n service types, the service request is converted to obtain the target requests corresponding to each first preset type. Exemplarily, taking n as 3 and p as 2 as an example, when the 3 service types are specifically 2 first preset types and 1 second preset type, based on the 2 first preset types A1 and B1, the service request is converted to obtain 2 target requests, namely the target request a corresponding to the first preset type A1 and the target request b corresponding to the first preset type B1.

[0041] Step 105: Send each target request to a first service device associated with the first preset type.

[0042] In an embodiment of the present application, the first service device associated with the first preset type refers to the service device that provides the microservices of the first preset type. That is, after the gateway device obtains p target requests, it forwards each target request to the first service device that provides the requested service of the corresponding first preset type. The first service device is a service device that provides at least one microservice. Exemplarily, the gateway device forwards the target request a to the first service device that provides the microservice of the first preset type A1, and forwards the target request b to the second service device that provides the microservice of the first preset type B1.

[0043] Step 106: Send the service request to a second service device associated with the second preset type.

[0044] Among them, the service request is used to make the second service device provide the corresponding service.

[0045] In the embodiment of the present application, the second service device having an association relationship with the second preset type refers to the service device that provides the microservices of the second preset type. That is, when the gateway device determines that the n service types include n-p second preset types, there is no need to perform conversion processing on the service request, and the service request is directly forwarded to the second service device that provides the microservices of the second preset type. The second preset type may have an association relationship with the type of the service request. In some application scenarios, when n-p is greater than 1, the gateway device may, according to actual needs, determine the number of second service devices to which the service request is forwarded according to the service request. Therefore, the number of times the gateway device forwards the service request here is not specifically limited and can be specifically determined according to the microservices provided by the second service device.

[0046] In the embodiment of the present application, after receiving the service request sent by the client device, the gateway device parses the service request, determines the n requested services included in the service request, and determines the service types of the n requested services to obtain n service types. If the n service types include p first preset types and n-p second preset types, based on the p first preset types, conversion processing is performed on the service request to obtain p target requests, and each target request is sent to the first service device having an association relationship with the first preset type, and the service request is sent to the second service device having an association relationship with the second preset type. In this way, the gateway device determines whether to perform conversion processing on the service request according to the service types of the requested services included in the service request. When it is determined that conversion processing of the service request is required, it is converted into the corresponding target request and forwarded to the corresponding service device, solving the problem that the current API gateway cannot provide service interfaces of non-HTTP / HTTPS protocols to directly conduct business with microservices of non-HTTP / HTTPS protocols, resulting in low forwarding efficiency, and realizing the technical solution that the API gateway can directly forward non-HTTP / HTTPS protocol requests to the corresponding microservices, effectively improving the forwarding efficiency of the API gateway and enriching the functions of the API gateway.

[0047] Based on the foregoing embodiments, an embodiment of the present application provides a microservice request processing method. Referring to Figure 2 as shown, the method is applied to a gateway device, and the method includes the following steps:

[0048] Step 201: Receive a service request sent by a client device.

[0049] In the embodiment of the present application, a microservice architecture can be provided. Referring to Figure 3 as shown, it includes a client device 31, a gateway device 32, and a server device 33, where: the gateway device 32 is used for information transfer between the client device 31 and the server device 33, and the server device 33 includes multiple service devices for providing various microservices. Figure 3The microservice system corresponding to the microservice architecture shown can be roughly divided into three layers, including: the presentation layer, the API gateway layer, and the business logic layer. Among them, the presentation layer runs on the client device and realizes interaction with users, including World Wide Web (WEB) pages, Application (APP) pages, and interfaces for third-party calls, etc.; the API gateway layer runs on the gateway device and is the unified entry of the microservice system. Externally, the microservice is accessed through the unified API gateway, and at the same time, some non-business functions are processed, such as monitoring, load balancing, traffic control, identity authentication, etc.; the business logic layer runs on the server device and is responsible for implementing business rules.

[0050] Exemplarily, the client device sends a business request in HTTP format to the gateway device.

[0051] Step 202: Parse the business request to determine the n requested services included in the business request.

[0052] Wherein, n is an integer greater than or equal to 1.

[0053] In the embodiment of the present application, the gateway device parses the business request and determines n requested services from the request header of the business request.

[0054] Exemplarily, when the API gateway layer receives a user's HTTP business request, the API gateway layer parses the request header of the HTTP business request to obtain the cache (Cookie) value with the key of target. Among them, the Cookie value indicates the requested services included in the HTTP business request. If the Cookie value is rmb, it means the requested service is the reliable message bus service of the Reliable Message Bus (RMB); if the Cookie value is rmb and http, it means there are two requested services, namely the RMB service and the HTTP service.

[0055] Step 203: Determine the service types of the n requested services to obtain n service types.

[0056] In the embodiment of the present application, when the Cookie value is rmb, n is 1, and the corresponding service type is RMB. When the Cookie value is rmb and http, n is 2, and the corresponding two service types are the RMB service type and the HTTP service type.

[0057] Step 204: If the n service types include p first preset types and n - p second preset types, obtain the target request conversion processor corresponding to each first preset type.

[0058] Among them, the first preset type is a service type other than the second preset type, p is an integer greater than or equal to 1 and less than n, and the value of n - p is greater than or equal to 1.

[0059] In the embodiment of the present application, the target request conversion processor is a converter that is pre-generated and stored in the storage unit corresponding to the gateway device, and is used to convert a service request into a target request corresponding to the first preset type. The second preset type is the HTTP service type, and the first preset type is a service type other than the HTTP service type, such as the RMB service type, the WebSocket service type, etc.

[0060] Exemplarily, when the Cookie value is rmb and http, n is 2, and the corresponding two service types are the RMB service type and the HTTP service type, obtain the target request conversion processor corresponding to the RMB service type.

[0061] Step 205: Parse the target parameters corresponding to each first preset type from the service request through the target request conversion processor, and encapsulate the target parameters in the parameter format corresponding to each first preset type to obtain p target requests.

[0062] In the embodiment of the present application, the gateway device converts the service request into a corresponding target request through the target request conversion processor. Exemplarily, use the HTTP service request as the input parameter of the target request conversion processor corresponding to the RMB service type, and input it into the target request conversion processor corresponding to the RMB service type. The target request conversion processor corresponding to the RMB service type outputs a target request in the RMB format. Among them, when the target request conversion processor corresponding to the RMB service type parses the HTTP service request, since RMB has no request header, the target request conversion processor corresponding to the RMB service type will filter out the request header content of the HTTP service request. RMB also has no request methods such as get and post. The target request conversion processor corresponding to the RMB service type will mask these request methods, that is, delete the items invalid for RMB, so as to parse the parameters of different HTTP request methods, that is, retain the parameters required for RMB as target parameters, and encapsulate the parsed parameters required for RMB in a unified rmb parameter format to obtain the target request corresponding to the RMB service type.

[0063] Step 206: Send each target request to the first service device associated with the first preset type.

[0064] In the embodiment of the present application, the gateway device forwards the target request corresponding to the RMB service type to the first service device providing the RMB service.

[0065] Step 207: Send a service request to a second service device associated with a second preset type.

[0066] The service request is used to enable the second service device to provide corresponding services.

[0067] In an embodiment of the present application, the gateway device forwards an HTTP service request to a second service device that provides HTTP services.

[0068] In this way, by using a pre-set target conversion processor to process the conversion of the service request, the conversion efficiency is effectively improved. And during the process of encapsulating the service request to obtain the target request, operations such as compression and / or filtering are performed according to the service type of the requested service, effectively reducing the size of the target request body, and thus reducing the consumption of network bandwidth. Moreover, there are interfaces with different protocols between the gateway device and the server device for communication. In this way, the gateway device performs a single conversion process on the service request sent by the client device, obtains a target request corresponding to the corresponding server device, and sends it to the corresponding server device. Correspondingly, the API gateway can receive responses in any protocol format sent by the microservice, and then package the received response into an HTTP format response and return it to the client device, effectively improving the service processing efficiency in the microservice architecture.

[0069] Based on the foregoing embodiments, in other embodiments of the present application, step 204 may be implemented by steps 204a to 204c:

[0070] Step 204a: If the n service types include p first preset types and n - p second preset types, obtain a request conversion processor mapping relationship.

[0071] In an embodiment of the present application, the request conversion processor mapping relationship is a pre-set lookup relationship for different preset types in the gateway device and the identification information of the request conversion processors corresponding to different preset types. In some application scenarios, the request conversion processing mapping relationship may be represented in the form of a list.

[0072] Step 204b: From the request conversion processor mapping relationship, determine the identification information of the target request conversion processor corresponding to each first preset type.

[0073] Step 204c: From the target storage area corresponding to the gateway device, obtain the target request conversion processor corresponding to the identification information of the target request conversion processor.

[0074] In this way, by using the request conversion processor mapping relationship set in the gateway device to find the target request conversion processor corresponding to each first preset type, the search efficiency of the target request conversion processor is effectively improved.

[0075] Based on the foregoing embodiments, in other embodiments of the present application, referring to Figure 4 as shown, before the gateway device executes step 202, steps 208 to 210 may be executed:

[0076] Step 208, obtain the stored storage file from the target storage area.

[0077] In the embodiments of the present application, the target storage area may be the storage area corresponding to the gateway device for storing the request conversion processor. The gateway device obtains all the stored storage files in the target storage area.

[0078] Step 209, select the target file in the target form from the storage files.

[0079] In the embodiments of the present application, the target form may refer to the naming form of the file. In some application scenarios, it may also be the storage format of the file. Exemplarily, the gateway device selects the file with the naming form as the target form from the obtained storage files to obtain the target file.

[0080] Step 210, generate a request conversion processor mapping relationship based on the target file.

[0081] In the embodiments of the present application, the gateway device counts the identification information of the target file to obtain the request conversion processor mapping relationship.

[0082] It should be noted that the embodiments corresponding to steps 208 to 210 may be executed before any one of the steps before step 202. Steps 208 to 210 may also be used as an independent embodiment and executed at a certain moment, such as when the gateway device starts or the gateway system in which the gateway device runs starts. It may also be executed after the request conversion processor is updated, and steps 208 to 209 are executed to update the request conversion processor mapping relationship accordingly. In this way, by presetting the request conversion processor mapping relationship, the conversion efficiency of the gateway device when converting service requests is effectively improved.

[0083] Based on the foregoing embodiments, in other embodiments of the present application, step 210 may be implemented by steps 210a to 210d:

[0084] Step 210a, obtain the target identification information of each target file.

[0085] In the embodiments of the present application, the target identification information of each target file may be the information used to uniquely identify the target file. For example, it may be the naming name of the target file.

[0086] Step 210b, determine the storage path of each target file stored in the target storage area.

[0087] Step 210c: Perform reflective loading based on each piece of target identification information and the corresponding storage path to obtain each reference request conversion processor.

[0088] Step 210d: Generate a request conversion processor mapping relationship based on each piece of target identification information and the corresponding reference request conversion processor.

[0089] Exemplarily, 1) When the API gateway system starts up, the API gateway obtains all the files, i.e., storage files, in the target storage area, which is the converter set path, through a file operation class, forming a file set. When the converter set path includes a folder, a recursive request method can be used to determine the sub-files included in the folder, that is, by continuously determining the sub-folders that meet the requirements from the folder through the same query request. Each query request queries a sub-folder from the folder until there are no sub-folders that meet the requirements in the folder. The file set may also include sub-folder paths. For example, in the sub-file folderB included in the file folderA, there is a file named HttpToRmbHandler.java stored, so the path of HttpToRmbHandler.java can be obtained as folderA / folderB / HttpToRmbHandler.java. The target storage area, i.e., the converter set path, can be the system default or specified in a configuration file.

[0090] 2) In the API gateway, it can be set that when naming the request conversion processor, it is named in the form of HttpTo***Handler. In this way, the target form HttpTo***Handler can be determined, that is, select the target files named in the form of HttpTo***Handler from the file set, and determine the target identification information of each target form of the target file. The target file is used to specify the request conversion method. The input parameter of the method is the HTTP service request, and the return parameter is the HTTP response, that is, the output target request. Exemplarily, naming it HttpToRmbHandler means a request conversion processor that converts the HTTP service request into the target request corresponding to RMB.

[0091] 3) Obtain that the target identification information of each target form of the target file determined in step 2) is HttpToRmbHandler, and determine the storage path of each target form of the target file. The storage path of each target form of the target file includes the converter set path. The API gateway reflects and executes the following operations according to the storage path of each target form of the target file:

[0092] a. Lexical analysis. Read the complete content of the converter class definition in the file into memory and identify the keywords in the definition content. These keywords are either reserved keywords in the Java language (such as if, else, while, etc.) or meet the Java variable naming convention (starting with a letter or an underscore). Those that do not meet the requirements will throw an exception and terminate the operation.

[0093] b. Syntactic analysis. Check whether the combination of keywords in a) conforms to the Java language specification. For example, whether a boolean judgment expression immediately follows the if keyword, and whether a function definition includes a return type, function name, function body, etc.

[0094] c. Semantic analysis. Examine the context - related properties of the syntactically correct source program to check for semantic errors. For example, whether the array subscript is an integer and whether the automatic type conversion is correct.

[0095] d. Bytecode generation. Translate the content of the source file into bytecode that conforms to the Java Virtual Machine specification, obtain each reference request conversion processor, and store it in memory. In this way, the API gateway can call the methods or properties in the translated file, that is, the request conversion processor, to complete the corresponding conversion processing operation.

[0096] 4) Build a request conversion processor mapping table. Use the target identification information of each target file in the target form determined in step 2) as the key, and each reference request conversion processor obtained by reflection loading in step 3) as the value to build a request conversion processor mapping table in memory.

[0097] In this way, by pre - counting the request conversion processors stored in the gateway device and generating a request conversion processor mapping table, the situation where the request conversion processor does not exist is effectively reduced, and the request conversion processing efficiency of the gateway device is improved.

[0098] Based on the foregoing embodiments, in other embodiments of the present application, as shown in Figure 5 Before the gateway device executes step 206, it is also used to execute the steps:

[0099] Step 211, obtain the uniform resource identifier URI mapping relationship.

[0100] In the embodiments of the present application, the URI mapping relationship is the URI mapping relationship corresponding to non - second preset types. The URI mapping relationship is the device identification information of the service device that is pre - set to provide microservices other than the second preset type.

[0101] Step 212, based on p first preset types, determine the device identification information for providing services for each first preset type from the URI mapping relationship.

[0102] In the embodiments of the present application, the device identification information for providing services to each first preset type included in the URI mapping relationship may be the interface identification information provided by each microservice externally. The devices providing services for different first preset types are different, and the corresponding device identification information is also different.

[0103] Step 213: Determine the first service device based on the device identification information.

[0104] In the embodiments of the present application, it should be noted that in some application scenarios, one service device may provide microservices of different preset types.

[0105] In this way, by using the pre-set URI mapping relationship to determine the service device providing the microservice of the first preset type, the efficiency of determining the service device providing the microservice is effectively improved, and the forwarding efficiency of the gateway device for forwarding the target request is also improved.

[0106] Based on the foregoing embodiments, in other embodiments of the present application, step 211 may be implemented by steps 211a to 211c:

[0107] Step 211a: Determine the reference device identification information of at least one server device controlled by the gateway device.

[0108] Among them, the at least one server device includes a first service device and a second service device.

[0109] In the embodiments of the present application, the reference device identification information of the at least one server device may be the interface identification information provided by the at least one server device externally.

[0110] Step 211b: Determine at least one target device identification information for providing services other than the service of the second service type from the at least one reference device identification information.

[0111] In the embodiments of the present application, since the gateway device control, that is, at least one service device that can communicate with the gateway device, includes both HTTP format and non-HTTP format, therefore, determine at least one target device identification information belonging to the non-HTTP format from the at least one reference device identification information.

[0112] Step 211c: Generate a URI mapping relationship based on the at least one target device identification information.

[0113] In the embodiments of the present application, count the at least one target device identification information belonging to the non-HTTP format, and generate a URI mapping relationship of the target device identification information providing the non-HTTP format service.

[0114] It should be noted that steps 211a to 211c can be executed before any step before step 210, or can be executed as an independent embodiment, and can be executed at a certain moment, such as when the gateway device is started or the gateway system in which the gateway device runs is started. It can also be executed after the microservices provided by the server are updated, and steps 211a to 211c are executed to perform corresponding updates on the URI mapping relationship.

[0115] In this way, by presetting the URI mapping relationship including at least one target device identification information in a non-HTTP format, the efficiency of determining the service device providing the microservice is effectively improved, and the forwarding efficiency of the gateway device for forwarding the target request is improved.

[0116] Based on the foregoing embodiments, in other embodiments of the present application, step 211c can be implemented by steps a11 to a13:

[0117] Step a11: Determine the target annotation corresponding to each target device identification information.

[0118] Step a12: Obtain the target attribute from the target annotation.

[0119] Step a13: Generate a URI mapping relationship based on each target attribute and the corresponding target device identification information.

[0120] In the embodiments of the present application, by way of example, (1) when the API gateway is started, the Spring framework is used to load the custom annotations included in the API gateway, that is, the target annotations. Among them, the custom annotation includes an attribute path, that is, the target attribute.

[0121] (2) Determine the business service interfaces provided by at least one server device, that is, the reference device identification information of the server device. Determine the business service interfaces in a non-HTTP format from the determined business service interfaces provided by at least one service device to obtain at least one target device identification information. Among them, there is a corresponding custom annotation on the business service interface in a non-HTTP format, and the attribute path included in the custom annotation is used to specify the corresponding HTTP URI, so that it can be indicated that the business service interface is used to process HTTP service requests with the URI being the specified value. Therefore, it is possible to directly determine whether it is a business service interface in a non-HTTP format through the business service interface in a non-HTTP format.

[0122] Exemplarily, the domain name corresponding to the business service is www.wbnk.com. The business service has an interface for providing RMB services externally to query user information. Then, by adding the attribute path value / userinfo included in the custom annotation to the definition of the business service interface, the target device identification information corresponding to the RMB interface of the business service can be obtained as www.wbnk.com / userinfo.

[0123] (3) Construct a request URI mapping table. Using the attribute path parsed in (2) as the key and the corresponding target device identification information as the value, construct a URI mapping table for non-HTTP requests in memory.

[0124] Based on the foregoing embodiments, in other embodiments of the present application, as shown in Figure 6 After the gateway device executes step 207, it is further configured to execute steps 214 to 216:

[0125] Step 214, receive the first service responses sent by each first service device and the second service responses sent by each second service device, and obtain p first service responses and q second service responses.

[0126] Wherein, each first service response is a service response provided by the corresponding first service device for the received target request, and each second service response is a service response provided by the corresponding second service device for the received service request.

[0127] Step 215, process the p first service responses and q second service responses to obtain a target response.

[0128] Wherein, the target response is used to respond to the service request sent by the client device.

[0129] In the embodiments of the present application, the gateway device performs an assembly process on the p first service responses and q second service responses, assembles them into an HTTP response, i.e., the target response, and returns it to the client device. For the response to a submission-type request, only the total number of successful or failed submissions needs to be returned after assembly; for the response to a data acquisition-type request, duplicate data will be removed and filtered during the assembly process, which reduces the size of the response body to a certain extent and reduces network bandwidth consumption.

[0130] Step 216, send the target response to the client device.

[0131] In the embodiments of the present application, the target response is sent to the client device to implement the response to the service request sent by the client device.

[0132] In this way, the gateway device assembles the service responses fed back by the microservices to generate a target response and returns it to the client device. By assembling the service responses fed back by multiple microservices in the gateway device, effective control over the filtering, whitelist control, etc. of the service response data fed back by multiple microservices is achieved, and it is avoided that each service response fed back by a microservice needs to be sent to the client device separately, effectively improving the efficiency of the gateway device in responding to the client device.

[0133] Based on the foregoing embodiments, in other embodiments of the present application, referring to Figure 7 as shown, if the n service types are all the first preset type, after the gateway device executes step 203, it may also choose to execute steps 217 to 221:

[0134] Step 217, if the n service types are all the first preset type, based on each service type, perform conversion processing on the service request to obtain n target requests.

[0135] In the embodiments of the present application, when the n service types are all the first preset type, the specific implementation process of performing conversion processing on the service request based on each service type to obtain n target requests may refer to step 204 and step 205, as well as the implementation processes corresponding to steps 204a to 204c, which will not be elaborated here in detail.

[0136] Step 218, send each target request to a first service device associated with the first preset type.

[0137] Step 219, receive the third service response sent by each first service device.

[0138] Step 220, process the third service response to obtain a target response.

[0139] In the embodiments of the present application, when n = 1, generate a target response in the HTTP format from the third service response sent by the first service device; when n is greater than or equal to 2, perform assembly processing on multiple third service responses to obtain a target response in the HTTP format.

[0140] Step 221, send the target response to the client device.

[0141] In the embodiments of the present application, if the n service types are all the second preset type, directly send the service request to the corresponding second service device, and when receiving the fourth service response sent by each second service device, perform packaging processing on the fourth service response to obtain a target response, and send the target response to the client device.

[0142] In this way, when the service types of all n services are the first preset type, the gateway device processes the service request, obtains the corresponding target request and forwards it to the server device, effectively enriching the functions of the gateway device and improving the forwarding efficiency of the gateway device.

[0143] Based on the foregoing embodiments, an embodiment of the present application provides a microservice request processing method. Referring to Figure 8 as shown, it includes:

[0144] Step 31: The presentation layer sends the user request in HTTP format sent by the client device to the gateway layer.

[0145] Step 32: The gateway layer parses the request header of the user request to obtain the request service type included in the user request.

[0146] Step 33: The gateway layer determines whether the request service type included in the user request is of the HTTP type. If so, step 34 is executed; if not, step 36 is executed.

[0147] Step 34: The gateway layer forwards the user request to the service interface of the HTTP type.

[0148] Step 35: The gateway layer receives the service response 1 regarding the user request sent by the service interface of the HTTP type.

[0149] Step 36: The gateway layer obtains the request conversion processor corresponding to the non-HTTP type request service type, and performs conversion processing on the user request through the corresponding request conversion processor to obtain the target request 1 and the target request 2.

[0150] Step 37: The gateway layer obtains the URI mapping table.

[0151] Step 38: Based on the URI mapping table, the gateway layer determines the service interface 1 corresponding to the request service type corresponding to the target request 1, and sends the target request 1 to the service interface 1, determines the service interface 2 corresponding to the request service type corresponding to the target request 2, and sends the target request 2 to the service interface 2.

[0152] Step 39: The gateway layer receives the service response 2 for the target request 1 sent by the service interface 1 and the service response 3 for the target request 2 sent by the service interface 2.

[0153] Step 310: The gateway layer assembles the service response 1, the service response 2, and the service response 3 to obtain the target response.

[0154] Step 311: The gateway layer sends the target response to the presentation layer.

[0155] Step 312: The presentation layer displays the content corresponding to the target response.

[0156] It should be noted that for the descriptions of the same steps and the same content in this embodiment and other embodiments, reference may be made to the descriptions in other embodiments, and details will not be repeated here.

[0157] In the embodiment of the present application, after receiving a service request sent by a client device, the gateway device parses the service request, determines n requested services included in the service request, and determines the service types of the n requested services to obtain n service types. If the n service types include p first preset types and n - p second preset types, based on the p first preset types, the service request is converted to obtain p target requests, and each target request is sent to a first service device associated with the first preset type, and the service request is sent to a second service device associated with the second preset type. In this way, the gateway device determines whether to perform conversion processing on the service request according to the service types of the requested services included in the service request. When it is determined that the service request needs to be converted, it is converted into a corresponding target request and forwarded to the corresponding service device, solving the problem that the current API gateway cannot provide service interfaces for non-HTTP / HTTPS protocols, resulting in low forwarding efficiency for direct business interactions with microservices using non-HTTP / HTTPS protocols. It realizes the technical solution that the API gateway can directly forward requests for non-HTTP / HTTPS protocols to the corresponding microservices, effectively improving the forwarding efficiency of the API gateway and enriching the functions of the API gateway.

[0158] Based on the foregoing embodiments, an embodiment of the present application provides a gateway device. Referring to Figure 9 as shown, the gateway device 4 may include: a processor 41, a memory 42, and a communication bus 43, where:

[0159] The memory 42 is used to store executable instructions;

[0160] The communication bus 43 is used to implement the communication connection between the processor 41 and the memory 42;

[0161] The processor 41 is used to execute the microservice request processing program stored in the memory 42 to implement the following steps:

[0162] Receive a service request sent by a client device;

[0163] Parse the service request to determine n requested services included in the service request; where n is an integer greater than or equal to 1;

[0164] Determine the service types of the n requested services to obtain n service types;

[0165] If the n service types include p first preset types and n - p second preset types, based on the p first preset types, the service request is processed for conversion to obtain p target requests; wherein, the first preset type is a service type other than the second preset type, p is an integer greater than or equal to 1 and less than n, and the value of n - p is greater than or equal to 1;

[0166] Send each target request to a first service device associated with the first preset type;

[0167] Send the service request to a second service device associated with the second preset type; wherein, the service request is used to make the second service device provide the corresponding service.

[0168] In other embodiments of the present application, when the processor executes the step that if the n service types include p first preset types and n - p second preset types, based on the p first preset types, the service request is processed for conversion to obtain p target requests, it can be implemented through the following steps:

[0169] If the n service types include p first preset types and n - p second preset types, obtain a target request conversion processor corresponding to each first preset type;

[0170] Through the target request conversion processor, parse the target parameters corresponding to each first preset type from the service request, and encapsulate the target parameters in the parameter format corresponding to each first preset type to obtain p target requests.

[0171] In other embodiments of the present application, when the processor executes the step that if the n service types include p first preset types and n - p second preset types, obtain a target request conversion processor corresponding to each first preset type, it can be implemented through the following steps:

[0172] If the n service types include p first preset types and n - p second preset types, obtain a request conversion processor mapping relationship;

[0173] From the request conversion processor mapping relationship, determine the identification information of the target request conversion processor corresponding to each first preset type;

[0174] From the target storage area corresponding to the gateway device, obtain the target request conversion processor corresponding to the identification information of the target request conversion processor.

[0175] In other embodiments of the present application, before the processor executes the step of parsing the service request to determine the n requested services included in the service request, it is further used to execute the following steps:

[0176] From the target storage area, obtain the stored storage file;

[0177] Select a target file in the target format from the storage file;

[0178] Generate a request conversion processor mapping relationship based on the target file.

[0179] In other embodiments of the present application, when the processor executes the step of generating a request conversion processor mapping relationship based on the target file, it can be implemented through the following steps:

[0180] Obtain the target identification information of each target file;

[0181] Determine the storage path where each target file is stored in the target storage area;

[0182] Perform reflection loading based on each target identification information and the corresponding storage path to obtain each reference request conversion processor;

[0183] Generate a request conversion processor mapping relationship based on each target identification information and the corresponding reference request conversion processor.

[0184] In other embodiments of the present application, before the processor executes the step of sending each target request to the first service device associated with the first preset type, it is further configured to execute the following steps:

[0185] Obtain a Uniform Resource Identifier (URI) mapping relationship;

[0186] Based on p first preset types, determine the device identification information for providing services for each first preset type from the URI mapping relationship;

[0187] Determine the first service device based on the device identification information.

[0188] In other embodiments of the present application, when the processor executes the step of obtaining a Uniform Resource Identifier (URI) mapping relationship, it can be implemented through the following steps:

[0189] Determine the reference device identification information of at least one server device controlled by the gateway device; wherein, the at least one server device includes a first service device and a second service device;

[0190] Determine at least one target device identification information for providing services other than the services of the second service type from the at least one reference device identification information;

[0191] Generate a URI mapping relationship based on the at least one target device identification information.

[0192] In other embodiments of the present application, when the processor executes the step of generating a URI mapping relationship based on the at least one target device identification information, it can be implemented through the following steps:

[0193] Determine the target annotation corresponding to each target device identification information;

[0194] Obtain the target attribute from the target annotation;

[0195] Generate a URI mapping relationship based on each target attribute and the corresponding target device identification information.

[0196] In other embodiments of the present application, the processor is further configured to perform the following steps:

[0197] Receive the first service response sent by each first service device and the second service response sent by each second service device, and obtain p first service responses and q second service responses; wherein, each first service response is a service response provided by the corresponding first service device for the received target request, and each second service response is a service response provided by the corresponding second service device for the received service request;

[0198] Process the p first service responses and q second service responses to obtain a target response; wherein, the target response is used to respond to the service request sent by the client device;

[0199] Send the target response to the client device.

[0200] In other embodiments of the present application, the processor is further configured to perform the following steps:

[0201] If the n service types are all the first preset type, based on each service type, perform conversion processing on the service request to obtain n target requests;

[0202] Send each target request to the first service device associated with the first preset type;

[0203] Receive the third service response sent by each first service device;

[0204] Process the third service response to obtain a target response;

[0205] Send the target response to the client device.

[0206] It should be noted that the explanation of the steps of one or more programs by one or more processors in the embodiments of the present application can refer to Figures 1 - 2 and Figures 4 - 7 the method implementation process provided in the corresponding embodiments, which will not be elaborated here.

[0207] In the embodiment of the present application, after receiving a service request sent by a client device, the gateway device parses the service request, determines n requested services included in the service request, and determines the service types of the n requested services to obtain n service types. If the n service types include p first preset types and n - p second preset types, based on the p first preset types, the service request is subjected to conversion processing to obtain p target requests, and each target request is sent to a first service device associated with the first preset type, and the service request is sent to a second service device associated with the second preset type. In this way, the gateway device determines whether to perform conversion processing on the service request according to the service types of the requested services included in the service request. When it is determined that the service request needs to be converted and processed, it is converted into a corresponding target request and forwarded to the corresponding service device, which solves the problem that the current API gateway cannot provide service interfaces for non-HTTP / HTTPS protocols, resulting in low forwarding efficiency for direct business interactions with microservices using non-HTTP / HTTPS protocols. It realizes the technical solution that the API gateway can directly forward requests for non-HTTP / HTTPS protocols to the corresponding microservices, effectively improving the forwarding efficiency of the API gateway and enriching the functions of the API gateway.

[0208] Based on the foregoing embodiments, an embodiment of the present application provides a computer-readable storage medium, simply referred to as a storage medium. The computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the Figures 1 - 2 and Figures 4 - 7 implementation process of the microservice request processing method provided in the corresponding embodiments, which will not be elaborated here.

[0209] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) containing computer-usable program code.

[0210] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, and the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate for implementation in the processFigure 1 a process or processes and / or blocks Figure 1 a device for the functions specified in a block or blocks.

[0211] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the functions in the process Figure 1 a process or processes and / or blocks Figure 1 specified in a block or blocks.

[0212] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus, such that a series of operational steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions in the process Figure 1 a process or processes and / or blocks Figure 1 specified in a block or blocks.

[0213] As described above, only the preferred embodiments of this application are provided and are not intended to limit the protection scope of this application.

Claims

1. A microservice request processing method, characterized in that, the method includes: Receiving a service request sent by a client device; Parsing the service request to determine n requested services included in the service request; where n is an integer greater than or equal to 1; Determining the service types of the n requested services to obtain n service types; If the n service types include p first preset types and n - p second preset types, based on the p first preset types, performing conversion processing on the service request to obtain p target requests; where the first preset type is a service type other than the second preset type, p is an integer greater than or equal to 1 and less than n, and the value of n - p is greater than or equal to 1; Sending each of the target requests to a first service device associated with the first preset type; Sending the service request to a second service device associated with the second preset type; where the service request is used to enable the second service device to provide corresponding services; where, the step of if the n service types include p first preset types and n - p second preset types, performing conversion processing on the service request based on the p first preset types to obtain p target requests, includes: If the n service types include p first preset types and n - p second preset types, through the request conversion processor mapping relationship, obtaining a target request conversion processor corresponding to each of the first preset types; using the service request as an input parameter of the target request conversion processor, and through the target request conversion processor, parsing each first preset type corresponding target parameter from the service request, and encapsulating the target parameter in the parameter format corresponding to each first preset type to obtain p target requests; where the request conversion processor mapping relationship is obtained in the following manner: Obtaining the target identification information of each target file; Determining the storage path where each target file is stored in the target storage area; Performing reflection loading based on each target identification information and the corresponding storage path to obtain each reference request conversion processor; Generating the request conversion processor mapping relationship based on each target identification information and the corresponding reference request conversion processor.

2. The method according to claim 1, characterized in that, the step of if the n service types include p first preset types and n - p second preset types, obtaining a target request conversion processor corresponding to each of the first preset types, includes: If the n service types include p first preset types and n - p second preset types, obtaining the request conversion processor mapping relationship; Determining, from the request conversion processor mapping relationship, the identification information of the target request conversion processor corresponding to each of the first preset types; Obtaining the target request conversion processor corresponding to the identification information of the target request conversion processor from the target storage area corresponding to the gateway device.

3. The method according to claim 2, characterized in that, Before parsing the service request and determining the n requested services included in the service request, the method further includes: Obtain the stored storage file from the target storage area; Select a target file in a target format from the storage file; Generate the request conversion processor mapping relationship based on the target file.

4. The method according to claim 1, wherein, Before sending each of the target requests to a first service device associated with the first preset type, the method further includes: Obtain a Uniform Resource Identifier (URI) mapping relationship; Based on the p first preset types, determine device identification information for providing services for each of the first preset types from the URI mapping relationship; Determine the first service device based on the device identification information.

5. The method according to claim 4, wherein, The obtaining of the Uniform Resource Identifier (URI) mapping relationship includes: Determine reference device identification information of at least one server device controlled by a gateway device; wherein, at least one of the server devices includes the first service device and the second service device; Determine at least one target device identification information for providing services other than the services of the second preset type from at least one of the reference device identification information; Generate the URI mapping relationship based on at least one of the target device identification information.

6. The method according to claim 5, wherein, The generating of the URI mapping relationship based on at least one of the target device identification information includes: Determine a target annotation corresponding to each of the target device identification information; Obtain a target attribute from the target annotation; Generate the URI mapping relationship based on each of the target attributes and the corresponding target device identification information.

7. The method according to any one of claims 1 to 6, wherein, The method further includes: Receive a first service response sent by each of the first service devices and a second service response sent by each of the second service devices to obtain p first service responses and q second service responses; wherein, each first service response is a service response provided by the corresponding first service device for the received target request, and each second service response is a service response provided by the corresponding second service device for the received service request; Process the p first service responses and the q second service responses to obtain a target response; wherein, the target response is used to respond to the service request sent by the client device; Send the target response to the client device.

8. The method according to any one of claims 1 to 6, wherein, The method further includes: If all of the n service types are the first preset type, perform conversion processing on the service request based on each of the service types to obtain n target requests; Send each of the target requests to a first service device associated with the first preset type; Receive a third service response sent by each of the first service devices; Process the third service response to obtain a target response; Send the target response to the client device.

9. A gateway device, characterized in that, the device includes a memory, a processor, and a communication bus; wherein: the memory is used for storing executable instructions; the communication bus is used for realizing the communication connection between the processor and the memory; the processor is used for executing the microservice request processing program stored in the memory to realize the steps of the microservice request processing method according to any one of claims 1 to 8.

10. A storage medium, characterized in that, the storage medium stores a microservice request processing program, and when the microservice request processing program is executed by a processor, the steps of the microservice request processing method according to any one of claims 1 to 8 are realized.

Images