CN110247984B - Service processing method, device and storage medium - Google Patents

Service processing method, device and storage medium Download PDF

Info

Publication number
CN110247984B
CN110247984B CN201910569286.8A CN201910569286A CN110247984B CN 110247984 B CN110247984 B CN 110247984B CN 201910569286 A CN201910569286 A CN 201910569286A CN 110247984 B CN110247984 B CN 110247984B
Authority
CN
China
Prior art keywords
coroutine
service
context information
service request
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910569286.8A
Other languages
Chinese (zh)
Other versions
CN110247984A (en
Inventor
成贤斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201910569286.8A priority Critical patent/CN110247984B/en
Publication of CN110247984A publication Critical patent/CN110247984A/en
Application granted granted Critical
Publication of CN110247984B publication Critical patent/CN110247984B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/567Integrating service provisioning from a plurality of service providers

Abstract

The application discloses a service processing method, a service processing device and a storage medium, and relates to the technical field of internet. In the application, after the first coroutine sends a data acquisition request to the second process, the first process can be switched from the first coroutine to the second coroutine, and current state information of the first coroutine is stored. Because the first coroutine does not process other services after the first coroutine finishes sending the data acquisition request, subsequently, when receiving the service data returned by the second process, the first coroutine can be switched back from the second coroutine according to the current state information of the first coroutine, and the service data is continuously processed. Therefore, it can be seen that the first coroutine only executes the code corresponding to the service request. Therefore, the codes corresponding to the service requests are complete instead of fragmented, so that the service requests are easier to read and maintain, and the maintenance cost is reduced. Moreover, because the code is not fragmented, the complexity of the business processing logic is reduced, and the code writing difficulty is reduced.

Description

Service processing method, device and storage medium
Technical Field
The present application relates to the field of internet technologies, and in particular, to a method and an apparatus for processing a service, and a storage medium.
Background
Currently, a variety of application clients are generally installed in a terminal. The application client may send a service request to the application server, and after receiving the service request, the application server may process the service request and return a corresponding processing result.
In the related art, a first process for processing a service request exists in an application server. The first process may receive a plurality of service requests from different application clients and asynchronously process the plurality of service requests. For example, when processing a first service request, if a first process needs to request data from a second process, the first process may send a data acquisition request to the second process according to the first service request, where the data acquisition request may carry user state information corresponding to the first service request. After the data acquisition request is sent, the first process will continue to process other service requests, and after the second process returns service data carrying user state information, the first process can acquire the service data through a callback function and return the service data to the corresponding application client according to the user state information.
It can be seen that, in the related art, the code for processing the first service request in the first process is fragmented, not easy to read and has high maintenance cost. Moreover, because the code is fragmented and the code blocks are isolated from each other, the business processing logic of the first process is complex, which results in a difficult code writing.
Disclosure of Invention
The embodiment of the application provides a service processing method, a service processing device and a storage medium, which can be used for solving the problems that in the related art, codes corresponding to service requests which are asynchronously realized and need to acquire data in a cross-process mode are fragmented, reading is not easy, maintenance is not easy, and compiling difficulty is high. The technical scheme is as follows:
in one aspect, a method for processing a service is provided, where the method includes:
sending a data acquisition request to a second process through a first coroutine, wherein the first coroutine is a coroutine distributed for a service request in the first process;
switching from the first coroutine to a second coroutine, and storing the current state information of the first coroutine, wherein the second coroutine is a coroutine distributed for other service requests in the first process;
when receiving the service data returned by the second process, switching from the second process to the first process according to the current state information of the first process;
and processing the service data through the first coroutine.
In another aspect, a traffic processing apparatus is provided, and the apparatus includes:
the system comprises a sending module, a receiving module and a sending module, wherein the sending module is used for sending a data acquisition request to a second process through a first coroutine in a first process, and the first coroutine is a coroutine distributed for a service request in the first process;
a switching module, configured to switch from the first coroutine to a second coroutine, and store current state information of the first coroutine, where the second coroutine is a coroutine allocated to another service request in the first process;
the switching module is further configured to switch from the second coroutine to the first coroutine according to the current state information of the first coroutine when receiving the service data returned by the second process;
and the processing module is used for processing the service data through the first coroutine.
In another aspect, a business process apparatus is provided, the apparatus includes a processor and a memory, the memory stores at least one instruction, at least one program, a set of codes, or a set of instructions, and the instruction, the program, the set of codes, or the set of instructions is loaded and executed by the processor to implement the business process method.
In another aspect, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a set of codes, or a set of instructions is stored, which is loaded and executed by a processor to implement the above-mentioned business processing method.
In another aspect, a computer program product containing instructions is provided, which when run on a computer, causes the computer to perform the above-described business process method.
The beneficial effects brought by the technical scheme provided by the embodiment of the application at least comprise:
in the embodiment of the application, a data acquisition request is sent to the second process through the first coroutine, and then the first process can be switched from the first coroutine to the second coroutine, and current state information of the first coroutine is stored. Subsequently, when receiving the service data returned by the second process, the second process can be switched back to the first process according to the current state information of the first process, and the first process continues to process the service data. After the first coroutine finishes sending the data acquisition request, the first coroutine is switched to other coroutines after being stored with the current state information and without processing other services. Subsequently, after receiving the service data, the first coroutine is switched back to process the service data, so that the first coroutine is completely used for processing the service request, that is, the first coroutine only executes a code corresponding to the service request. Therefore, the codes corresponding to the service requests are complete instead of fragmented, so that the service requests are easier to read and maintain, and the maintenance cost is reduced. Moreover, because the codes are not fragmented any more and the code segments are not isolated from each other any more, the complexity of the business processing logic is reduced and the difficulty of code writing is reduced.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a processing flow chart of a mail reading service in the related art provided by an embodiment of the present application;
fig. 2 is an implementation environment diagram related to a service processing method provided in the embodiment of the present application;
fig. 3 is a schematic diagram of an application server provided in an embodiment of the present application;
fig. 4 is a flowchart of a service processing method according to an embodiment of the present application;
fig. 5 is a flowchart of another service processing method provided in the embodiment of the present application;
fig. 6 is a timing diagram illustrating processing of a service request for reading a mailing list according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of a service processing apparatus according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of an application server for performing service processing according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
Before explaining the embodiments of the present application in detail, an application scenario related to the embodiments of the present application will be described.
Generally, an application client installed in a terminal may request service data by sending a service request to an application server during operation. The application server may receive a plurality of service requests transmitted by a plurality of application clients installed on a plurality of terminals. In order to ensure the service processing speed, the first process currently processes a plurality of service requests in an asynchronous processing manner, because the first process for processing the service requests may need to acquire data across processes in the process of processing the service requests.
For example, fig. 1 shows a flow chart of a mail reading service in the related art. When reading the mail, the mobile game client a can send a service request for instructing to read the mail to the application server. After receiving the request, the first process in the application server for processing the mail reading service needs to cross processes to obtain a mail list from the database. In this case, the first process may execute the service code 1 to send a mail acquisition request to the database. After sending the mail acquisition request, the first process continues to process the service requests of other clients without suspending the operation to wait for the database to return the result. That is, the first process will continue to execute code following business code 1, which is not the code used to process the business request of client a. It follows that the first process is not the process that is fully used to process the service request of client a. In this case, the mail obtaining request needs to carry user status information to indicate which client sent the service request corresponds to the mail obtaining request. Subsequently, when the database returns the mail list, the user state information can be carried in the returned result. Thereafter, the first process may obtain the mailing list by executing the service code 2 and return the mailing list to the client a according to the user status information contained therein. After returning the mailing list to the client, the first process may execute the service code 3 to send a setting instruction for setting an identification bit indicating whether the mailing list is read in the database to the database. Similarly, in the process that the database sets the identification bit according to the setting instruction, the first process still does not pause, but continues to execute other codes. Subsequently, after the database returns the setting result, the first process needs to obtain the setting result returned by the database through the service code 4.
From the above analysis, it can be seen that under the existing asynchronous processing framework, the service code 1 and the service code 2 for processing the service request sent by the client a are isolated by other codes and lack of relation with each other. Similarly, service code 3 and service code 4 are also isolated. That is, the service code used to process the service request is fragmented. Just because the business code is fragmented, there is a lack of association between business codes 1 and 2, so the business layer needs to maintain user state information during interaction with the database. And, since the first process executes other codes after executing the service code 1, after the database returns the mailing list, the returned mailing list result needs to be obtained through the callback function of the service code 2. Similarly, after the database returns the setting result, it also needs to be acquired through the service code 4. Therefore, due to the fragmentation of the codes, the codes are not easy to read and difficult to maintain, the service layer needs to maintain the user state information, and the code needs to contain a callback function to acquire a processing result, so that the problems of complex processing logic and high code compiling difficulty are caused.
The service processing method provided by the embodiment of the present application can solve the problem of code fragmentation for processing the mail service in the above example. In addition, the service processing method provided in the embodiment of the present application may also be applied to a service system that needs to acquire data across processes in other asynchronous processing frameworks. For example, in a scenario where a mobile game client requests to create a game room, a business process requests other processes to create a game room and returns the results of creating the room.
Next, an implementation environment related to the embodiments of the present application will be described.
Fig. 2 is an implementation environment diagram related to a service processing method provided in the embodiment of the present application. As shown in fig. 2, the implementation environment includes a terminal 201 and an application server 202.
An application client is installed in the terminal 201, and the application client refers to a client having the application server 202 to provide services. The application client may be, for example, a game client, a music application client, a social application client, or other application clients, and the application is not limited to the kind of application client.
A first process for processing a service request sent by an application client installed in the terminal 201 exists on the application server 202. In addition, a second process may exist on the application server 202 that processes other information. The first process may include multiple coroutines, and each coroutine may process a service request by executing a complete code corresponding to the service request, and then return a service processing result to the application client. It should be noted that only one coroutine can be run in the first process at the same time. In addition, a coroutine pool is arranged in the first process. During each coroutine processing service request, data may be requested from a second process across processes. After the second process does not return the service data, the corresponding coroutine can be hung and stored to the coroutine pool, the current state information of the corresponding coroutine is stored to the coroutine pool, after the service data returned by the second process is received, the corresponding coroutine can be recovered from the coroutine pool, and the service data is continuously processed according to the stored state information.
It should be noted that, as shown in fig. 3, the code of the mail service executed in the first process may be referred to as a service layer, and the multiple protocols and the set protocol pool in the first process may be referred to as a framework layer. In addition, a communication layer may be included in the framework layer.
It should be noted that the terminal 201 may be an intelligent terminal such as a smart phone, a tablet computer, a laptop computer, and a desktop computer. The application server 202 may be one server or a server cluster formed by multiple servers, which is not limited in this embodiment of the present application.
Next, a service processing method provided in the embodiment of the present application is introduced.
Fig. 4 is a flowchart of a service processing method according to an embodiment of the present application. The method may be applied to a first process on the application server shown in fig. 2, and referring to fig. 4, the method includes:
step 401: and sending a data acquisition request to a second process through a first co-process, wherein the first co-process is a co-process distributed for the service request in the first process.
In the embodiment of the application, a first process for processing a certain type of service request exists on the application server. The first process may include a plurality of coroutines. The multiple coroutines may include a main coroutine, and each coroutine except the main coroutine may be configured to process a service request. It should be noted that the master coroutine may be a coroutine used in the first process to implement scheduling of other coroutines.
When an application client requests a service from an application server, the application client may send a service request to the application server. The first process may receive the service request through the master coroutine and allocate a coroutine to the service request. The service request refers to a service request which needs to acquire service data in a cross-process manner.
Illustratively, the master coroutine of the first process may detect whether an idle coroutine exists in a plurality of coroutines included in the first process; if no idle coroutine exists in a plurality of coroutines included in the first process, creating one coroutine, and taking the created coroutine as the first coroutine; if the first process comprises a plurality of co-processes with idle co-processes, selecting one co-process from the idle co-processes as the first co-process.
Wherein, the idle coroutines refer to unallocated coroutines. That is, the first process may search for whether an unallocated idle coroutine still exists from the plurality of coroutines through the master coroutine. If so, the found free coroutines can be allocated to the service request. If no undistributed free coroutines exist, the second process can create a new coroutine through the main coroutine and distribute the created coroutine to the service request. It should be noted that, after a new coroutine is created, the master coroutine may also allocate a corresponding coroutine identifier to the created new coroutine.
After allocating the coroutines for the service request, the first process may suspend the master coroutine, store the master coroutine in the coroutine pool, and store context information of the master coroutine in the coroutine pool. Then, the first process may start a first co-process, execute the service code of the service request through the first co-process, and check whether the parameter carried in the service request is legal through the first co-process. The parameters carried in the service request may be user information, a service identifier, and the like of the application client that sends the service request, which is not limited in this embodiment of the present application. After the first process successfully verifies the parameters carried in the service request through the first co-program, the first process can send a data acquisition request to the second process through the first co-program. Wherein the data acquisition request is used for requesting service data from the second process. And the data acquisition request carries the protocol identification of the first protocol. The coroutine identifier of the first coroutine may uniquely identify the first coroutine.
It should be noted that each coroutine has its own register context and stack. In this embodiment, the context information of the master coroutine may refer to a register context and a stack of the master coroutine before the master coroutine is suspended. The register context and stack may be used to indicate where the master coroutine has run when suspended.
The following is a code segment for implementing that a first process allocates a coroutine for a service request and performs parameter checking through the first coroutine, which is exemplarily given in the embodiment of the present application.
Figure BDA0002110516220000071
Step 402: and switching from the first coroutine to the second coroutine, and storing the current state information of the first coroutine.
After the first process sends the data acquisition request to the second process through the first coroutine, the second process needs time to acquire and return the service data, so the first process can be switched from the first coroutine to the second coroutine, and current state information of the first coroutine is stored.
Illustratively, the first process may suspend the first coroutine and deposit the first coroutine to the coroutine pool. Meanwhile, the first process may use context information of the first coroutine when sending the data acquisition request as current state information of the first coroutine, and store the current state information of the first coroutine in the coroutine pool. Thereafter, the first process may initiate a second coroutine to effect a switch between the first coroutine and the second coroutine.
In this embodiment of the present application, the context information when the first coroutine sends the data acquisition request may refer to a register context and a stack of the first coroutine when the data acquisition request is sent. At this time, the register context and stack can indicate the running state of the first coroutine, that is, which position of the service code the first coroutine is currently running to. In this way, when subsequently switching to the first protocol again, the first protocol can then continue to operate from the corresponding location according to the status information.
After the first coroutine is put into the coroutine pool and the current state information of the first coroutine is stored, the first process may obtain the aforementioned master coroutine and the stored context information of the master coroutine from the coroutine pool. As can be seen from the foregoing description, the context information of the master co-program refers to the register context and stack of the master co-program when the master co-program is suspended, and may be used to indicate to which location the master co-program runs when the master co-program is suspended. Based on this, after the context information of the main coroutine is acquired, the first process may restart the main coroutine according to the context information of the main coroutine, so that the main coroutine continues to run from a position to which the main coroutine runs when being suspended last time based on the context information. In this way, the first process returns control to the master coroutine. Next, the master coroutine may initiate a second coroutine. The second coroutine may be a coroutine allocated by the first process for other service requests.
It should be noted that, in the process of starting the second coroutine by the master coroutine, reference may be made to the implementation process of starting the first coroutine by the first process through the master coroutine in the foregoing embodiment, which is not described herein again in this embodiment of the present application.
Alternatively, if the second coroutine is a coroutine that has been previously suspended and is stored in the coroutine pool, the first process may refer to the aforementioned process of recovering the master coroutine from the coroutine pool, and recover the second coroutine through the master coroutine, so that the second coroutine continues to run from the position to which it ran when it was last suspended.
Optionally, in a possible implementation manner, the second coroutine may be a master coroutine. In this case, the implementation manner of switching from the first coroutine to the second coroutine is the aforementioned process of switching from the first coroutine to the main coroutine, and the embodiments of the present application are not described herein again.
Step 403: and when receiving the service data returned by the second process, switching from the second process to the first process according to the current state information of the first process.
After switching from the first coroutine to the second coroutine, the first process may process other traffic through the second coroutine. In this process, the second process may obtain corresponding service data according to the received data obtaining request, and then return the service data to the first process.
As can be seen from the introduction in step 401, the data acquisition request carries the coroutine identifier of the first coroutine. When the second process returns the service data, the second process may carry the protocol identifier of the first protocol in the service data.
After receiving the service data returned by the second process, the first process may obtain the protocol identifier of the first protocol from the service data. Then, the first process may obtain the first coroutine and current state information of the first coroutine from the coroutine pool according to the coroutine identifier of the first coroutine.
It should be noted that, in the coroutine pool, a coroutine identifier, a mapping relationship between coroutines and coroutine state information is stored. Based on this, the first process may obtain the coroutine and the state information corresponding to the coroutine identifier of the first coroutine from the mapping relationship, where the obtained coroutine is the first coroutine and the current state information of the first coroutine.
After the state information of the first coroutine and the first coroutine is acquired, the first process can suspend the second coroutine which is currently running, and store the current state information of the second coroutine and the second coroutine into a coroutine pool; and restarting the first coroutine according to the current state information of the first coroutine.
Illustratively, the first process may suspend the second coroutine, putting it into the coroutine pool. And simultaneously, the register context and the stack of the second coroutine at the current moment are used as the current state information of the second coroutine to be stored in the coroutine pool. Then, if the second coroutine is the main coroutine, the first coroutine may be rerun according to the obtained current state information of the first coroutine. Since the current state information of the first coroutine is the register context and stack when the first coroutine is suspended after the acquisition request is sent, which can be used to indicate to which position of the service code the first coroutine is running when the first coroutine is suspended last time, when the first process runs the first coroutine according to the context information, the first coroutine enters the state when the data acquisition request is sent last time, that is, the coroutine continues to run from the position where the first coroutine was running when the first coroutine was suspended last time.
It should be noted that, if the second coroutine is a coroutine corresponding to another service request, after the suspension of the second coroutine is put into the coroutine pool and the current state information of the second coroutine is stored in the coroutine pool, the first process may refer to the method described in the foregoing embodiment to recover the main coroutine from the coroutine pool. The master coroutine of the first process may then re-enable the first coroutine according to the first coroutine and the current state information of the first coroutine, as described above with reference to the method.
After the first coroutine is restarted, the first process may delete information corresponding to the first coroutine in the mapping relationship stored in the coroutine pool.
The following provides implementation code for switching from the first coroutine to the master coroutine after allocating the first coroutine to the service request, and then switching back from the master coroutine to the first coroutine.
Figure BDA0002110516220000091
Figure BDA0002110516220000101
Figure BDA0002110516220000111
In the embodiment of the application, after the first coroutine sends the data acquisition request, the first coroutine is suspended and stored in the coroutine pool, and the state information of the first coroutine when suspended is also stored in the coroutine pool. In this way, subsequent to receiving the returned service data, the first coroutine may be restored directly from the coroutine pool to continue executing subsequent service code. Because the first co-program can be directly recovered according to the co-program identifier of the first co-program, so that the first co-program can continue to run downwards from the running position when the first co-program is suspended last time, even if the data acquisition request sent to the second process and the service data returned by the second process do not carry user state information, the first co-program can learn the application client corresponding to the service data according to the context information after recovery. That is, the service layer does not need to maintain user state information. In addition, the first process does not need to acquire the service data returned by the second process through a callback function, so that the service processing logic is simplified, the code amount is reduced, and the code compiling difficulty is reduced.
Step 404: and processing the service data through the first protocol.
After the first coroutine is re-run, the first process can continue to perform subsequent processing on the service data through the first coroutine, and returns a processing result to the client corresponding to the service request.
It should be noted that, if the service data returned by the second process is the service data requested by the application client, the first process may directly return the service data to the client through the first protocol.
Fig. 5 exemplarily shows a system flow chart of a service processing method applied to the foregoing system architecture shown in fig. 2. Referring to fig. 5, an application client sends a service request. And the first process in the application server receives the service request through the main coroutine and searches whether an idle coroutine exists at present. If the first coroutine exists, acquiring an idle coroutine as the first coroutine, and if the first coroutine does not exist, creating a new coroutine as the first coroutine. And finally, parameter checking is carried out through the first co-program, and the first co-program is enabled to execute the service code so as to send a data acquisition request to the second process. And suspending the coroutine and putting the coroutine into a coroutine pool to wait for the second process to return the service data. And after the service data is returned, recovering the first coroutine from the coroutine pool so as to enable the first coroutine to continuously run according to the stored context information.
In the embodiment of the application, a data acquisition request may be sent to the second process through the first coroutine, and then, the first process may be switched from the first coroutine to the second coroutine, and current state information of the first coroutine is stored. Subsequently, when receiving the service data returned by the second process, the second process can be switched back to the first process according to the current state information of the first process, and the first process continues to process the service data. After the first coroutine finishes sending the data acquisition request, the first coroutine is switched to other coroutines after being stored with the current state information and without processing other services. Subsequently, after receiving the service data, the first coroutine is switched back to process the service data, so that the first coroutine is completely used for processing the service request, that is, the first coroutine only executes a code corresponding to the service request. Therefore, the codes corresponding to the service requests are complete instead of fragmented, reading and maintenance are easier, maintenance cost is reduced, and service updating iteration is facilitated. Moreover, because the codes are not fragmented any more and the code segments are not isolated from each other any more, the complexity of the business processing logic is reduced and the difficulty of code writing is reduced.
In some embodiments, the service processing method described above may be applied to a process in which the application server processes a service request for reading a mailing list sent by the game client. Fig. 6 shows a timing diagram of the processing of the service request using the method described above. As shown in fig. 6, after receiving a service request sent by a game client, a service process in an application server for processing a mail service may allocate a coroutine, that is, a first coroutine, to the service request. Then, the first coroutine may perform parameter verification, execute the code 601 in the service code corresponding to the service request, and send a data acquisition request to the database. After the data acquisition request is sent, the first coroutine is suspended and put into a coroutine pool, and meanwhile, the current state information of the first coroutine is stored into the coroutine pool. That is, the first coroutine will suspend execution of other code in the business code after code 601. And then, when the database returns the mail list, the first process recovers the first coroutine from the coroutine pool and switches the context information into the stored context information of the first coroutine. Thus, the first coroutine will continue to run from code 602 after code 601. The mailing list is returned to the corresponding application client by executing code 602. The first coroutine may then execute the code 603 to send setup instructions to the database. After sending the setting instruction, the first process may suspend the first coroutine again, place the first coroutine in the coroutine pool, and save the state information of the first coroutine at this time. After the database returns the set result, the first process may recover the first coroutine from the coroutine pool, and at this time, the first coroutine may end the operation or perform other processing according to the set result.
As can be seen from the above process, when the method provided in the embodiment of the present application is used for processing a service request of a game client for reading an email, no other code of the service request exists between the code 601 and the code 602, that is, the service code corresponding to the service request is complete, is not fragmented, and is easier to read and maintain. Moreover, because the service code is complete, and the context information of the first protocol is recorded every time the first protocol is suspended, the data acquisition request sent by the first protocol to the database does not need to carry the user state information of the game client, and correspondingly, the database does not carry the user state information in the service data. In addition, the first coroutine does not execute other codes after sending the data acquisition request, but waits for the second process to return data, and the first coroutine can continue to run next to the original position because the context information of the first coroutine is stored, so that a callback function does not need to be written in the code 602, the service processing logic is simplified, the code amount is reduced, and the code writing difficulty is reduced.
The following provides codes for processing the mail reading service by using the service processing method.
Figure BDA0002110516220000131
As can be seen from the above codes, the coroutine in the framework layer may suspend to be put into the coroutine pool after the code of the mailing list is acquired in the business layer. After receiving the mailing list, the coroutines in the framework layer may be restored from the coroutine pool (resume), executing code that checks the mailing list and returns it to the client. And then, the coroutine in the framework layer executes the code with the set identification bit, suspends the code after the execution and stores the code into the coroutine pool, and recovers the coroutine pool after receiving the returned set result.
In some possible embodiments, the mail reading service may be reading an article mail. In this case, after receiving a setting result returned by the database for indicating that the item has been picked up, the framework layer protocol may further execute a code for sending a delete command to the database to delete the corresponding mailing list. After sending the delete command, the coroutine of the framework layer will suspend storing into the coroutine pool again. And then, after receiving a deletion success message returned by the database, recovering the coroutine from the coroutine pool to execute subsequent codes. Illustratively, the code of the business process described above is as follows:
Figure BDA0002110516220000132
Figure BDA0002110516220000141
next, a service processing apparatus provided in an embodiment of the present application is described.
Referring to fig. 7, an embodiment of the present application provides a service processing apparatus 700, where the apparatus 700 includes:
a sending module 701, configured to send a data acquisition request to a second process through a first coroutine in a first process, where the first coroutine is a coroutine allocated to a service request in the first process;
a switching module 702, configured to switch from a first coroutine to a second coroutine, store current state information of the first coroutine, where the second coroutine is a coroutine allocated to another service request in the first process;
the switching module 702 is further configured to switch from the second protocol to the first protocol according to the current state information of the first protocol when receiving the service data returned by the second process;
the processing module 703 is configured to process the service data through the first coroutine.
Optionally, the switching module 702 includes:
the first suspending submodule is used for suspending the first coroutine and storing the first coroutine to the coroutine pool;
the storage submodule is used for taking the context information when the data acquisition request is sent by the first coroutine as the current state information of the first coroutine and storing the current state information of the first coroutine in the coroutine pool;
and the starting submodule is used for starting the second coordination process.
Optionally, the switching module 702 further includes:
the second suspending submodule is used for suspending the second coroutine and storing the second coroutine and the current state information of the second coroutine into a coroutine pool;
and the restarting submodule is used for restarting the first coroutine according to the current state information of the first coroutine.
Optionally, the data acquisition request and the service data both carry a protocol identifier of the first protocol;
the apparatus 700 further comprises:
and the acquisition module is used for acquiring the first coroutine and the current state information of the first coroutine from the coroutine pool according to the coroutine identifier of the first coroutine.
Optionally, the apparatus 700 is further configured to:
detecting whether an idle coroutine exists in a plurality of coroutines included in a first process;
if no idle coroutine exists in a plurality of coroutines included in the first process, creating one coroutine, and taking the created coroutine as the first coroutine;
if the first process comprises a plurality of co-processes with idle co-processes, selecting one co-process from the idle co-processes as the first co-process.
To sum up, in the embodiment of the present application, a data acquisition request may be sent to a second process through a first coroutine, and then, the first process may be switched from the first coroutine to the second coroutine, and current state information of the first coroutine is stored. Subsequently, when receiving the service data returned by the second process, the second process can be switched back to the first process according to the current state information of the first process, and the first process continues to process the service data. After the first coroutine finishes sending the data acquisition request, the first coroutine is switched to other coroutines after being stored with the current state information and without processing other services. Subsequently, after receiving the service data, the first coroutine is switched back to process the service data, so that the first coroutine is completely used for processing the service request, that is, the first coroutine only executes a code corresponding to the service request. Therefore, the codes corresponding to the service requests are complete instead of fragmented, so that the service requests are easier to read and maintain, and the maintenance cost is reduced. Moreover, because the codes are not fragmented any more and the code segments are not isolated from each other any more, the complexity of the business processing logic is reduced and the difficulty of code writing is reduced.
It should be noted that: in the service processing apparatus provided in the foregoing embodiment, when detecting a character string, only the division of each function module is described as an example, and in practical applications, the function distribution may be completed by different function modules according to needs, that is, the internal structure of the device is divided into different function modules, so as to complete all or part of the functions described above. In addition, the service processing apparatus and the service processing method provided by the above embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments for details, which are not described herein again.
Fig. 8 is a schematic structural diagram of an application server provided in this embodiment of the present application, where the application server 800 may generate a relatively large difference due to different configurations or performances, and may include one or more processors (CPUs) 801 and one or more memories 802, where the memory 802 stores at least one instruction, and the at least one instruction is loaded and executed by the processor 801 to implement the business processing method in the foregoing embodiment. Certainly, the application server 800 may further have components such as a wired or wireless network interface, a keyboard, and an input/output interface, so as to perform input and output, and the application server 800 may further include other components for implementing device functions, which are not described herein again.
In an exemplary embodiment, a computer readable storage medium is also provided, in which at least one instruction, at least one program, set of codes, or set of instructions is stored, which is loaded and executed by a processor to implement the above-mentioned business processing method. For example, the computer-readable storage medium may be a ROM (Read-only memory), a RAM (random access memory), a CD-ROM (Compact Disc Read-only memory), a magnetic tape, a floppy disk, an optical data storage device, and the like.
It is noted that the computer-readable storage medium referred to herein may be a non-volatile storage medium, in other words a non-transitory storage medium.
It should be understood that all or part of the steps for implementing the above embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The computer instructions may be stored in the computer-readable storage medium described above.
That is, in an exemplary embodiment, there is also provided a computer program product containing instructions which, when run on a computer, cause the computer to perform the above-described business process method.
It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.
The above description is only exemplary of the present application and should not be taken as limiting, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims (8)

1. A service processing method is applied to a first process, the first process comprises a plurality of coroutines, the plurality of coroutines comprise a main coroutine, and the main coroutine is used for scheduling other coroutines, and the method comprises the following steps:
receiving a service request sent by an application client through the main coroutine, and distributing a first coroutine to the service request, wherein parameters carried by the service request comprise user information of the application client;
executing the service code of the service request through the first co-program to verify that the parameter carried by the service request is legal, and sending a data acquisition request to a second process after the verification is successful, wherein the data acquisition request carries the co-program identifier of the first co-program;
switching from the first coroutine to a second coroutine, and storing context information when the first coroutine sends the data acquisition request, wherein the second coroutine is a coroutine distributed for other service requests in the first process;
when business data returned by the second process is received, acquiring context information of the first coroutine according to a coroutine identifier of the first coroutine, and switching from the second coroutine to the first coroutine according to the context information of the first coroutine, wherein the business data is data corresponding to the data acquisition request and carries the coroutine identifier of the first coroutine;
and determining the application client corresponding to the service data according to the context information of the first protocol, and returning the service data to the application client through the first protocol.
2. The method according to claim 1, wherein the switching from the first protocol to the second protocol, saving context information when the first protocol sends the data acquisition request, comprises:
suspending the first coroutine and storing the first coroutine to a coroutine pool;
storing context information of the first coroutine in the coroutine pool;
and starting the second coroutine.
3. The method of claim 2, wherein switching from the second protocol to the first protocol according to the context information of the first protocol comprises:
suspending the second coroutine and storing the second coroutine and the context information of the second coroutine to the coroutine pool;
and restarting the first coroutine according to the context information of the first coroutine.
4. A method according to any of claims 1-3, wherein said allocating a first protocol to said service request comprises:
detecting whether an idle coroutine exists in a plurality of coroutines included in the first process;
if no idle coroutine exists in a plurality of coroutines included in the first process, creating one coroutine, and taking the created coroutine as the first coroutine;
if an idle coroutine exists in a plurality of coroutines included in the first process, selecting one coroutine from the idle coroutines as the first coroutine.
5. A traffic processing apparatus, characterized in that the apparatus comprises:
the system comprises a sending module, a processing module and a processing module, wherein the sending module is used for executing a service code of a service request sent by an application client through a first co-program in a first process so as to verify that parameters carried by the service request are legal, and sending a data acquisition request to a second process after the verification is successful, the first co-program is a co-program distributed for the service request in the first process, the data acquisition request carries a co-program identifier of the first co-program, the first process comprises a plurality of co-programs, the plurality of co-programs comprise a main co-program, and the main co-program is used for scheduling other co-programs;
a switching module, configured to switch from the first coroutine to a second coroutine, and store context information when the first coroutine sends the data acquisition request, where the second coroutine is a coroutine allocated to another service request in the first process;
the switching module is further configured to, when receiving service data returned by the second process, acquire context information of the first coroutine according to a coroutine identifier of the first coroutine, and switch from the second coroutine to the first coroutine according to the context information of the first coroutine, where the service data is data corresponding to the data acquisition request and carries the coroutine identifier of the first coroutine;
the processing module is used for determining the application client corresponding to the service data according to the context information of the first coroutine and returning the service data to the application client through the first coroutine;
the apparatus is further configured to: and receiving a service request sent by an application client through the main coroutine, and distributing a first coroutine to the service request, wherein parameters carried by the service request comprise user information of the application client.
6. The apparatus of claim 5, wherein the switching module comprises:
the first suspending submodule is used for suspending the first coroutine and storing the first coroutine to a coroutine pool;
the storage submodule is used for storing the context information of the first coroutine in the coroutine pool;
and the starting submodule is used for starting the second coroutine.
7. The apparatus of claim 6, wherein the switching module further comprises:
the second suspending submodule is used for suspending the second coroutine and storing the second coroutine and the context information of the second coroutine into the coroutine pool;
and the restarting submodule is used for restarting the first coroutine according to the context information of the first coroutine.
8. A computer-readable storage medium, having stored therein at least one instruction, at least one program, a set of codes, or a set of instructions, which is loaded and executed by a processor to implement a business process method according to any one of claims 1 to 4.
CN201910569286.8A 2019-06-27 2019-06-27 Service processing method, device and storage medium Active CN110247984B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910569286.8A CN110247984B (en) 2019-06-27 2019-06-27 Service processing method, device and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910569286.8A CN110247984B (en) 2019-06-27 2019-06-27 Service processing method, device and storage medium

Publications (2)

Publication Number Publication Date
CN110247984A CN110247984A (en) 2019-09-17
CN110247984B true CN110247984B (en) 2022-02-22

Family

ID=67889939

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910569286.8A Active CN110247984B (en) 2019-06-27 2019-06-27 Service processing method, device and storage medium

Country Status (1)

Country Link
CN (1) CN110247984B (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110990667B (en) * 2019-10-29 2023-06-23 内蒙古大学 Multi-end college student electronic file management system based on cooperative distance technology
CN110825455A (en) * 2019-10-31 2020-02-21 郑州悉知信息科技股份有限公司 Application program running method, device and system
CN111659126B (en) * 2020-07-08 2023-03-03 腾讯科技(深圳)有限公司 Distribution method, device, server, terminal and storage medium of matching process
CN111913792B (en) * 2020-07-17 2023-12-01 郑州阿帕斯数云信息科技有限公司 Service processing method and device
CN112052008B (en) * 2020-09-10 2022-02-18 腾讯科技(深圳)有限公司 Code checking method, device, computer equipment and computer readable storage medium
CN112162840B (en) * 2020-09-29 2024-03-08 曹蕤 Coroutine processing and management method based on interrupt reentry mechanism
CN112286595A (en) * 2020-10-30 2021-01-29 深圳市九九互动科技有限公司 Asynchronous processing method and device of Lua language, computer equipment and storage medium
CN115426403A (en) * 2022-08-23 2022-12-02 奇安信网神信息技术(北京)股份有限公司 Data processing method and device, electronic equipment and storage medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2217998A4 (en) * 2007-10-25 2014-07-23 Microsoft Corp Techniques for switching threads within routines
CN106980546A (en) * 2016-01-18 2017-07-25 阿里巴巴集团控股有限公司 A kind of task asynchronous execution method, apparatus and system
CN107147641A (en) * 2017-05-10 2017-09-08 深圳市万游引力科技有限公司 A kind of information processing method, system and computer-readable storage medium
CN109213591A (en) * 2017-06-30 2019-01-15 合网络技术(北京)有限公司 Assist the distribution method and device of journey running stack
CN109885386A (en) * 2019-01-03 2019-06-14 北京潘达互娱科技有限公司 A kind of method, apparatus and electronic equipment of multitask execution

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10747511B2 (en) * 2015-04-28 2020-08-18 Microsoft Technology Licensing, Llc Compiler optimization of coroutines
CN105760237B (en) * 2016-02-05 2019-03-22 南京贝伦思网络科技股份有限公司 A kind of means of communication based on association's journey mechanism
CN107992344B (en) * 2016-10-25 2021-03-02 腾讯科技(深圳)有限公司 Coroutine implementation method and coroutine implementation device
CN109726102A (en) * 2018-05-14 2019-05-07 网联清算有限公司 Flow pressure test method and device
CN109739482B (en) * 2018-12-28 2022-04-15 杭州东信北邮信息技术有限公司 Service logic execution system and method based on dynamic language

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2217998A4 (en) * 2007-10-25 2014-07-23 Microsoft Corp Techniques for switching threads within routines
US10007551B2 (en) * 2007-10-25 2018-06-26 Microsoft Technology Licensing, Llc Techniques for switching threads within routines
CN106980546A (en) * 2016-01-18 2017-07-25 阿里巴巴集团控股有限公司 A kind of task asynchronous execution method, apparatus and system
CN107147641A (en) * 2017-05-10 2017-09-08 深圳市万游引力科技有限公司 A kind of information processing method, system and computer-readable storage medium
CN109213591A (en) * 2017-06-30 2019-01-15 合网络技术(北京)有限公司 Assist the distribution method and device of journey running stack
CN109885386A (en) * 2019-01-03 2019-06-14 北京潘达互娱科技有限公司 A kind of method, apparatus and electronic equipment of multitask execution

Also Published As

Publication number Publication date
CN110247984A (en) 2019-09-17

Similar Documents

Publication Publication Date Title
CN110247984B (en) Service processing method, device and storage medium
US11809901B2 (en) Migrating the runtime state of a container between two nodes
CN109032796B (en) Data processing method and device
CN111124286A (en) Libcloud-based multi-cloud management implementation method
CN111800468A (en) Cloud-based multi-cluster management method, device, medium and electronic equipment
CN112328365A (en) Virtual machine migration method, device, equipment and storage medium
US10318343B2 (en) Migration methods and apparatuses for migrating virtual machine including locally stored and shared data
US10579419B2 (en) Data analysis in storage system
US20200371827A1 (en) Method, Apparatus, Device and Medium for Processing Data
CN113014608A (en) Flow distribution control method and device, electronic equipment and storage medium
CN110798358B (en) Distributed service identification method and device, computer readable medium and electronic equipment
CN112631994A (en) Data migration method and system
CN112243030A (en) Data synchronization method, device, equipment and medium of distributed storage system
CN111767126A (en) System and method for distributed batch processing
CN115454971A (en) Data migration method and device, electronic equipment and storage medium
CN115238006A (en) Retrieval data synchronization method, device, equipment and computer storage medium
CN110059080B (en) Data processing method and device
US11121981B1 (en) Optimistically granting permission to host computing resources
CN109478151B (en) Network accessible data volume modification
CN112445571A (en) Virtual machine migration and management method, server and computer readable storage medium
CN111666338B (en) Data replication method, control node and electronic equipment
CN112596855B (en) Container creation method and device
KR101542605B1 (en) Parallel processing apparatus and processing apparatus for semantic heterogeneity of ontology matching
US11379147B2 (en) Method, device, and computer program product for managing storage system
CN110046192B (en) System and method for generating serial number of request information

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant