业务处理方法、装置及存储介质与流程

本申请涉及互联网技术领域，特别涉及一种业务处理方法、装置及存储介质。

背景技术：

当前，终端中通常会安装有各种各样的应用客户端。应用客户端可以向应用服务器发送业务请求，应用服务器在接收到该业务请求之后，可以对该业务请求进行处理，并返回相应地处理结果。

相关技术中，应用服务器中存在用于对业务请求进行处理的第一进程。该第一进程可以接收来自不同应用客户端的多个业务请求，并对该多个业务请求进行异步处理。例如，在处理第一业务请求时，如果第一进程需要向第二进程请求数据，则第一进程可以根据第一业务请求向第二进程发送数据获取请求，该数据获取请求中可以携带有第一业务请求对应的用户状态信息。在发送数据获取请求之后，第一进程将会继续处理其他业务请求，待第二进程返回携带有用户状态信息的业务数据之后，该第一进程可以通过回调函数获取该业务数据，并根据该用户状态信息将该业务数据返回至对应的应用客户端。

由此可见，在相关技术中，第一进程中用于处理第一业务请求的代码是碎片化的，不易阅读且维护成本高。并且，由于代码是碎片化的，各个代码块之间彼此隔离，因此，第一进程的业务处理逻辑较为复杂，导致代码编写难度大。

技术实现要素：

本申请实施例提供了一种业务处理方法、装置及存储介质，可以用于解决相关技术中异步实现且需要跨进程获取数据的业务请求所对应的代码碎片化，不易阅读不易维护且编写难度较大的问题。所述技术方案如下：

一方面，提供了一种业务处理方法，所述方法包括：

通过第一协程向第二进程发送数据获取请求，所述第一协程是所述第一进程中为业务请求分配的协程；

从所述第一协程切换至第二协程，保存所述第一协程的当前状态信息，所述第二协程是所述第一进程中为其他业务请求分配的协程；

当接收到所述第二进程返回的业务数据时，根据所述第一协程的当前状态信息，从所述第二协程切换至所述第一协程；

通过所述第一协程对所述业务数据进行处理。

另一方面，提供了一种业务处理装置，所述装置包括：

发送模块，用于通过第一进程中的第一协程向第二进程发送数据获取请求，所述第一协程是第一进程中为业务请求分配的协程；

切换模块，用于从所述第一协程切换至第二协程，保存所述第一协程的当前状态信息，所述第二协程是所述第一进程中为其他业务请求分配的协程；

所述切换模块，还用于当接收到所述第二进程返回的业务数据时，根据所述第一协程的当前状态信息，从所述第二协程切换至所述第一协程；

处理模块，用于通过所述第一协程对所述业务数据进行处理。

另一方面，提供了一种业务处理装置，所述装置包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现上述业务处理方法。

另一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由处理器加载并执行以实现上述业务处理方法。

另一方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述业务处理方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

在本申请实施例中，通过第一协程向第二进程发送数据获取请求，之后，第一进程可以从第一协程切换至第二协程，并保存第一协程的当前状态信息。后续，当接收到第二进程返回的业务数据时，可以根据第一协程的当前状态信息，从第二协程切换回第一协程，由第一协程继续对业务数据进行处理。由于第一协程在发送完数据获取请求之后，并不会去处理其他业务，而是会被保存当前状态信息之后，切换到其他协程。后续在接收到业务数据后，将会切换回第一协程对业务数据继续进行处理，因此可见，第一协程完全用于处理该业务请求，也即，第一协程只执行该业务请求对应的代码。这样，该业务请求对应的代码将是完整的，而不是碎片化的，更易于阅读和维护，降低了维护成本。并且，由于代码不再碎片化，代码段彼此之间不再隔离，因此，业务处理逻辑的复杂度降低，代码编写难度降低。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的相关技术中邮件读取业务的处理流程图；

图2是本申请实施例提供的业务处理方法所涉及的实施环境图；

图3是本申请实施例提供的一种应用服务器的示意图；

图4是本申请实施例提供的一种业务处理方法的流程图；

图5是本申请实施例提供的另一种业务处理方法的流程图；

图6是是本申请实施例提供的对读取邮件列表的业务请求进行处理的时序图；

图7是本申请实施例提供的一种业务处理装置的结构示意图；

图8是本申请实施例提供的一种用于进行业务处理的应用服务器的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

在对本申请实施例进行详细的解释说明之前，先对本申请实施例涉及的应用场景予以介绍。

