WO2020233206A1 - Method and device for processing code execution request - Google Patents

Abstract

The present application relates to the field of financial technology (fintech), and provides a method and a device for processing a code execution request, used to address the problem in the art of laborious user operations during code processing. The method comprises: receiving a code execution request sent by a client end, the code execution request comprising code requested by the user for execution; selecting, according to N pre-determined rules, a session from a total session list corresponding to the user for executing the code execution request, wherein the total session list comprises all corresponding sessions of the user in an engine service, and N is a positive integer; and sending the code requested by the user for execution to the session used to execute the code execution request. The invention selects, by means of the N pre-determined rules, a suitable session for a code execution request, and submits the code execution request to said session, such that users do not need to be concerned with information such as the number of sessions in an engine service, and do not need to specify a session, thereby simplifying user operations.

Description

Method and device for processing code execution request

Cross references to related applications

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on May 20, 2019, the application number is 201910419110.4, and the application name is "a method and device for processing code execution requests", the entire contents of which are incorporated by reference In this application.

Technical field

This application relates to the technical field of Fintech, and in particular to a method and device for processing code execution requests.

Background technique

With the development of computer technology, more and more technologies are applied in the financial field. The traditional financial industry is gradually transforming to the financial technology (Fintech) field. However, due to the security and real-time requirements of the financial industry, more technology is also proposed. High demands. The financial industry (such as banking, insurance, and securities) generally involves scripting on big data platforms. The script job of the big data platform is generally that the user sends code fragments to the engine server through the client, and the code is executed by the session on the engine server.

The existing method of processing code execution requests is roughly as follows: a user submits a code execution request on the client, the forwarding service submits the code execution request to the session specified by the code execution request, and then the specified session executes the code submitted by the user.

However, in this way of processing code execution requests, users need to log in to various engine server accounts to obtain their corresponding sessions in various engine services, and then determine which engine service to choose according to the required code execution request, and then determine the Which session in the engine service the code execution request is submitted to, and finally the code execution request is submitted to the engine service through the client, and the engine service sends the code execution request to the user code execution request after receiving the code execution request The session specified in. It can be seen that the existing method of processing code execution requests has a technical problem that user operations are extremely cumbersome.

Summary of the invention

This application provides a method and device for processing code execution requests, which are used to simplify user operations when processing code execution requests.

In a first aspect, a method for processing code execution requests is provided, which is applied to an intermediate proxy server, and the intermediate proxy server is in communication connection with the client and engine services in the engine server, and the method includes:

Receiving a code execution request sent by the client, where the code execution request includes the code requested to be executed by the user;

According to the preset N rules, from the total conversation list corresponding to the user, the conversations used to execute the code execution request are filtered out; wherein, the total conversation list includes the corresponding user in the engine service All conversations of, N is a positive integer;

Send the code requested to be executed by the user to the session for executing the code execution request.

In this application, after receiving the code execution request, the intermediate proxy server can screen a suitable session for the code execution request through preset N rules, and submit the code execution request to the session, compared to the current one. According to the technology, the user selects the way of specifying the session. In the embodiment of the present application, the user does not need to pay attention to the number of sessions in the engine service, and there is no need for the user to specify the session, thereby simplifying the user's operation and improving the user experience. Moreover, in this application, the intermediate proxy server can filter out corresponding sessions from multiple sessions according to N rules, so that the intermediate proxy server has higher flexibility in selecting sessions.

In a possible implementation manner, the filtering out the session for executing the code execution request from the total session list corresponding to the user according to preset N rules includes: corresponding to the user The total conversation list of is passed through K rules in order to filter out the conversations used to execute the code execution request; wherein, the K rules are the first K of the N rules arranged from high to low according to the preset priority Rule, K is a positive integer less than or equal to N.

In the above implementation, the N rules are first sorted according to the preset priority, and then when the intermediate proxy server screens the sessions according to the N rules, the first K rules with higher priority are used to filter out the first K rules that satisfy the first K rules. As the only session for executing the code execution request, on the one hand, it ensures that the corresponding session can be screened out every time, and on the other hand, it can also ensure that the screened out session can meet the higher priority rules, thus guaranteeing to a certain extent The reliability of the conversation.

In a possible implementation manner, the N rules include one or more of health state rules, concurrency rules, load rules, designated session rules, blacklist session rules, and priority session rules; among them, all The health status rule refers to the selection of sessions whose health status is normal, the concurrency rule refers to the selection of sessions whose current concurrency number is less than the maximum concurrency number, and the load rule refers to the selection of a load that is higher than the expected load within a preset first time period. It is assumed that the maximum duration of the load is lower than the preset second duration of the session, the first duration is greater than the second duration, and the specified session rule refers to selecting the session specified in the code execution request, the The blacklist session rule refers to the selection of sessions other than the sessions in the preset blacklist. The priority session rule refers to arranging multiple sessions in order of preset priority from high to low, and selecting the session with the highest priority .

In the foregoing implementation manner, there may be multiple possibilities for the N rules. If the N rules are different, the screened sessions will be different accordingly. In this way, the flexibility of the intermediate proxy server for selecting sessions can be further improved.

In a possible implementation manner, after receiving the code execution request from the client, the code execution request is encapsulated as a task, and the task identification code ID is assigned to the task, and the task ID is stored in the relationship Correspondingly, after the code requested to be executed by the user is sent to the session for executing the code execution request, the session information corresponding to the session for executing the code execution request is combined with the task ID The corresponding relationship is updated to the relational database, and the session used to execute the code execution request is obtained from the engine service according to the session information corresponding to the session used to execute the code execution request to execute the task And then feed back the status information to the client.

