Request processing method and system, server, storage medium and program product

Abstract

The invention discloses a request processing method and system, a server, a storage medium and a program product. The method relates to the technical field of big data, and comprises the following steps: receiving a service request sent by terminal equipment; basic data required for executing the service request is predicted, and the basic data comprises function information and resource requirements; selecting a target server from the plurality of second servers according to the function information, the resource demand and the current states of the plurality of second servers; and sending a processing instruction including the function information and the service request to the target server, so that the target server executes the service request after obtaining and loading a method function corresponding to the function information from the central database. According to the scheme provided by the invention, local execution of the service request in the target server can be realized, the network communication overhead is reduced, and meanwhile, the resource utilization rate and the response timeliness of the server are improved.

Description

Technical Field

[0001] This invention relates to the field of big data technology, and in particular to a request processing method, system, server, storage medium, and program product. Background Technology

[0002] With the digital transformation of financial services, business systems are gradually evolving towards high concurrency, high iteration, and high availability. To ensure the processing of massive requests, rapid feature iteration, and fault isolation requirements, most business systems currently adopt a distributed microservice architecture to achieve service decoupling and elastic scaling.

[0003] Distributed microservice architecture is a software architecture pattern that breaks down complex applications into multiple small, independent service units. These service units work together over a network to complete the functionality that was originally a single application. However, when processing service requests, every call between service units in a distributed microservice architecture requires network transmission, protocol parsing, and serialization / deserialization, resulting in excessive network communication overhead and increased latency. Furthermore, each service unit constantly consumes server memory, leading to low resource utilization. Summary of the Invention

[0004] This invention provides a request processing method, system, server, storage medium, and program product, which enables service requests to be executed locally on the target server, reducing network communication overhead and improving server resource utilization and response time.

[0005] According to one aspect of the present invention, a request processing method is provided, applied to a first server, the method comprising: receiving a service request sent by a terminal device; predicting basic data required to execute the service request, wherein the basic data includes function information and resource requirements; selecting a target server from a plurality of second servers based on the function information, resource requirements and the current state of a plurality of second servers; and sending a processing instruction including function information and a service request to the target server, such that the target server retrieves and loads the method function corresponding to the function information from a central database and then executes the service request.

[0006] Optionally, the basic data required to predict the execution of the service request includes: parsing the service request and extracting the feature elements of the service request; inputting the feature elements into a pre-set first prediction model to obtain function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; and determining the resource requirements based on the function information.

[0007] Optionally, the basic data required to predict the execution of the service request includes: obtaining the feature vector of the service request; classifying the feature vector to obtain function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; and determining the resource requirements based on the function information.

[0008] Optionally, based on function information, resource requirements, and the current status of several second servers, a target server is selected from several second servers, including: obtaining the current status of each second server, wherein the current status includes the current available resources and the list of currently loaded functions; selecting a second server whose current available resources are greater than or equal to the resource requirements as a candidate server; and determining the target server based on the function information and the list of currently loaded functions of the candidate servers.

[0009] Optionally, the target server is determined based on the function information and the list of currently loaded functions of the candidate servers, including: for each candidate server, calculating the function download and loading latency corresponding to the candidate server based on the function information and the list of currently loaded functions of the candidate server; determining the processing latency of the candidate server for handling service requests based on the attribute information and the current available resources of the candidate server; calculating the total latency corresponding to the candidate server based on the function download and loading latency and the processing latency; and determining the target server based on the total latency corresponding to all candidate servers.

[0010] Optionally, the processing instruction may also include an uninstallation instruction, which instructs the target server to uninstall the function to be uninstalled; before sending the processing instruction, which includes function information and service requests, to the target server, the method may further include: determining the function to be uninstalled based on the target server's currently loaded function list and preset resource management rules.

[0011] Optionally, after sending a processing instruction including function information and service request to the target server, the method further includes: receiving the processing result sent by the target server; and sending the processing result to the terminal device.

[0012] According to another aspect of the present invention, a first server is provided, the first server comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the request processing method of any embodiment of the present invention.

[0013] According to another aspect of the present invention, a request processing system is provided, including a first server according to any embodiment of the present invention, a central database, and a plurality of second servers.

[0014] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the request processing method of any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the request processing method of any embodiment of the present invention.