通常，终端中安装的应用客户端在运行过程中，可以通过向应用服务器发送业务请求来请求业务数据。应用服务器可以接收多个终端上安装的多个应用客户端发送的多个业务请求。由于在处理业务请求的过程中，用于处理这些业务请求的第一进程可能需要跨进程获取数据，因此，为了保证业务处理速度，当前，第一进程均是采用异步处理方式来对多个业务请求进行处理。

例如，图1示出了一种相关技术中邮件读取业务的流程图。其中，手机游戏客户端a在读取邮件时，可以向应用服务器发送用于指示读取邮件的业务请求。应用服务器中用于处理邮件读取业务的第一进程在接收到该请求之后，需要跨进程从数据库中获取邮件列表。在这种情况下，第一进程可以执行业务代码1，以向数据库发送邮件获取请求。在发送邮件获取请求之后，第一进程将会继续对其他客户端的业务请求进行处理，而不会暂停运行以等待数据库返回结果。也即，第一进程将继续执行业务代码1之后的代码，而该业务代码1之后的代码并非用于处理客户端a的业务请求的代码。由此可见，第一进程并非完全用于处理客户端a的业务请求的进程。在这种情况下，邮件获取请求中即需要携带用户状态信息，以指示该邮件获取请求对应的是哪个客户端发送的业务请求。后续，数据库在返回邮件列表时，可以将用户状态信息再携带在返回结果中。之后，第一进程可以通过执行业务代码2来获取该邮件列表，并根据其中包含的用户状态信息将该邮件列表返回至客户端a。在返回邮件列表至客户端之后，第一进程可以执行业务代码3，以发送设置指令至数据库，该设置指令用于对数据库中指示邮件列表是否被读取的标识位进行设置。同理，数据库在根据该设置指令对标识位进行设置的过程中，第一进程依然不会暂停，而是会继续执行其他代码。后续，当数据库返回置位结果之后，第一进程还需要通过业务代码4来获取数据库返回的置位结果。

由上述分析可以看出，在现有的异步处理框架下，用于处理客户端a发送的业务请求的业务代码1和业务代码2被其他代码隔离，彼此之间缺乏联系。同理，业务代码3和业务代码4也被隔离。也即，用于处理该业务请求的业务代码是碎片化的。正是由于业务代码是碎片化的，业务代码1和2之间缺乏联系，所以，在与数据库交互的过程中，业务层需要维护用户状态信息。并且，由于执行业务代码1之后，第一进程接着去执行了其他代码，所以，在数据库返回邮件列表之后，需要通过业务代码2的回调函数来获取返回的邮件列表结果。同理，在数据库返回置位结果之后，也需要通过业务代码4来获取。由此可见，由于代码碎片化，不仅导致了代码不易阅读难以维护，而且还导致业务层需要维护用户状态信息，代码中需要包含回调函数来获取处理结果，造成了处理逻辑复杂，代码编写难度大的问题。

而本申请实施例提供的业务处理方法即可以解决上述示例中用于处理邮件业务的代码碎片化的问题。当然，除此之外，本申请实施例提供的业务处理方法还可以应用于其他异步处理框架下，需要跨进程获取数据的业务系统中。例如，在手机游戏客户端请求创建对局房间场景中，业务进程请求其他进程创建对局房间并返回创建房间的结果的过程。

接下来对本申请实施例涉及的实施环境进行介绍。

图2是本申请实施例提供的业务处理方法所涉及的实施环境图。如图2所示，该实施环境中包括终端201和应用服务器202。

其中，终端201中安装有应用客户端，该应用客户端是指有应用服务器202提供服务的客户端。示例性地，该应用客户端可以为游戏客户端、音乐应用客户端、社交应用客户端或其他应用客户端，本申请在此不对应用客户端的种类作限定。

应用服务器202上存在用于处理终端201中安装的应用客户端发送的业务请求的第一进程。除此之外，该应用服务器202上还可以存在处理其他信息的第二进程。其中，第一进程中可以包括多个协程，每个协程可以通过执行一个业务请求对应的完整的代码来处理该业务请求，进而向应用客户端返回业务处理结果。需要说明的是，在同一时刻，第一进程中仅可以运行有一个协程。另外，第一进程中设置有协程池。在每个协程处理业务请求的过程中，可以跨进程向第二进程请求数据。在第二进程未返回业务数据之后，可以将相应协程挂起存放至该协程池，并将相应协程的当前状态信息保存至协程池，在接收到第二进程返回的业务数据之后，可以从协程池中恢复相应协程，并根据保存的状态信息继续对业务数据进行处理。