In the above implementation, after the intermediate proxy server allocates a session for each code execution request, the corresponding relationship between the session and the task ID that the session needs to be executed can be stored in a relational database. This is not only convenient for the intermediate proxy server to determine in time The task volume of each session also facilitates the intermediate proxy server to follow up the execution progress of each task in time; and, after the intermediate proxy server follows up the execution progress of each task, it feeds back the status information to the client in time, so that the user can obtain the code in time The progress of the operation further enhances the user experience.

In a possible implementation manner, before filtering out the session for executing the code execution request from the total session list corresponding to the user according to the preset N rules, the method further includes: receiving at least one engine The registration information sent by each engine service in the service; wherein the registration information includes the resource locator URL, service type, and service metadata information of each engine service; further, according to the registration information, the Each engine service sends a first heartbeat; according to the information fed back by each engine service for the first heartbeat, a session list corresponding to each engine service is obtained.

In the above implementation, the intermediate proxy server will receive the registration information sent by each engine service in advance, and after obtaining the registration information of each engine service, obtain the session list corresponding to each engine service from each engine service, so as to facilitate the management of the intermediate proxy server Sessions under each engine service.

In a possible implementation manner, before filtering out the session for executing the code execution request from the total session list corresponding to the user according to preset N rules, the method further includes: A session list corresponding to each engine service, send a second heartbeat to each session in the session list corresponding to each engine service, and send a second heartbeat to each session in the session list corresponding to each engine service. The heartbeat feedback information determines the health status of each session in the session list corresponding to each engine service.

In the foregoing implementation manner, by sending a heartbeat to each session in the session list corresponding to each engine service, the health status of each session can be determined in time, which facilitates subsequent screening of the sessions whose health status is normal for code execution requests. Moreover, the intermediate proxy server manages each session, which can also reduce the burden on the engine server.

In a second aspect, a device for processing code execution requests is provided. A client communicates with an engine service in an engine server through the device, and the device includes:

The receiving module is configured to receive a code execution request sent by the client, where the code execution request includes the code requested to be executed by the user;

The session screening module is configured to screen out the sessions used to execute the code execution request from the total session list corresponding to the user according to preset N rules; wherein, the total session list includes the user's current For all the corresponding sessions in the engine service, N is a positive integer;

The sending module is configured to send the code requested to be executed by the user to the session for executing the code execution request.

In a possible implementation, the session screening module is specifically configured to: sequentially pass the total session list corresponding to the user through K rules to filter out the sessions used to execute the code execution request; wherein, the K The rules are the first K rules arranged from high to low among the N rules according to the preset priority, and K is a positive integer less than or equal to N.

In a possible implementation manner, the N rules include one or more of health state rules, concurrency rules, load rules, designated session rules, blacklist session rules, and priority session rules; among them, all The health status rule refers to the selection of sessions whose health status is normal, the concurrency rule refers to the selection of sessions whose current concurrency number is less than the maximum concurrency number, and the load rule refers to the selection of a load that is higher than the expected load within a preset first time period. Assuming that the maximum duration of the load is lower than the preset second duration of the session, the first duration is greater than the second duration, and the specified session rule refers to selecting the session specified in the code execution request, so The blacklist session rule refers to the selection of sessions other than the sessions in the preset blacklist, and the priority session rule refers to arranging multiple sessions in order of preset priority from high to low, and selecting the one with the highest priority Conversation.

In a possible implementation manner, the device further includes a session management module; the receiving module is further configured to encapsulate the code execution request into a task after receiving the code execution request of the client, and perform the The task assignment task identification code ID is stored in a relational database; correspondingly, the session management module is configured to send the code requested by the user to be executed by the sending module to the user After the session for executing the code execution request is executed, the correspondence between the session information corresponding to the session for executing the code execution request and the task ID is updated to the relational database, and the code execution is executed according to the The session information corresponding to the requested session is used to obtain the status information of the task performed by the session used to execute the code execution request from the engine service; the sending module is also used to feed back the status information to the Client.

In a possible implementation manner, the device further includes a session registration module; the receiving module filters out the total session list corresponding to the user according to the preset N rules for executing the Before the session of the code execution request, it is also used to receive registration information sent by each engine service in at least one engine service; wherein the registration information includes the resource locator URL, service type, and service metadata of each engine service Correspondingly, the sending module is also used to send a first heartbeat to each engine service according to the registration information; the session registration module is used to send a first heartbeat to the first engine service according to the each engine service Obtain the session list corresponding to each engine service based on the information fed back by the heartbeat.

In a possible implementation manner, the device further includes a session health status determination module; the sending module is further configured to filter out from the total session list corresponding to the user according to preset N rules Before the session used to execute the code execution request, according to the session list corresponding to each engine service, send a second heartbeat to each session in the session list corresponding to each engine service; accordingly, the The session health status determination module is configured to determine each session in the session list corresponding to each engine service according to the information fed back to the second heartbeat for each session in the session list corresponding to each engine service Health status.

In a third aspect, a computing device is provided, including:

At least one processor, and

A memory connected in communication with the at least one processor;

Wherein, the memory stores instructions that can be executed by the at least one processor, and the at least one processor implements any one of the first aspect and any possible implementation manner by executing the instructions stored in the memory The method described.

In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer instructions. When the computer instructions run on a computer, the computer executes the first aspect and any possible design The method of any one of.

Description of the drawings

FIG. 1 is a schematic diagram of an applicable system architecture provided by an embodiment of the application;