[0016] The technical solution of this invention receives a service request sent by a terminal device and predicts the basic data required to execute the service request. Further, based on the function information and resource requirements included in the basic data, and combined with the current status of several second servers, a target server is selected from several second servers. A processing instruction including function information and the service request is sent to the target server, enabling the target server to retrieve and load the method function corresponding to the function information from the central database and then execute the service request. Compared with existing distributed microservice architectures, firstly, because the basic data required to execute the service request is predicted, including function information and resource requirements, a data foundation can be provided for subsequent selection of a suitable target server. Secondly, because the selection of the target server fully considers function information, resource requirements, and the current status of each second server, the target server can meet the resource requirements for executing the service request while improving resource utilization and response time. Thirdly, after the target server retrieves and loads the method function corresponding to the function information from the central database according to the processing instruction, it executes the service request locally on the target server, reducing network communication overhead. Furthermore, the method function is centrally stored in the central database for management and maintenance, which significantly reduces operational complexity.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the structure of a request processing system provided in an embodiment of the present invention;

[0020] Figure 2 This is a flowchart illustrating a request processing method provided in an embodiment of the present invention;

[0021] Figure 3 This is an interactive schematic diagram of a request processing method provided in an embodiment of the present invention;

[0022] Figure 4 This is an example of function information prediction provided by an embodiment of the present invention;

[0023] Figure 5 This is another example of function information prediction provided by an embodiment of the present invention;

[0024] Figure 6 This is a schematic diagram of the structure of a request processing device provided in an embodiment of the present invention;

[0025] Figure 7 This is a schematic diagram of the structure of a first server provided in an embodiment of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," "target," "current," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] Furthermore, the user-related information (such as user identifier, device information, geographical location, etc.) involved in the following embodiments of the present invention is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0029] Figure 1 This is a schematic diagram of the structure of a request processing system provided in an embodiment of the present invention. Figure 1 As shown, the request processing system includes: a first server, several second servers, and a central database. The central database and the first server can interact with each of the second servers, and the central database and the first server can also interact.

[0030] The central database is a database that centrally stores, manages, and maintains method functions. A method function is an independent unit of code that performs a specific task; it is the smallest executable program unit stored within the central database. Different service requests require combinations of different method functions to be implemented. The central database can communicate and interact with each server (e.g., server 1, server 2, etc.). The central database can be of various types, such as a relational database, object storage database, or metadata database.

[0031] The first server is used for request analysis and resource scheduling. The second server is used for executing requests. In this invention, the first and second servers can switch roles; that is, the roles of the first and second servers are not fixed and can be dynamically adjusted according to system needs (such as load changes, fault recovery, and functional expansion). The first server, originally responsible for "request analysis and resource scheduling," can switch to the role of "request execution," and the second server, originally responsible for "request execution," can also switch to the role of "request analysis and resource scheduling." This switching mechanism aims to improve system flexibility, fault tolerance, and resource utilization.

[0032] Figure 2 This is a flowchart illustrating a request processing method provided in an embodiment of the present invention. This embodiment is applicable to situations involving the processing of service requests. The method can be executed by a request processing device, which can be implemented in hardware and / or software. The request processing device can be configured in... Figure 1 Within the first server of the request processing system shown. For example... Figure 2 As shown, the method includes:

[0033] S210, Receive service requests sent by terminal devices.

[0034] In this invention, a terminal device is any device capable of sending service requests. A service request is an application issued by the terminal device requesting the server to provide specific functions or data, such as a query request or an operation execution request.

[0035] S220. Predict the basic data required to execute the service request, including function information and resource requirements.

[0036] Upon receiving a service request, the first server needs to predict the basic data required to execute the request. This basic data includes function information and resource requirements. Function information refers to the methods and functions needed to execute the service request, while resource requirements refer to the server resources required to execute the request.

[0037] In one possible implementation, the method for predicting the basic data required to execute a service request may include: parsing the service request and extracting its feature elements; inputting the feature elements into a pre-set first prediction model to obtain function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; and determining resource requirements based on the function information.

[0038] The first prediction model can be a pre-trained model used to predict function information based on feature elements. For example, the first prediction model can be a decision tree model.

[0039] In another possible implementation, the method for predicting the basic data required to execute a service request may include: obtaining a feature vector of the service request; classifying the feature vector to obtain function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; and determining resource requirements based on the function information.