需要说明的是，如图3所示，第一进程中所执行的邮件业务的代码可以称为业务层，第一进程中的多个协程以及设置的协程池可以称为框架层。除此之外，框架层中还可以包括通信层。

需要说明的是，终端201可以为智能手机、平板电脑、便携式电脑、台式电脑等智能终端。应用服务器202可以是一台服务器，也可以为多台服务器组成的服务器集群，本申请实施例对此不作限定。

接下来对本申请实施例提供的业务处理方法进行介绍。

图4是本申请实施例提供的一种业务处理方法的流程图。该方法可以应用于图2所示的应用服务器上的第一进程，参见图4，该方法包括：

步骤401：通过第一协程向第二进程发送数据获取请求，第一协程是第一进程中为业务请求分配的协程。

在本申请实施例中，应用服务器上存在用于处理某一类业务请求的第一进程。该第一进程中可以包括多个协程。其中，该多个协程中可以包括主协程，除主协程之外的每个协程可以用于处理一个业务请求。需要说明的是，主协程可以是第一进程中用于实现对其他协程进行调度的协程。

当应用客户端向应用服务器请求服务时，应用客户端可以向应用服务器发送业务请求。第一进程可以通过主协程接收该业务请求，并为该业务请求分配一个协程。其中，该业务请求是指需要跨进程获取业务数据的业务请求。

示例性地，第一进程的主协程可以检测第一进程包括的多个协程中是否存在空闲协程；如果第一进程包括的多个协程中不存在空闲协程，则创建一个协程，将创建的协程作为第一协程；如果第一进程包括的多个协程中存在空闲协程，则从空闲协程中选择一个协程作为第一协程。

其中，空闲协程是指未分配的协程。也即，第一进程可以通过主协程从多个协程中查找是否还存在未分配的空闲协程。如果存在，则可以将查找到的空闲协程分配给该业务请求。如果不存在未分给的空闲协程，则第二进程可以通过该主协程创建一个新的协程，并将创建的协程分配给该业务请求。需要说明的是，在创建一个新的协程之后，主协程还可以为创建的新的协程分配对应的协程标识。

在为业务请求分配协程之后，第一进程可以将主协程挂起，并将主协程保存至协程池，将主协程的上下文信息也保存在协程池中。之后，第一进程可以启动第一协程，通过该第一协程执行该业务请求的业务代码，并通过第一协程校验该业务请求中携带的参数是否合法。其中，该业务请求中携带的参数可以是发送该业务请求的应用客户端的用户信息以及业务标识等，本申请实施例对此不做限定。在第一进程通过第一协程对业务请求中携带的参数校验成功之后，第一进程可以通过第一协程向第二进程发送数据获取请求。其中，该数据获取请求用于向第二进程请求业务数据。并且，该数据获取请求中携带第一协程的协程标识。该第一协程的协程标识可以唯一标识第一协程。

需要说明的是，每个协程拥有自己的寄存器上下文和栈。在本申请实施例中，主协程的上下文信息可以是指主协程被挂起前该主协程的寄存器上下文和栈。该寄存器上下文和栈可以用于指示主协程在被挂起时，运行到了哪个位置。

下文是本申请实施例示例性地给出的用于实现第一进程为业务请求分配协程，并通过第一协程进行参数校验的代码段。

步骤402：从第一协程切换至第二协程，保存第一协程的当前状态信息。

第一进程通过第一协程向第二进程发送数据获取请求之后，由于第二进程获取并返回业务数据需要时间，所以，第一进程可以从第一协程切换至第二协程，并保存第一协程的当前状态信息。

示例性地，第一进程可以将第一协程挂起，并将第一协程存放至协程池。与此同时，第一进程可以将第一协程在发送数据获取请求时的上下文信息作为第一协程的当前状态信息，将第一协程的当前状态信息存储在协程池中。之后，第一进程可以启动第二协程，以此来实现第一协程到第二协程之间的切换。

在本申请实施例中，第一协程发送数据获取请求时的上下文信息可以是指发送完数据获取请求时该第一协程的寄存器上下文和栈。此时，该寄存器上下文和栈能够指示该第一协程的运行状态，也即，可以指示当前第一协程运行到业务代码的哪个位置。这样，当后续再次切换至第一协程时，第一协程则可以根据该状态信息从相应地位置继续运行。