2 is a schematic diagram of a brief process of processing a code execution request provided by an embodiment of the application;

3 is a schematic diagram of an interaction flow corresponding to a method for processing code execution requests provided by an embodiment of the application;

4 is a schematic structural diagram of an apparatus for processing code execution requests provided by an embodiment of the application;

FIG. 5 is a schematic structural diagram of a computing device provided by an embodiment of this application.

Detailed ways

In order to better understand the technical solutions provided by the embodiments of the present application, a detailed description will be given below in conjunction with the accompanying drawings of the specification and specific implementation manners.

The financial industry (such as banking, insurance, and securities) generally involves scripting on big data platforms. The script job of the big data platform is generally that the user sends code fragments to the engine server through the client, and the code is executed by the session on the engine server. In the existing methods of processing code execution requests, user operations are extremely cumbersome, and it is difficult to meet the actual business needs of banks and other financial industries.

In view of this, an embodiment of the present application proposes a method for processing code execution requests.

The application scenarios involved in this method are described below.

FIG. 1 is a schematic diagram of an applicable system architecture provided by an embodiment of the application. As shown in FIG. 1, the system architecture includes a client 11, an intermediate proxy server 12, and an engine server 13. Among them, the client 11 communicates with the engine server 13 through the intermediate proxy server 12. It should be noted that the intermediate proxy server 12 may be a single server or a server cluster, and the engine server 13 may be a single server or a server cluster, which is not limited.

Based on the system architecture shown in Figure 1, the interaction process between the various devices under the system architecture is described below. It should be noted that, in the following embodiments of the present application, the type of engine service is equivalent to the type of engine server, and the engine services corresponding to a type of engine server all belong to the same type.

Based on the system architecture shown in FIG. 1, FIG. 2 is a schematic diagram of a brief process of processing a code execution request provided by an embodiment of the application. As shown in Figure 2, multiple engine services (ie multiple engine servers, such as Spark engine server 131 and Python engine server 132) are set in the engine server 13, and each engine service corresponds to multiple sessions. One session can be understood as A lightweight application, a session can run code alone.

It should be noted that, in FIG. 2, the engine server 13 includes the Spark engine server 131 and the Python engine server 132 as an example, but in fact, the type of the engine server 13 is not limited, and the type of engine service is also not limited.

Please continue to refer to Figure 1 and Figure 2 below to briefly describe the interaction process between each device in this application scenario.

Specifically, the user sends a code execution request through the client 11. After the client 11 receives the code execution request, it sends the code execution request to the intermediate proxy server 12. The intermediate proxy server 12 screens out the corresponding sessions for the code execution request, and then The code execution request is sent to the corresponding session in the engine server, and the corresponding code of the user is executed by the corresponding session.

Based on the system architecture shown in FIG. 1, FIG. 3 is a schematic diagram of an interaction flow corresponding to a method for processing code execution requests provided by an embodiment of the application.

In step 301, the intermediate proxy server 12 receives a code execution request from the client 11, and the code execution request includes the code requested to be executed by the user.

Specifically, when a user wants to use the engine server 13 to execute code, the user can submit a code execution request through the client 11, the client 11 sends the code execution request to the intermediate proxy server 12, and the intermediate proxy server 12 receives the code sent by the client 11. Code execution request.

In a possible implementation manner, the intermediate proxy server 12 includes multiple intermediate proxy services. In order to avoid excessive load of a certain proxy service, the intermediate proxy server 12 allocates code execution requests of different users to different users in a polling manner. Each intermediate agent service is processed to try to ensure the load balance of each intermediate agent service.

The code execution request includes the code requested by the user to execute. The code execution request may also include the engine service type. The engine service type refers to the engine service type designated by the user to execute the code execution request. For example, the user specifies that the code execution request is sent to the Python engine service for execution. The code execution request may also include a session identification code (identification, ID) specified by the user.

For example, the client may send the code execution request to the intermediate proxy server 12 in a Representational State Transfer (REST) manner.

Step 302: Encapsulate the code execution request as a task, assign a task ID to the task, and store the task ID in a relational database.

Specifically, in order to facilitate the later identification of the code execution request of each user and the different code execution request of each user, after receiving each code execution request, the intermediate proxy server 12 encapsulates each code execution request, and then performs a processing for each code execution request. The code execution request assigns the corresponding task ID. In order to facilitate the intermediate proxy server 12 to obtain the task ID of each task, the task ID of each task and the state information corresponding to the task may be stored in a relational database. The status information of the task includes one or more of the execution progress of the task, the running intermediate parameters of the code, and the final result of the task processing. For example, the current task has not been executed yet, then the execution progress of the task can be identified as pending.

Among them, the relational database may be a database in the intermediate proxy server 12 or a database that exists separately in other servers. When the relational database is a database that exists separately in other servers, the relational database and the intermediate proxy server 12 can communicate with each other.

For example, the intermediate proxy server 12 receives three code execution requests sent by three users, and can encapsulate the three code execution requests into corresponding tasks, assign corresponding IDs, and store them in a relational database. In this way, the contents of the relational database are shown in Table 1 below.

Table 1

Task ID	task progress
1	Pending
2	Pending
3	Pending

In step 303, the intermediate proxy server 12 receives registration information from the engine service in the engine server 13.

Specifically, there are many types of engine services. Whenever a new engine service needs to access the intermediate proxy server 12, it can send registration information to the intermediate proxy server 12. After the intermediate proxy server 12 receives the registration information, it indicates that The new engine service has been successfully registered.