[0040] Specifically, a second prediction model can be used to obtain the feature vector of the service request, and then the feature vector can be classified based on a classifier to obtain function information. For example, the second prediction model can be a language model.

[0041] S230. Based on the function information, resource requirements, and the current status of several second servers, select the target server from the several second servers.

[0042] After obtaining the basic data through prediction, the target server can be selected from several secondary servers based on function information, resource requirements, and the current status of several secondary servers, in order to facilitate subsequent server scheduling.

[0043] In one embodiment, the first server selects the target server from a plurality of second servers. The plurality of second servers can be a global range of servers (i.e., all second servers included in the system) or a regional range of servers (i.e., a subset of second servers included in the system). The division of the regional server range can be determined based on the geographical location, type, grouping information, etc. of the servers, and this embodiment of the invention does not impose specific limitations on this.

[0044] The principle for selecting target servers is to ensure resource utilization and response time while meeting the resource requirements for executing service requests, thereby improving user experience and ensuring server load balancing.

[0045] S240. Send a processing instruction including function information and service request to the target server, so that the target server can retrieve and load the method function corresponding to the function information from the central database and then execute the service request.

[0046] The processing instruction is used to instruct the target server to execute the service request based on the function information. Specifically, after receiving the processing instruction, the target server first downloads the method function corresponding to the function information from the central database, then loads the method function to form a unified executable environment, ensuring that the method functions can work together, and finally executes the service request.

[0047] Optionally, the target server can also perform security and resource management on the aforementioned executable environment. Specifically, before loading the method function, a strict security check can be performed in an isolated environment (such as an in-process sandbox) to verify the digital signature of the method function, ensuring its source is trustworthy and has not been tampered with. Only after successful verification is it loaded into the main execution environment. When executing service requests, resource isolation mechanisms can also be implemented (such as setting resource quotas through the operating system or container technology) to strictly limit the amount of resources used. At the same time, the resource usage during the execution of service requests can be continuously tracked to ensure that its behavior complies with preset limits, preventing resource abuse or abnormal behavior from interfering with the system.

[0048] The technical solution of this invention receives a service request sent by a terminal device and predicts the basic data required to execute the service request. Further, based on the function information and resource requirements included in the basic data, and combined with the current status of several second servers, a target server is selected from several second servers. A processing instruction including function information and the service request is sent to the target server, enabling the target server to retrieve and load the method function corresponding to the function information from the central database and then execute the service request. Compared with existing distributed microservice architectures, firstly, because the basic data required to execute the service request is predicted, including function information and resource requirements, a data foundation can be provided for subsequent selection of a suitable target server. Secondly, because the selection of the target server fully considers function information, resource requirements, and the current status of each second server, the target server can meet the resource requirements for executing the service request while improving resource utilization and response time. Thirdly, after the target server retrieves and loads the method function corresponding to the function information from the central database according to the processing instruction, it executes the service request locally on the target server, reducing network communication overhead. Furthermore, the method function is centrally stored in the central database for management and maintenance, which significantly reduces operational complexity.

[0049] Figure 3 This is an interactive schematic diagram of a request processing method provided by an embodiment of the present invention. Based on the above embodiments, this embodiment provides a specific prediction method for basic data, a specific selection method for the target server, and a specific implementation method for the target server to execute service requests. Figure 3 As shown, the method includes:

[0050] S301, The terminal device sends a service request to the first server.

[0051] S302, The first server receives the service request sent by the terminal device.

[0052] S303. The first server predicts the basic data required to execute the service request, including function information and resource requirements.

[0053] In one embodiment, the basic data includes function information and resource requirements. Function information refers to the methods and functions required to execute the service request, while resource requirements refer to the server resources needed to execute the service request. Function information may include the function name and its corresponding version number, as well as the function call path.

[0054] In one possible implementation, the method of "the first server predicting the basic data required to execute the service request" may include the following three steps.

[0055] Step A1: Parse the service request and extract its feature elements.

[0056] Specifically, static code analysis of service requests can parse out the various components of the service request, such as the request path, request headers, parameters, request body, and context information (such as user identifier, device information, geographical location, etc.), and then use some or all of these components as feature elements of the service request.

[0057] Optionally, the components can be normalized to unify their metrics for easier subsequent prediction.

[0058] Step A2: Input the feature elements into the pre-set first prediction model to obtain function information, which includes the function name and its corresponding version number, as well as the function call path.