在将第一协程放入到协程池且保存第一协程的当前状态信息之后，第一进程可以从协程池中获取前述的主协程以及存储的主协程的上下文信息。由前述介绍可知，主协程的上下文信息是指主协程在被挂起时该主协程的寄存区上下文和栈，可以用于指示在主协程被挂起时，该主协程运行到哪个位置。基于此，在获取到主协程的上下文信息之后，第一进程可以根据该主协程的上下文信息重新启用主协程，从而使主协程基于该上下文信息，从上次被挂起时所运行到的位置开始继续运行。这样，第一进程将控制权交还给主协程。接下来，主协程可以启动第二协程。其中，该第二协程可以是第一进程为其他业务请求分配的协程。

需要说明的是，主协程启动第二协程的过程，可以参考前述实施例中第一进程通过主协程启用第一协程的实现过程，本申请实施例在此不再赘述。

可选地，如果第二协程是之前已经被挂起且存放在协程池中的协程，则第一进程可以参考前述从协程池中恢复主协程的过程，通过主协程恢复第二协程，从而使得第二协程从上次被挂起时运行到的位置来是继续运行。

可选地，在一种可能的实现方式中，第二协程即可以为主协程。在这种情况下，从第一协程切换至第二协程的实现方式即为前述的从第一协程切换至主协程的过程，本申请实施例在此不再赘述。

步骤403：当接收到第二进程返回的业务数据时，根据第一协程的当前状态信息，从第二协程切换至第一协程。

在从第一协程切换至第二协程之后，第一进程可以通过该第二协程处理其他业务。在这个过程中，第二进程可以根据接收到的数据获取请求获取对应的业务数据，进而将该业务数据返回至第一进程。

由步骤401中的介绍可知，数据获取请求中携带有第一协程的协程标识。第二进程在返回业务数据时，可以在业务数据中携带第一协程的协程标识。

第一进程在接收到第二进程返回的业务数据之后，可以从该业务数据中获取到第一协程的协程标识。之后，第一进程可以根据第一协程的协程标识，从协程池中获取第一协程和第一协程的当前状态信息。

需要说明的是，在协程池中，存放有协程标识、协程和协程状态信息的映射关系。基于此，第一进程可以从该映射关系中获取第一协程的协程标识对应的协程和状态信息，获取到的协程即为第一协程和第一协程的当前状态信息。

在获取到第一协程和第一协程的状态信息之后，第一进程可以将当前正在运行的第二协程挂起，将第二协程和第二协程的当前状态信息存放至协程池；根据第一协程的当前状态信息，重启第一协程。

示例性地，第一进程可以将第二协程挂起，放入到协程池中。与此同时，将第二协程在当前时刻的寄存器上下文和栈作为第二协程的当前状态信息存入协程池中。之后，如果第二协程即为主协程，则第一进程可以按照获取的第一协程的当前状态信息，重新运行第一协程。由于第一协程的当前状态信息是第一协程在发送完获取请求后被挂起时的寄存器上下文和栈，可以用于指示第一协程在上次被挂起时运行到业务代码的哪个位置，因此，第一进程按照该上下文信息运行第一协程时，第一协程将进入到上次发送完数据获取请求时的状态，也即，从上次被挂起时运行到的位置继续运行。

需要说明的是，如果第二协程为其他业务请求对应的协程，则在将第二协程的挂起放入到协程池，并将第二协程的当前状态信息保存至协程池之后，第一进程可以参考前述实施例中介绍的方法，从协程池中恢复主协程。之后，第一进程的主协程可以参考前述介绍的方法根据第一协程和第一协程的当前状态信息，重新启用第一协程。

在重新启动第一协程之后，第一进程可以将协程池中存储的映射关系中第一协程对应的信息进行删除。

下文中给出了在为业务请求分配第一协程之后，从第一协程切换至主协程，再从主协程切换回第一协程的实现代码。

在本申请实施例中，第一协程在发送数据获取请求之后，将被挂起存放至协程池，并且，第一协程挂起时的状态信息也会被存放至协程池。这样，后续在接收到返回的业务数据之后，可以直接从协程池中恢复该第一协程以继续执行后续业务代码。由于第一进程可以直接根据第一协程的协程标识恢复第一协程，以使第一协程可以从上次挂起时的运行到的位置开始继续往下运行，因此，即使向第二进程发送的数据获取请求以及第二进程返回的业务数据中不携带用户状态信息，第一协程在恢复之后也可以根据上下文信息获悉业务数据对应的应用客户端。也即，业务层无需在维护用户状态信息。并且，第一进程也无需再通过回调函数来获取第二进程返回的业务数据，简化了业务处理逻辑，从而减少了代码量，降低了代码编写难度。