Among them, the registration information includes the resource locator (Uniform Resource Locator, URL), service type and service metadata information of the engine service. Service metadata information can be understood as some fixed parameters of the engine service, for example, which types of code can be run in the session in the engine service, and which users have the authority to use the engine service, etc.

Step 304: After receiving the registration information, the intermediate proxy server 12 sends the first heartbeat to the engine service.

Specifically, after the new engine service accesses the intermediate proxy server 12, the intermediate proxy service 12 may send a first heartbeat to the engine service according to the registration information, and the first heartbeat is used to confirm whether the engine service is running normally.

Step 305: The intermediate proxy server 12 receives the information for the first heartbeat feedback sent by the engine service.

Specifically, after receiving the first heartbeat, the engine service sends information for the first heartbeat feedback to the intermediate proxy server 12, and the information for the first heartbeat feedback includes session information corresponding to at least all sessions included in the engine service. The session information includes the session ID of each session, and the session information may also include the maximum concurrent number of each session.

Step 306: The intermediate proxy server 12 obtains a session list corresponding to the engine service according to the information fed back for the first heartbeat.

After the intermediate proxy server 12 receives the information for the first heartbeat feedback, it can obtain the session list of the engine service. The session list includes session IDs of all sessions included in the engine service. The session list can also include the maximum number of concurrent sessions.

It should be noted that the embodiment of step 303 to step 306 provides a way to obtain the session list of each engine service. Step 303 to step 306 are executed after step 302 as an example in FIG. 3, but in fact, step 303 to step 306 can also be executed before step 301 or before step 302.

After obtaining the session list of each engine service, the intermediate proxy server 12 can obtain the total session list corresponding to the user. The user's total conversation list can be understood as the conversations in all engine services for which the user has usage rights. The user's total conversation list generally includes multiple conversations.

Among them, as discussed in step 303 above, when each engine service is created, the service metadata information includes which users have the authority to use the engine service. After the intermediate proxy server 12 obtains the session list of each engine service, it It is possible to determine whether the user has the permission to use the corresponding session in the engine service according to the service metadata information of the engine service, and then determine the total session list corresponding to the user.

In a possible implementation manner, in order to facilitate the intermediate proxy server 12 to obtain the session list of each engine service, the intermediate proxy server 12 may store the session list in a relational database.

For example, after obtaining the session list of the Spark engine service and the session list of the Python engine service, the intermediate proxy server 12 stores the session list of the Spark engine service and the session list of the Python engine service in a relational database. In this way, the contents of the relational database are shown in Table 2 below.

Table 2

Step 307: The intermediate proxy server 12 sends a second heartbeat to the sessions in the session list served by each engine.

Specifically, after obtaining the session list of each engine service, the intermediate proxy server 12 sends the second heartbeat to each session in the session list. The intermediate proxy server 12 may periodically send the second heartbeat to the sessions in the session list corresponding to all engine services. In order to reduce the burden of the intermediate proxy server 12, the intermediate proxy server 12 may also send a second heartbeat to the sessions in the session list corresponding to all engine services after receiving the code execution request.

Among them, the second heartbeat is used to confirm the health status of the session, and the health status can be understood as whether the session can run normally. Each session has a certain life cycle. Some sessions may be stopped due to the expiration of the life cycle, or they may be stopped artificially, or they may exit abnormally due to a memory overflow, etc., resulting in abnormal health status of some sessions.

In step 308, the intermediate proxy server 12 receives the information fed back by the engine service for the second heartbeat, and determines the health status of each session according to the information.

Specifically, after each session receives the second heartbeat, if the session is in a normal working state, each session can feed back information to the intermediate proxy server 12 in a timely manner, and the intermediate proxy server 12 receives the second heartbeat of the session within a preset period of time. The heartbeat feedback information determines that the health status of the session is normal. If the session is abnormal, it may not be able to feed back to the intermediate proxy server 12 in time. The intermediate proxy server 12 does not receive the second heartbeat feedback information of the session within the preset time period, and then determines that the health status of the session is abnormal, so that the intermediate proxy server 12 The server 12 can obtain the health status of each session.

In a possible implementation manner, in order to facilitate the intermediate proxy server 12 to obtain the health status of each session in a timely manner, the health status of each session may also be updated to the relational database.

For example, continuing to take the session shown in Table 2 as an example, if the intermediate proxy server 12 determines that session 1 is abnormal, and session 2, session 3, and session 4 are normal, it can update the current health status of each session to the relational database in time in.

In the embodiment discussed in step 307 to step 308, the intermediate proxy server 12 can determine the health status of each session in time, so as to facilitate the screening of corresponding sessions for subsequent code execution requests.

In step 309, the intermediate proxy server 12 filters out the sessions used to execute the code execution request from the total session list according to the N rules.

Specifically, there may be more than one session in the user's total session list. Therefore, after receiving the code execution request sent by the client 11, the intermediate proxy server 12 selects one session from the total session list according to N rules for execution. Code execution request.

In the following, an example will be described for the manner in which the intermediate proxy server 12 filters out the sessions for executing the code execution request from the total session list according to N rules.

method one:

The intermediate proxy server 12 passes the total conversation list corresponding to the user through K rules in turn, and filters out the conversations used to execute the code execution request. The K rules are the top K of the N rules arranged from high to low according to the preset priority. A rule, K is a positive integer less than or equal to N.

Specifically, the intermediate proxy server 12 can arrange N rules in order from high to low according to the preset priority. If the total conversation list is filtered by the first K rules, there is only one session that meets the first K rules. Then the session is the session used to execute the code execution request, and the session can no longer be screened by the following (NK) rules.