[0059] In one embodiment, the first prediction model may be a pre-trained model used to predict function information based on feature elements.

[0060] Taking the first prediction model as an example, which is the decision tree model, Figure 4 This is an example of function information prediction provided by an embodiment of the present invention. For example... Figure 4 As shown, by extracting feature elements and matching them based on a decision tree model, we can obtain the function name, its corresponding version number, and the function call path.

[0061] The function information includes the function name and its corresponding version number, as well as the function call path. This represents the minimum set of functions and related information predicted by the first server to be required to process the service request. The function call path can be represented as a function list or as a call relationship graph.

[0062] Optionally, the function call path can also be optimized based on historical execution data. The purpose is to load only high-frequency core method functions in the initial stage, and load low-frequency method functions on demand, thereby reducing the initial occupation of server memory and other resources.

[0063] Step A3: Determine resource requirements based on function information.

[0064] Specifically, resource requirements can be determined based on historical request processing performance data or performance baseline data stored in a central database, combined with function information.

[0065] Resource requirements may include, but are not limited to: CPU computation, memory usage, and input / output operations.

[0066] In another possible implementation, the method of "the first server predicting the underlying data required to execute the service request" may include the following three steps.

[0067] Step B1: Obtain the feature vector of the service request.

[0068] Step B2: Classify the feature vectors to obtain function information, which includes the function name and its corresponding version number, as well as the function call path.

[0069] The first server can use the second prediction model to obtain the feature vector of the service request, and then classify the feature vector based on the classifier to obtain function information.

[0070] Taking the second prediction model as an example, which is a language model, Figure 5 This is another example of function information prediction provided by an embodiment of the present invention. For example... Figure 5 As shown, by inputting the service request into the language model, the feature vector of the service request is obtained. Then, the feature vector is classified according to the classifier to obtain the function name, its corresponding version number, and the function call path.

[0071] The function information includes the function name and its corresponding version number, as well as the function call path. This represents the minimum set of functions and related information predicted by the first server to be required to process the service request. The function call path can be represented as a function list or as a call relationship graph.

[0072] Optionally, the function call path can also be optimized based on historical execution data. The purpose is to load only high-frequency core method functions in the initial stage, and load low-frequency method functions on demand, thereby reducing the initial occupation of server memory and other resources.

[0073] Step B3: Determine resource requirements based on function information.

[0074] Specifically, resource requirements can be determined based on historical request processing performance data or performance baseline data stored in a central database, combined with function information.

[0075] Resource requirements may include, but are not limited to: CPU computation, memory usage, and input / output operations.

[0076] It should also be noted that, regardless of whether it is the first preset model or the second preset model, the present invention can continuously collect real data during the actual request processing process to evaluate the accuracy of the prediction and optimize it.

[0077] S304. The first server obtains the current status of each second server, where the current status includes the amount of currently available resources and the list of currently loaded functions.

[0078] In one embodiment, the first server selects the target server from a plurality of second servers. The plurality of second servers can be a global range of servers (i.e., all second servers included in the system) or a regional range of servers (i.e., a subset of second servers included in the system). The division of the regional server range can be determined based on the geographical location, type, grouping information, etc. of the servers, and this embodiment of the invention does not impose specific limitations on this.

[0079] Optionally, the current status may also include CPU utilization, memory usage, network bandwidth, storage space, current load, etc.

[0080] S305. The first server selects the second server whose current available resources are greater than or equal to the resource requirement as the candidate server.

[0081] The current available resources of the candidate servers are greater than or equal to the resource requirements, ensuring that the candidate servers can all meet the resource requirements for executing service requests.

[0082] S306. The first server determines the target server based on the function information and the list of currently loaded functions of the candidate servers.

[0083] Specifically, the method of "the first server determining the target server based on the function information and the list of currently loaded functions of the candidate servers" can include the following four steps.

[0084] Step C1: For each candidate server, calculate the function download and loading latency corresponding to the candidate server based on the function information and the list of currently loaded functions of the candidate server.

[0085] The first server can compare the function information with the list of currently loaded functions on the candidate servers to determine whether at least some of the methods in the function information have been loaded on the candidate servers, thereby reducing the download and loading delay of the corresponding functions on the candidate servers.

[0086] In this way, repeated downloading and loading of methods and functions can be avoided, significantly reducing latency and resource overhead.