步骤404：通过第一协程对业务数据进行处理。

在重新运行第一协程之后，第一进程可以通过该第一协程继续对业务数据执行后续处理，并将处理结果返回至该业务请求对应的客户端。

需要说明的是，如果第二进程返回的业务数据就是应用客户端请求的业务数据，则第一进程可以直接通过第一协程将该业务数据返回至客户端。

图5示例性地给出了一种应用于前述图2所示的系统架构中的业务处理方法的系统流程图。参见图5，应用客户端发送业务请求。应用服务器中的第一进程通过主协程接收该业务请求，并查找当前是否存在空闲协程。如果存在，则获取空闲协程作为第一协程，如果不存在，则创建新协程作为第一协程。之后，通过第一协程进行参数检查，启用第一协程执行业务代码，以向第二进程发送数据获取请求。挂起协程并放入协程池，等待第二进程返回业务数据。待返回业务数据之后，则从协程池恢复第一协程，以使第一协程按照保存的上下文信息继续运行。

在本申请实施例中，可以通过第一协程向第二进程发送数据获取请求，之后，第一进程可以从第一协程切换至第二协程，并保存第一协程的当前状态信息。后续，当接收到第二进程返回的业务数据时，可以根据第一协程的当前状态信息，从第二协程切换回第一协程，由第一协程继续对业务数据进行处理。由于第一协程在发送完数据获取请求之后，并不会去处理其他业务，而是会被保存当前状态信息之后，切换到其他协程。后续在接收到业务数据后，将会切换回第一协程对业务数据继续进行处理，因此可见，第一协程完全用于处理该业务请求，也即，第一协程只执行该业务请求对应的代码。这样，该业务请求对应的代码将是完整的，而不是碎片化的，更易于阅读和维护，降低了维护成本，有利于业务更新迭代。并且，由于代码不再碎片化，代码段彼此之间不再隔离，因此，业务处理逻辑的复杂度降低，代码编写难度降低。

在一些实施例中，可以将上述的业务处理方法应用于应用服务器对游戏客户端发送的读取邮件列表的业务请求进行处理的过程中。图6示出了采用上述方法对该业务请求进行处理的时序图。如图6所示，应用服务器中用于处理邮件业务的业务进程在收到游戏客户端发送的业务请求之后，可以为该业务请求分配一个协程，也即第一协程。之后，第一协程可以进行参数校验，执行该业务请求对应的业务代码中代码601，以向数据库发送数据获取请求。在发送完数据获取请求之后，第一协程将被挂起放入协程池，同时第一协程的当前状态信息存入协程池。也即，第一协程将暂停执行该业务代码中代码601之后的其他代码。之后，当数据库返回邮件列表时，第一进程从协程池中恢复第一协程，并将上下文信息切换为存储的第一协程的上下文信息。这样，第一协程将从代码601后的代码602开始继续运行。通过执行代码602将该邮件列表返回至相应的应用客户端。之后，第一协程可以执行代码603，以向数据库发送设置指令。在发送设置指令之后，第一进程可以将第一协程再次挂起，放入协程池，并保存第一协程此时的状态信息。之后，待数据库返回置位结果之后，第一进程可以从协程池中恢复该第一协程，此时，第一协程可以根据该置位结果结束操作或者是执行其他处理。

由上述过程可以看出，通过本申请实施例中提供的方法来处理游戏客户端读取邮件的业务请求时，代码601和代码602之间并不存在任何其他业务请求的代码，也即，业务请求对应的业务代码是完整的，而非碎片化的，更易于阅读和维护。并且，由于业务代码是完整的，且每次挂起第一协程时，均会记录其上下文信息，因此，第一协程向数据库发送的数据获取请求中并不需要携带游戏客户端的用户状态信息，相应地，数据库也可以不在业务数据中携带该用户状态信息。另外，由于第一协程在发送数据获取请求之后，并未执行其他代码，而是在等待第二进程返回数据，并且，由于存储了第一协程的上下文信息，所以第一协程可以接着原来的位置继续运行，这样，即无需在代码602中编写回调函数，简化了业务处理逻辑，减少了代码量，降低了代码编写难度。

下文中给出了采用上述业务处理方法处理读邮件业务的代码。