The preset priority order of the N rules may be set by the user. In this case, the priority order of the N rules corresponding to different users may be different. For example, the user can carry the preset priority order of N rules in the code execution request. Alternatively, the preset priority order of the N rules may also be set by the intermediate proxy server 12 by default.

In the embodiment of this application, by sorting the N rules, and taking a session that meets the first K rules with higher priority as the session for executing the code execution request, it can ensure that the corresponding one can be filtered out every time On the other hand, it can also ensure that the selected sessions meet the higher priority rules.

Way two:

The intermediate proxy server 12 filters out the sessions meeting the N rules from the total session list as the sessions for executing the code execution request.

Specifically, if the intermediate proxy server 12 wants to filter out the sessions that satisfy N rules at the same time from the session list, it may appear that all the sessions in the session list do not meet the N rules. In this case, the intermediate proxy server 12 may The notification engine service creates a new session for the code execution request, and uses the newly created session as the session for executing the current code execution request.

In the embodiment of the present application, the selected session strictly meets the N rules, so as to ensure the quality of the session and improve the reliability of the code execution request in the later stage of the session.

In a possible implementation manner, in either the second mode or the first mode, multiple sessions satisfying N or K rules may be screened out. In this way, the intermediate proxy server 12 may select multiple sessions satisfying N or K rules. Any one of the sessions is selected to execute the code execution request, or the session with the highest priority can be selected from multiple sessions satisfying N or K rules to execute the code execution request. The highest priority refers to the priority of the session The highest in the order.

Among them, the priority order of the sessions may be set by the intermediate proxy server 12 by default, or the intermediate proxy server 12 may be determined according to the average length of code execution of each session, for example, according to the execution of each task in each session within the set time period in the past. The average duration is determined. Among them, the shorter the average duration of the session execution code, the higher the priority corresponding to the session.

In the embodiment of this application, the N rules can be understood as a set of preset rules for filtering out conversations from the total conversation list. The N rules include one or more of the following (1) to (8) . The eight rules are briefly described below.

(1) The health status rule refers to the selection of sessions whose health status is normal.

Specifically, when the intermediate proxy server 12 filters the sessions that meet the health state rules from the total session list, it needs to determine the health status of each session in the total session list. As discussed above in step 307 to step 308, the intermediate proxy server 12 can obtain the latest health status of each session through a relational database to determine the health status of each session.

In the embodiment of this application, the selection of the session whose health status is normal is compared with the way in which the user specifies the session in the prior art, which not only simplifies the user's operation, but also ensures that the session used to execute the code execution request is normal , To ensure the reliability of the subsequent session.

(2) Concurrency rules refer to the selection of sessions whose current concurrent number is less than the maximum concurrent number.

When the intermediate proxy server 12 filters the sessions meeting the concurrency rule from the total session list, it needs to determine the current number of concurrent sessions for each session.

Exemplarily, the intermediate proxy server 12 may send confirmation information to each session in real time. The confirmation information is used to confirm the current number of concurrent sessions of each session. After the intermediate proxy server 12 obtains the feedback information of each session for the confirmation information, The feedback information of each session determines the current concurrent number of each session.

Or, as discussed in step 302 above, the intermediate proxy server 12 stores the session and the number of tasks corresponding to the session in the relational database after allocating the session for each code execution request. In this way, when the current concurrency number of each session needs to be determined, the intermediate proxy server 12 may first obtain the number of tasks corresponding to each session according to the relational database, and after obtaining the number of tasks corresponding to the session, the current number of concurrent sessions can be obtained. Generally speaking, if a session only processes one task, the number of concurrent sessions for that session is one.

After obtaining the current concurrency number of each session, the intermediate proxy server 12 can determine whether the current concurrency number of each session is less than the maximum concurrency number according to the maximum concurrency number of each session in the session list.

In the embodiment of this application, by selecting the session whose current concurrent number is less than the maximum concurrent number, it can be ensured that after the code execution request is sent to the session, the session can respond to the code execution request in a timely manner, thereby improving the timeliness of processing the code execution request , To enhance the user experience.

(3) The load rule refers to the selection of sessions in which the maximum duration in which the load amount is higher than the preset load amount in the preset first duration is lower than the preset second duration, and the first duration is greater than the second duration.

When the intermediate proxy server 12 filters the sessions that meet the load rule from the total session list, it needs to determine the load of each session in the first time period, and the load can be characterized by the number of tasks. As discussed in step 302 above, after the intermediate proxy server 12 allocates sessions for each code execution request, the session and the number of tasks corresponding to the session are stored in the relational database. After each session completes the corresponding task, it can also report completion. Information to the intermediate proxy server 12. In this way, the intermediate proxy server 12 can also update the task quantity of each session in the relational database in a timely manner based on the feedback completion information. When it is necessary to determine the load of each session in the first time period, the intermediate proxy server 12 can obtain the load of each session in real time according to the relational database, and then determine that the load in the first preset time period is higher than the preset load. The maximum duration of. If the maximum duration is less than the second duration, it means that the load of the session can process the corresponding task in time, and the code execution request can be allocated to the session at this time. If the maximum duration is greater than the second duration, it means that the load of the session remains high. At this time, you can refuse to assign the code execution request to the task, thereby avoiding the user's code caused by assigning the code execution request to the task. Issue of extension when executing request.

In the embodiments of the present application, by screening out the sessions that meet the load rules, not only the user's code execution request can be processed in time, but also the load balance of each session can be ensured as much as possible.