[0087] Step C2: Determine the processing latency of the candidate server for handling service requests based on the candidate server's attribute information and the current available resources.

[0088] Step C3: Calculate the total latency corresponding to the candidate servers based on the function download and loading latency and processing latency.

[0089] Step C4: Determine the target server based on the total latency corresponding to all candidate servers.

[0090] The number of target servers can be one or more. When there are multiple target servers, each target server needs to execute the service request independently.

[0091] Specifically, when there is only one target server, the candidate server with the minimum total latency among all candidate servers is selected as the target server. When there are N target servers (N is an integer greater than or equal to 2), the total latency of all candidate servers is arranged in ascending order, and the candidate server with the highest total latency among the top N is selected as the target server.

[0092] S307. The first server determines the functions to be uninstalled based on the target server's currently loaded function list and preset resource management rules.

[0093] For example, the first server can determine low-frequency method functions based on the target server's currently loaded function list and their recent usage time, usage frequency, etc., and designate these low-frequency method functions as functions to be unloaded.

[0094] S308. The first server sends a processing instruction to the target server. The processing instruction includes function information, service request, and uninstallation instruction. The uninstallation instruction is used to instruct the target server to uninstall the function to be uninstalled.

[0095] By using the uninstallation instruction, the target server can uninstall infrequently used methods and functions, thereby freeing up server resources.

[0096] S309, The target server receives the processing instruction.

[0097] S310. The target server uninstalls the function to be uninstalled and retrieves and loads the corresponding method function from the central database.

[0098] The central database is a database that centrally stores, manages, and maintains method functions. A method function is an independent unit consisting of a piece of code that performs a specific task; it is the smallest executable program unit stored within the central database.

[0099] Each method / function can include the following information: 1) Function and Interface Definition: Clearly describes the function's functionality, input data format requirements, and output data format. 2) Resource Requirements: Specifies the computing resources required for execution, including CPU, memory, disk space, and whether it depends on specific hardware. 3) Dependencies: Lists other modules or external libraries that the function depends on for normal operation. 4) Version Information: Includes the version number, supporting efficient version management, retrieval, and differentiation. 5) Security and Permission Requirements: Specifies the security context or operation permissions required for the function to run. 6) Performance Baseline Data: Provides reference performance metrics for function execution, such as average execution time and resource consumption. 7) Security Mechanisms: The function must be digitally signed, verified, and its source audited to ensure its authenticity and tamper-proof nature. It supports loading and execution in sandbox or secure container environments to restrict access permissions and potential impacts.

[0100] Specifically, the target server downloads the corresponding method functions from the central database, loads the method functions to form a unified executable environment, ensuring that the method functions can work together, and finally executes the service request.

[0101] Optionally, the target server can also perform security and resource management on the aforementioned executable environment. Specifically, before loading the method function, a strict security check can be performed in an isolated environment (such as an in-process sandbox) to verify the digital signature of the method function, ensuring its source is trustworthy and has not been tampered with. Only after successful verification is it loaded into the main execution environment. When executing service requests, resource isolation mechanisms can also be implemented (such as setting resource quotas through the operating system or container technology) to strictly limit the amount of resources used. At the same time, the resource usage during the execution of service requests can be continuously tracked to ensure that its behavior complies with preset limits, preventing resource abuse or abnormal behavior from interfering with the system.

[0102] S311. The target server executes the service request and sends the processing result to the first server.

[0103] The execution of service requests by the target server involves interaction and collaboration between different method functions. However, since all method functions are loaded in the target server, the process can be completed within the memory space of the same process.

[0104] Optionally, the target server can also be configured with a disaster recovery mechanism. If, during execution, it is found that the required method function is not loaded (e.g., due to inaccurate prediction), the target server will immediately trigger the dynamic loading of the method function from the central database into the local environment, and then perform the local function call after loading is complete. The disaster recovery mechanism enhances the system's tolerance to prediction deviations, ensuring that requests can continue to be completed efficiently.

[0105] S312. The first server receives the processing result sent by the target server.

[0106] S313, The first server sends the processing result to the terminal device.

[0107] S314. The terminal device receives the processing result sent by the first server.

[0108] By forwarding the processing results to the terminal device through the first server, the entire process of service request processing is improved.

[0109] Optionally, the target server can also send the processing results to the terminal device itself.