由上述代码可以看出，框架层中的协程可以在执行业务层中获取邮件列表的代码之后挂起放入到协程池。在接收到邮件列表之后，框架层中协程可以从协程池中恢复(resume)，执行检查邮件列表并返回至客户端的代码。之后，框架层中协程执行设置标识位的代码，执行后再次挂起存放到协程池中，在接收到返回的置位结果之后，即再次从协程池中恢复。

在一些可能的实施例中，上述读邮件业务可以是读取物品邮件。在这种情况下，在接收到数据库返回的用于指示物品已领取的置位结果后，框架层的协程还可以执行向数据库发送删除命令的代码，以删除对应的邮件列表。在发送删除命令之后，框架层的协程将再次挂起存放到协程池中。之后，在接收到数据库返回的删除成功消息之后，将该协程从协程池中恢复，以执行后续代码。示例性地，上述的业务流程的代码如下所示：

接下来对本申请实施例提供的业务处理装置进行介绍。

参见图7，本申请实施例提供了一种业务处理装置700，该装置700包括：

发送模块701，用于通过第一进程中的第一协程向第二进程发送数据获取请求，第一协程是第一进程中为业务请求分配的协程；

切换模块702，用于从第一协程切换至第二协程，保存第一协程的当前状态信息，第二协程是第一进程中为其他业务请求分配的协程；

切换模块702，还用于当接收到第二进程返回的业务数据时，根据第一协程的当前状态信息，从第二协程切换至第一协程；

处理模块703，用于通过第一协程对业务数据进行处理。

可选地，切换模块702包括：

第一挂起子模块，用于挂起第一协程，将第一协程存放至协程池；

存储子模块，用于将通过第一协程发送数据获取请求时的上下文信息作为第一协程的当前状态信息，将第一协程的当前状态信息存储在协程池中；

启动子模块，用于启动第二协程。

可选地，切换模块702还包括：

第二挂起子模块，用于挂起第二协程，将第二协程和第二协程的当前状态信息存放至协程池；

重启子模块，用于根据第一协程的当前状态信息，重启第一协程。

可选地，数据获取请求和业务数据中均携带有第一协程的协程标识；

该装置700还包括：

获取模块，用于根据第一协程的协程标识，从协程池中获取第一协程和第一协程的当前状态信息。

可选地，该装置700还用于：

检测第一进程包括的多个协程中是否存在空闲协程；

如果第一进程包括的多个协程中不存在空闲协程，则创建一个协程，将创建的协程作为第一协程；

如果第一进程包括的多个协程中存在空闲协程，则从空闲协程中选择一个协程作为第一协程。

综上所述，本申请实施例可以通过第一协程向第二进程发送数据获取请求，之后，第一进程可以从第一协程切换至第二协程，并保存第一协程的当前状态信息。后续，当接收到第二进程返回的业务数据时，可以根据第一协程的当前状态信息，从第二协程切换回第一协程，由第一协程继续对业务数据进行处理。由于第一协程在发送完数据获取请求之后，并不会去处理其他业务，而是会被保存当前状态信息之后，切换到其他协程。后续在接收到业务数据后，将会切换回第一协程对业务数据继续进行处理，因此可见，第一协程完全用于处理该业务请求，也即，第一协程只执行该业务请求对应的代码。这样，该业务请求对应的代码将是完整的，而不是碎片化的，更易于阅读和维护，降低了维护成本。并且，由于代码不再碎片化，代码段彼此之间不再隔离，因此，业务处理逻辑的复杂度降低，代码编写难度降低。

需要说明的是：上述实施例提供的业务处理装置在检测字符串时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的业务处理装置与业务处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图8是本申请实施例提供的一种应用服务器的结构示意图，该应用服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)801和一个或一个以上的存储器802，其中，所述存储器802中存储有至少一条指令，所述至少一条指令由该处理器801加载并执行，以实现上述实施例中的业务处理方法。当然，该应用服务器800还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该应用服务器800还可以包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由处理器加载并执行以实现上述业务处理方法。例如，所述计算机可读存储介质可以是rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、cd-rom(compactdiscread-onlymemory，只读光盘)、磁带、软盘和光数据存储设备等。

值得注意的是，本申请提到的计算机可读存储介质可以为非易失性存储介质，换句话说，是非瞬时性存储介质。

应当理解的是，实现上述实施例的全部或部分步骤可以通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。所述计算机指令可以存储在上述计算机可读存储介质中。

也即是，在示例性实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述业务处理方法。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。