(4) Specifying the session rule refers to selecting the session specified in the code execution request. The session specified in the code execution request can be one or multiple.

(5) Blacklist session rules refer to the selection of sessions other than those in the preset blacklist. The sessions in the blacklist preset in the blacklist session rule can be carried in the code execution request by the user. Among them, the corresponding sessions in the blacklist corresponding to each user may be different or the same.

(6) The priority conversation rule refers to arranging multiple conversations in the order of preset priority from high to low, and selecting the conversation with the highest priority. Among them, the way to set the preset priority of the session can refer to the content discussed above, and will not be repeated here.

In the embodiment of the present application, when multiple sessions meet certain rules in parallel, priority session rules can be used to select the session with the highest priority from the multiple sessions to ensure that a session with higher reliability is selected for the user.

(7) The engine service type rule refers to the selection of the session that matches the code type requested by the user.

As an embodiment, if the code execution request carries the engine service type, the intermediate proxy server 12 can assign a matching engine service to the code execution request according to the code execution request without setting engine type rules. If the code execution request does not carry the engine service type, the intermediate proxy server 12 may add an engine service type rule, so as to screen out matching engine service sessions for the code execution request based on the engine service type rule.

(8) The custom rule refers to the selection of the corresponding conversation according to the rule input by the user.

Specifically, the user may carry some filtering rules defined by himself in the code execution request. In this way, after receiving the code execution request, the intermediate proxy server 12 may determine the filtering rule in the code execution request as a rule for the user to screen the session.

The following is an example of the combination of the above (8) rules.

The N rules include health status rules, concurrency rules, load rules, designated session rules, blacklist session rules, and priority session rules. In this case, the sessions are filtered from the total session list according to the second method. Among them, the preset priority of the N rules can be: health state rule>concurrency rule>load rule>specified session rule>blacklist session rule>priority session rule.

Specifically, the intermediate proxy server 12 may first filter out the first session list whose health status is normal according to the health state rule, and then filter out the second session list whose current concurrent number is less than the maximum concurrent number from the first session list according to the concurrency rule. , And then filter from the second session list according to the load rule, and so on, until a session for executing the code execution request is filtered out.

It should be noted that the above-mentioned (8) rules can have many combinations, and this article will not list them all.

In step 310, the intermediate proxy server 12 sends the code requested by the user to be executed to the selected session.

Specifically, after the intermediate proxy server 12 screens out corresponding sessions according to N rules, it may send the code requested by the user to be executed to the screened session, and the session executes the code sent by the user.

In step 311, the intermediate proxy server 12 stores the correspondence between the screened session information and the task ID in a relational database.

Specifically, after determining the session corresponding to a certain task, the intermediate proxy server 12 may store the correspondence between the session information of the session and the task ID of the task in the relational database, and update the data in the relational database in time. It is convenient for the intermediate proxy server 12 to subsequently determine the number of tasks for each session.

In step 312, the intermediate proxy server 12 obtains task status information from the session.

Specifically, after the intermediate proxy server 12 submits the task to the session, the session may send to the intermediate proxy server 12 the status information of each task performed by the session at a preset time interval, so that the intermediate proxy server 12 can obtain the status information of the task. The intermediate proxy server 12 may also periodically inquire each session to obtain status information of the tasks performed by each session. The status information of the task can refer to the content discussed in step 302 above, which will not be repeated here.

In step 313, the intermediate proxy server 12 feeds back the status information of the task to the client 11.

After acquiring the status information of the task, the intermediate proxy server 12 can feed back the status information of the task to the client 11 in time. Alternatively, in order to save costs and update the progress of the task in time, the intermediate proxy server 12 may also store the status information of the task in a relational database, and periodically feedback the status information of each task to the client 11.

As an example, step 302 in FIG. 3 is an optional part, step 303-step 306 are optional part, step 307-step 308 are optional part, and step 311-step 313 are optional part. .

The embodiment of the application implements the above-mentioned method to realize timely processing of code execution requests in the financial industry such as banks. Users do not need to pay attention to information such as the number of sessions in the engine service, and do not need to specify sessions, thereby simplifying user operations , Improve user experience. In addition, the intermediate proxy server filters out corresponding sessions from multiple sessions according to N rules, which can also improve the flexibility of session selection.

On the basis of the method for processing code execution requests discussed above, an embodiment of the present application also provides a device for processing code execution requests, which is equivalent to the intermediate proxy server 12 in FIG. 3 above.

FIG. 4 is a schematic structural diagram of an apparatus for processing code execution requests provided by an embodiment of the application. As shown in FIG. 4, the apparatus includes:

The receiving module 401 is used to receive a code execution request sent by the client 11, the code execution request includes the code requested to be executed by the user; the content of the code execution request can refer to the content discussed in step 301 above, and will not be repeated here.

The session screening module 402 is used to screen out the sessions used to execute the code execution request from the total session list corresponding to the user according to the preset N rules; wherein, the total session list includes all the sessions corresponding to the user in the engine service , N is a positive integer; the content of the total conversation list and the N rules can refer to the content discussed in step 309 above, which will not be repeated here.

The sending module 403 is used to send the code requested by the user to be executed to the session for executing the code execution request.

In a possible implementation manner, the session screening module 402 is specifically configured to:

The total conversation list corresponding to the user is sequentially passed through K rules to filter out the conversations used to execute the code execution request; among them, the K rules are the first K rules arranged from high to low among the N rules according to the preset priority. , K is a positive integer less than or equal to N.

In a possible implementation, the N rules include: one or more of health state rules, concurrency rules, load rules, specified session rules, blacklist session rules, and priority session rules;