[0110] Building upon the above embodiments, since consecutive requests from the same user may be routed to different target servers for processing, maintaining and synchronizing a small amount of business state (especially session data) that needs to be shared across nodes directly within each target server is complex and unreliable. Therefore, each target server can store such business state (e.g., session data) that needs to be shared across nodes in an external shared storage service, so that the target server can directly access the external shared storage service when it needs to read or update this shared state.

[0111] This approach avoids implementing complex and error-prone state synchronization mechanisms (such as distributed consistency protocols) within the server, significantly reducing the complexity of node development and maintenance costs. It leverages the inherent persistence, high availability, and consistency guarantees of external shared storage services to improve the reliability and consistency of critical business states. The server itself maintains a stateless or lightweight design, making it easier to scale, upgrade, and recover from failures.

[0112] In addition, when the target server needs to destroy a created "executable environment" (i.e., sandbox), it can safely and orderly release all resources (such as memory, central processing unit, etc.) occupied by the environment according to the preset caching policy or scheduling instructions, and synchronize the resource release information to the first server.

[0113] This approach promptly releases idle or no longer needed resources, improving the overall utilization and turnover efficiency of physical node resources. Simultaneously, it avoids resource leakage, ensuring the long-term stability of node operation.

[0114] The technical solution of this invention receives a service request sent by a terminal device and predicts the basic data required to execute the service request. Further, based on the function information and resource requirements included in the basic data, and combined with the current status of several second servers, a target server is selected from several second servers. A processing instruction including function information and the service request is sent to the target server, enabling the target server to retrieve and load the method function corresponding to the function information from the central database and then execute the service request. Compared with existing distributed microservice architectures, firstly, because the basic data required to execute the service request is predicted, including function information and resource requirements, a data foundation can be provided for subsequent selection of a suitable target server. Secondly, because the selection of the target server fully considers function information, resource requirements, and the current status of each second server, the target server can meet the resource requirements for executing the service request while improving resource utilization and response time. Thirdly, after the target server retrieves and loads the method function corresponding to the function information from the central database according to the processing instruction, it executes the service request locally on the target server, reducing network communication overhead. Furthermore, the method function is centrally stored in the central database for management and maintenance, which significantly reduces operational complexity.

[0115] Figure 6 This is a schematic diagram of the structure of a request processing device provided in an embodiment of the present invention. Figure 6 As shown, the device includes: a communication module 601, a prediction module 602, and a scheduling module 603.

[0116] Communication module 601 is used to receive service requests sent by terminal devices;

[0117] The prediction module 602 is used to predict the basic data required to execute the service request, wherein the basic data includes function information and resource requirements;

[0118] The scheduling module 603 is used to select a target server from several second servers based on function information, resource requirements, and the current status of several second servers.

[0119] The communication module 601 is also used to send processing instructions, including function information and service requests, to the target server, so that the target server can retrieve and load the method function corresponding to the function information from the central database and then execute the service request.

[0120] Optionally, the prediction module 602 is specifically used to parse the service request and extract the feature elements of the service request; input the feature elements into a pre-set first prediction model to obtain function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; and determine the resource requirements based on the function information.

[0121] Optionally, the prediction module 602 is specifically used to obtain the feature vector of the service request; classify the feature vector to obtain function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; and determine the resource requirements based on the function information.

[0122] Optionally, the scheduling module 603 is specifically used to obtain the current status of each second server, wherein the current status includes the current available resources and the list of currently loaded functions; select the second server whose current available resources are greater than or equal to the resource requirement as a candidate server; and determine the target server based on the function information and the list of currently loaded functions of the candidate server.

[0123] Optionally, the scheduling module 603 is specifically used to, for each candidate server, calculate the function download and loading latency corresponding to the candidate server based on the function information and the list of currently loaded functions of the candidate server; determine the processing latency of the candidate server for processing service requests based on the attribute information and the current available resources of the candidate server; calculate the total latency corresponding to the candidate server based on the function download and loading latency and the processing latency; and determine the target server based on the total latency corresponding to all candidate servers.

[0124] Optionally, the processing instructions also include an uninstallation instruction, which instructs the target server to uninstall the function to be uninstalled; the scheduling module 603 is also used to determine the function to be uninstalled based on the target server's currently loaded function list and preset resource management rules.