Among them, the health status rule refers to the selection of sessions whose health status is normal, the concurrency rule refers to the selection of sessions whose current concurrency number is less than the maximum concurrency number, and the load rule refers to the selection of which load is higher than the preset load in the preset first time period. The maximum duration of the session is lower than the preset second duration. The first duration is greater than the second duration. The specified session rule refers to the session specified in the code execution request, and the blacklist session rule refers to the selection except the preset blacklist For conversations other than medium conversations, the priority conversation rule refers to arranging multiple conversations in order from high to low according to the preset priority, and selecting the conversation with the highest priority.

In a possible implementation, the device further includes a session management module 404;

The receiving module 401 is also used to encapsulate the code execution request as a task after receiving the code execution request from the client, assign the task identification code ID to the task, and store the task ID in the relational database;

The session management module 404 is used to update the correspondence between the session information corresponding to the session used to execute the code execution request and the task ID after the sending module 403 sends the code requested to be executed by the user to the session used to execute the code execution request to Relational database, and according to the session information corresponding to the session used to execute the code execution request, obtain the state information of the session execution task used to execute the code execution request from the engine service;

The sending module 403 is also used to feed back status information to the client 11.

In a possible implementation manner, the device further includes a session registration module 405;

The receiving module 401 is also used to receive the registration sent by each engine service in at least one engine service before filtering out the session for executing the code execution request from the total session list corresponding to the user according to the preset N rules Information; where the registration information includes the resource locator URL, service type and service metadata information of each engine service;

The sending module 403 is also used to send the first heartbeat to each engine service according to the registration information;

The session registration module 405 is configured to obtain the session list corresponding to each engine service according to the information fed back by each engine service for the first heartbeat.

In a possible implementation, the device further includes a session health status determination module 406;

The sending module 403 is also used to filter out the sessions used to execute the code execution request from the total session list corresponding to the user according to preset N rules, and send each engine service the corresponding session list to each Each session in the session list corresponding to the engine service sends a second heartbeat;

The session health status determination module 406 is configured to determine the health status of each session in the session list corresponding to each engine service according to the information fed back to the second heartbeat for each session in the session list corresponding to each engine service.

On the basis of the method for processing code execution requests discussed above, an embodiment of the present application also provides a device for processing code execution requests, which is equivalent to the intermediate proxy server 12 discussed above.

FIG. 5 is a schematic structural diagram of a computing device provided by an embodiment of the application. As shown in FIG. 5, the device includes:

At least one processor 501, and

A memory 502 communicatively connected with at least one processor 501;

Wherein, the memory 502 stores instructions that can be executed by at least one processor 501, and the at least one processor 501 implements the method described in FIG. 3 by executing the instructions stored in the memory 502.

As an embodiment, the session management module 404, the session registration module 405, the session health status determination module 406, and the session screening module 402 in FIG. 4 may be implemented by the processor 501 in FIG.

Among them, the processor 501 is the control center of the intermediate proxy server 12, which can use various interfaces and lines to connect the various parts of the entire intermediate proxy server 12, by running or executing instructions stored in the memory 502 and calling The data is implemented as a function of filtering sessions for code execution requests and managing sessions.

Optionally, the processor 501 may include one or more processing units, and the processor 501 may integrate an application processor and a modem processor. The application processor mainly processes the operating system, user interface, and application programs. The adjustment processor mainly deals with wireless communication. It can be understood that the foregoing modem processor may not be integrated into the processor 501. In some embodiments, the processor 501 and the memory 502 may be implemented on the same chip, or may be implemented on separate chips.

The processor 501 may be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, Implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.

As a non-volatile computer-readable storage medium, the memory 502 can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The memory 502 may include at least one type of storage medium, for example, may include flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM) ), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic memory, magnetic disk, optical disk, etc. The memory 502 is any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. The memory 502 in the embodiment of the application may also be a circuit or any other device capable of realizing a storage function for storing program instructions and/or data.

On the basis of the method for processing code execution requests discussed above, an embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium stores computer instructions, when the computer instructions are on the computer When running, the computer is made to execute the method described in Figure 3.

Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

This application is described with reference to flowcharts and/or block diagrams of methods, equipment (systems), and computer program products according to the embodiments of this 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 equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.

Although the preferred embodiments of the present application have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

Obviously, those skilled in the art can make various changes and modifications to the application without departing from the spirit and scope of the application. In this way, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalent technologies, this application also intends to include these modifications and variations.

Claims (14)

1. A method for processing code execution requests, characterized in that it is applied to an intermediate proxy server, the intermediate proxy server is in communication connection with the client and engine services in the engine server, and the method includes:

   Receiving a code execution request sent by the client, where the code execution request includes the code requested to be executed by the user;

   According to the preset N rules, from the total conversation list corresponding to the user, the conversations used to execute the code execution request are filtered out; wherein, the total conversation list includes the corresponding user in the engine service All conversations of, N is a positive integer;

   Send the code requested to be executed by the user to the session for executing the code execution request.
2. The method according to claim 1, wherein the filtering out a session for executing the code execution request from a total session list corresponding to the user according to preset N rules, comprises:

   The total conversation list corresponding to the user is sequentially passed through K rules to filter out the conversations used to execute the code execution request; wherein, the K rules are the N rules from high to preset priority For the first K rules after the low ranking, K is a positive integer less than or equal to N.
3. The method according to claim 1 or 2, wherein the N rules include: one of health state rules, concurrency rules, load rules, designated session rules, blacklist session rules, and priority session rules, or Several

   Wherein, the health state rule refers to the selection of sessions whose health state is normal, the concurrency rule refers to the selection of sessions whose current concurrency number is less than the maximum concurrency number, and the load rule refers to the selection of a load within a preset first time period A session with a maximum duration that is higher than the preset load and lower than the preset second duration, and the first duration is greater than the second duration, and the specified session rule refers to selecting the session specified in the code execution request The blacklist session rule refers to selecting sessions other than the sessions in the preset blacklist, and the priority session rule refers to arranging multiple sessions in order of preset priority from high to low, and selecting the priority The highest conversation.
4. The method of claim 1, wherein:

   After receiving the code execution request from the client, encapsulate the code execution request as a task, assign a task identification code ID to the task, and store the task ID in a relational database;

   After the code requested to be executed by the user is sent to the session for executing the code execution request, the correspondence between the session information corresponding to the session for executing the code execution request and the task ID is updated to the Relational database;

   According to the session information corresponding to the session used to execute the code execution request, obtain the state information of the task executed by the session used to execute the code execution request from the engine service;

   Feed back the status information to the client.
5. The method according to claim 1, 2 or 4, characterized in that, according to the preset N rules, from the total conversation list corresponding to the user, the conversation used to execute the code execution request is filtered out. ,Also includes:

   Receiving registration information sent by each engine service in at least one engine service; wherein the registration information includes the resource locator URL, service type, and service metadata information of each engine service;

   Sending a first heartbeat to each engine service according to the registration information;

   Acquire the session list corresponding to each engine service according to the information fed back by each engine service for the first heartbeat.
6. The method according to claim 5, characterized in that, before filtering out the session for executing the code execution request from the total session list corresponding to the user according to preset N rules, the method further comprises:

   Sending a second heartbeat to each session in the session list corresponding to each engine service according to the session list corresponding to each engine service;

   Determine the health status of each session in the session list corresponding to each engine service according to the information fed back to the second heartbeat for each session in the session list corresponding to each engine service.
7. A device for processing code execution requests, characterized in that a client communicates with an engine service in an engine server through the device, and the device includes:

   The receiving module is configured to receive a code execution request sent by the client, where the code execution request includes the code requested to be executed by the user;

   The session screening module is configured to screen out the sessions used to execute the code execution request from the total session list corresponding to the user according to preset N rules; wherein, the total session list includes the user's current For all the corresponding sessions in the engine service, N is a positive integer;

   The sending module is configured to send the code requested to be executed by the user to the session for executing the code execution request.
8. The device according to claim 7, wherein the session screening module is specifically configured to:

   The total conversation list corresponding to the user is sequentially passed through K rules to filter out the conversations used to execute the code execution request; wherein, the K rules are the N rules from high to preset priority For the first K rules after the low ranking, K is a positive integer less than or equal to N.
9. The device according to claim 7 or 8, wherein the N rules comprise: one of health state rules, concurrency rules, load rules, designated session rules, blacklist session rules, and priority session rules, or Several

   Wherein, the health state rule refers to the selection of sessions whose health state is normal, the concurrency rule refers to the selection of sessions whose current concurrency number is less than the maximum concurrency number, and the load rule refers to the selection of a load within a preset first time period A session with a maximum duration that is higher than the preset load and lower than the preset second duration, and the first duration is greater than the second duration, and the specified session rule refers to selecting the session specified in the code execution request The blacklist session rule refers to selecting sessions other than the sessions in the preset blacklist, and the priority session rule refers to arranging multiple sessions in order of preset priority from high to low, and selecting the priority The highest conversation.
10. 8. The device of claim 7, wherein the device further comprises a session management module;

    The receiving module is further configured to encapsulate the code execution request as a task after receiving the code execution request from the client, assign a task identification code ID to the task, and store the task ID in a relational type In the database

    The session management module is configured to send the session information corresponding to the session used to execute the code execution request after the sending module sends the code requested to be executed by the user to the session used to execute the code execution request The corresponding relationship with the task ID is updated to the relational database, and the session information corresponding to the session used to execute the code execution request is obtained from the engine service. The status information of the session executing the task;

    The sending module is also used to feed back the status information to the client.
11. The device according to claim 7, 8 or 10, wherein the device further comprises a session registration module;

    The receiving module is further configured to receive each of at least one engine service before filtering out the session for executing the code execution request from the total session list corresponding to the user according to preset N rules. Registration information sent by the engine service; wherein the registration information includes the resource locator URL, service type, and service metadata information of each engine service;

    The sending module is further configured to send a first heartbeat to each engine service according to the registration information;

    The session registration module is configured to obtain the session list corresponding to each engine service according to the information fed back by each engine service for the first heartbeat.
12. The device of claim 11, wherein the device further comprises a session health status determination module;

    The sending module is further configured to filter out the session for executing the code execution request from the total session list corresponding to the user according to the preset N rules, according to the corresponding engine service To send a second heartbeat to each session in the session list corresponding to each engine service;

    The session health status determination module is configured to determine each session in the session list corresponding to each engine service according to the information feedback for the second heartbeat for each session in the session list corresponding to each engine service. The health status of each session.
13. A computing device, characterized by comprising:

    At least one processor, and

    A memory connected in communication with the at least one processor;

    Wherein, the memory stores instructions that can be executed by the at least one processor, and the at least one processor implements the method according to any one of claims 1-6 by executing the instructions stored in the memory.
14. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, when the computer instructions run on a computer, the computer executes any one of claims 1-6 Methods.

Images