[0125] Optionally, the communication module 601 is also used to receive the processing results sent by the target server and send the processing results to the terminal device.

[0126] The request processing apparatus provided in the embodiments of the present invention can execute the request processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0127] Figure 7 This is a schematic diagram of the structure of a first server provided in an embodiment of the present invention. Figure 7As shown, the first server 10 includes at least one processor 11 and a memory, such as a read-only memory 12 or a random access memory 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 12 or loaded from storage unit 18 into the random access memory 13. The random access memory 13 may also store various programs and data required for the operation of the first server 10. The processor 11, read-only memory 12, and random access memory 13 are interconnected via a bus 14. An input / output interface 15 is also connected to the bus 14.

[0128] Multiple components in the first server 10 are connected to the input / output interface 15, including: an input unit 16, such as a keyboard, mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, optical disk, etc.; and a communication unit 19, such as a network card, modem, wireless transceiver, etc. The communication unit 19 allows the first server 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0129] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as request processing methods.

[0130] In some embodiments, the request processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the first server 10 via read-only memory 12 and / or communication unit 19. When the computer program is loaded into random access memory 13 and executed by processor 11, one or more steps of the request processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the request processing method by any other suitable means (e.g., by means of firmware).

[0131] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), systems-on-a-chip (SoCs), payload programmable logic devices, computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0132] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0133] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (or flash memory), optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0134] To provide interaction with a user, the systems and techniques described herein can be implemented on a first server, which includes: a display device (e.g., a cathode ray tube or liquid crystal display) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the first server. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including voice input, speech input, or tactile input).

[0135] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0136] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0137] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the request processing method provided in any embodiment of this invention.

[0138] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0139] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0140] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A request processing method, characterized in that, Applied to a first server, the method includes: Receive service requests sent by terminal devices; Predict the basic data required to execute the service request, wherein the basic data includes function information and resource requirements; Based on the function information, the resource requirements, and the current status of several second servers, a target server is selected from the several second servers; A processing instruction including the function information and the service request is sent to the target server, so that the target server retrieves and loads the method function corresponding to the function information from the central database and then executes the service request.

2. The request processing method according to claim 1, characterized in that, The basic data required to predict and execute the service request includes: Parse the service request and extract its feature elements; The feature elements are input into a pre-set first prediction model to obtain the function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; Based on the function information, determine the resource requirements.

3. The request processing method according to claim 1, characterized in that, The basic data required to predict and execute the service request includes: Obtain the feature vector of the service request; The feature vector is classified to obtain the function information, wherein the function information includes the function name and its corresponding version number, as well as the function call path; Based on the function information, determine the resource requirements.

4. The request processing method according to claim 1, characterized in that, The step of selecting a target server from the plurality of second servers based on the function information, the resource requirements, and the current status of the plurality of second servers includes: Obtain the current status of each second server, wherein the current status includes the amount of currently available resources and the list of currently loaded functions; Select a second server whose current available resources are greater than or equal to the resource requirement as a candidate server; The target server is determined based on the function information and the list of currently loaded functions of the candidate servers.

5. The request processing method according to claim 4, characterized in that, The step of determining the target server based on the function information and the list of currently loaded functions of the candidate servers includes: For each candidate server, the function download and loading latency corresponding to the candidate server is calculated based on the function information and the list of currently loaded functions of the candidate server. Based on the attribute information of the candidate server and the current available resources, determine the processing latency of the candidate server for processing the service request; Calculate the total latency corresponding to the candidate server based on the function download and loading latency and the processing latency; The target server is determined based on the total latency corresponding to all candidate servers.

6. The request processing method according to claim 4, characterized in that, The processing instruction also includes an uninstallation instruction, which instructs the target server to uninstall the function to be uninstalled. Before sending the processing instruction including the function information and the service request to the target server, the method further includes: The function to be uninstalled is determined based on the currently loaded function list of the target server and the preset resource management rules.

7. The request processing method according to claim 1, characterized in that, After sending a processing instruction including the function information and the service request to the target server, the method further includes: Receive the processing result sent by the target server; The processing result is sent to the terminal device.

8. A first server, characterized in that, The first server includes: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the request processing method according to any one of claims 1-7.

9. A request processing system, characterized in that, It includes the first server as described in claim 8, a central database, and several second servers.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the request processing method according to any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the request processing method according to any one of claims 1-7.

Images