线上服务方法、装置、电子设备和可读存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种线上服务方法、装置、电子设备和可读存储介质。

背景技术

目前，针对线上服务的需求越来越多，为了更好地满足这些需求以及更便于开发，微服务应运而生，微服务是一种新型的服务架构，可以把一个大型的服务拆分为多个微服务，以减轻服务的压力。

在现有技术中，服务器中可以包括若干微服务模块，其中，微服务模块可以用于执行微服务任务，当服务器接收到业务请求时，可以根据业务请求的内容调用各微服务执行微服务任务，以完成业务请求，具体的，现有技术中的微服务调用方式为同步调用微服务或者异步调用微服务。

在同步调用微服务的方式中，为了满足高吞吐量的需求，需要设置大量的主服务线程，这样会影响系统调度的时间，从而影响微服务的实时性，同时，由于主服务线程过多，会导致服务资源的利用率较低。

在异步调用微服务的方式中，由于主服务线程会大量请求微服务，很容易使得微服务无法承受大量的请求，从而使得微服务崩溃并无法响应，进而导致系统的稳定性较低。

发明内容

有鉴于此，本发明实施例提供一种线上服务方法、装置、电子设备和可读存储介质，以提高系统稳定性和服务资源利用率。

第一方面，提供了一种线上服务方法，所述方法应用于服务器，所述方法包括：

根据接收到的业务请求确定对应的至少一个目标微服务任务，将所述目标微服务任务写入任务消息队列；

根据所述任务消息队列执行所述目标微服务任务对应的操作，确定所述目标微服务任务对应的目标操作结果，将所述目标操作结果写入结果消息队列；以及

获取结果消息队列中的至少一个目标操作结果，并发送所述至少一个目标操作结果。

第二方面，提供了一种线上服务装置，所述装置应用于服务器，所述装置包括：

主服务入口模块，用于根据接收到的业务请求确定对应的至少一个目标微服务任务，将所述目标微服务任务写入任务消息队列；

微服务模块，用于根据所述任务消息队列执行所述目标微服务任务对应的操作，确定所述目标微服务任务对应的目标操作结果，将所述目标操作结果写入结果消息队列；以及

主服务出口模块，用于获取结果消息队列中的至少一个目标操作结果，并发送所述至少一个目标操作结果。

第三方面，本发明实施例提供了一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条计算机程序指令，其中，所述一条或多条计算机程序指令被所述处理器执行以实现如第一方面所述的方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令在被处理器执行时实现如第一方面所述的方法。

通过本发明实施例，服务器中可以部署本发明实施例中提出的微服务架构，具体的，服务器接收到业务请求后，可以将目标微服务任务写入任务消息队列，而不是直接将任务发送给微服务模块，当业务请求量过大时，目标微服务任务仅会在任务消息队列中堆积，而不会压垮微服务，提高了系统稳定性，然后微服务模块在处理目标微服务任务时，可以从任务消息队列中拉取目标微服务任务并执行对应操作，然后确定目标操作结果，将目标操作结果写入结果消息队列中，然后服务器可以从结果消息队列中拉取目标操作结果并进行结果分发，在此过程中，由于任务分发、任务处理和结果返回三个过程基于消息队列相互独立，因此，在本发明实施例中无需配置过多的主服务线程，进而提高了服务资源的利用率。

附图说明

通过以下参照附图对本发明实施例的描述，本发明实施例的上述以及其它目的、特征和优点将更为清楚，在附图中：

图1为本发明实施例提供的一种线上服务系统的示意图；

图2为本发明实施例提供的一种线上服务方法的流程图；

图3为本发明实施例提供的一种微服务架构的示意图；

图4为本发明实施例提供的另一种线上服务方法的流程图；

图5为本发明实施例提供的另一种线上服务方法的流程图；

图6为本发明实施例提供的另一种线上服务方法的流程图；

图7为本发明实施例提供的一种线上服务装置的结构示意图；

图8为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

以下基于实施例对本发明进行描述，但是本发明并不仅仅限于这些实施例。在下文对本发明的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本发明。为了避免混淆本发明的实质，公知的方法、过程、流程、元件和电路并没有详细叙述。

此外，本领域普通技术人员应当理解，在此提供的附图都是为了说明的目的，并且附图不一定是按比例绘制的。

除非上下文明确要求，否则在说明书的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。

在本发明的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

如图1所示，图1为本发明实施例提供的一种线上服务系统的示意图，其中，该示意图包括服务请求端1、服务器2和服务请求端3。

在实际应用中，服务请求端1和服务请求端3可以是终端设备，终端设备可以是能够运行应用程序的、具有通信功能通用数据处理终端，例如，智能手机、平板电脑或者个人计算机(Personal Computer，PC)等，服务器2可以是单个服务器，也可以是以分布式方式配置的服务器集群，还可以是云，例如弹性云(Elastic Cloud)。

弹性云是在云端部署的服务器，其具有适应性强、弹性易用等优点，可以根据业务需求和策略，自动调整弹性云计算资源，即弹性云可以根据业务需求进行缩扩容，进而可以高效匹配业务要求，并节省资源。

在本发明实施例中，当服务请求端1或者服务请求端3有业务需求时，可以通过网络向服务器2发送业务请求，然后，服务器2可以基于微服务架构，处理该业务请求，然后通过网络向服务请求端1或者服务请求端3返回处理结果，以完成一次线上服务。

其中，微服务是一种服务架构方案，可以将单个复杂的整体服务拆解为由许多松散耦合且可独立部署的较小服务，使得整个服务系统具有较好的适应性、扩展性以及开放性等优点。

下面将结合具体实施方式，对本发明实施例提供的一种线上服务方法进行详细的说明，如图2所示，具体步骤如下：

在步骤100，根据接收到的业务请求确定对应的至少一个目标微服务任务，将目标微服务任务写入任务消息队列。

在步骤200，根据任务消息队列执行目标微服务任务对应的操作，确定目标微服务任务对应的目标操作结果，将目标操作结果写入结果消息队列。

在步骤300，获取结果消息队列中的至少一个目标操作结果，并发送至少一个目标操作结果。

通过本发明实施例，服务器中可以部署本发明实施例中提出的微服务架构，具体的，服务器接收到业务请求后，可以将目标微服务任务写入任务消息队列，而不是直接将任务发送给微服务模块，当业务请求量过大时，目标微服务任务仅会在任务消息队列中堆积，而不会压垮微服务，提高了系统稳定性，然后微服务模块在处理目标微服务任务时，可以从任务消息队列中拉取目标微服务任务并执行对应操作，然后确定目标操作结果，将目标操作结果写入结果消息队列中，然后服务器可以从结果消息队列中拉取目标操作结果并进行结果分发，在此过程中，由于任务分发、任务处理和结果返回三个过程基于消息队列相互独立，因此，在本发明实施例中无需配置过多的主服务线程，进而提高了服务资源的利用率。

更进一步的，如图3所示，图3为本发明实施例提供的一种微服务架构的示意图，该示意图包括主服务入口、第一任务消息队列、第二任务消息队列、第一微服务、第二微服务、结果消息队列和主服务出口。

在本发明实施例中，图3所示的微服务架构可以部署在图1所示的服务器2中以执行图2所述的方法步骤，同时，该微服务架构可以是结合flink框架以及kafka系统构建的微服务架构。

kafka系统是一种高吞吐量的分布式发布订阅消息系统，其具有高吞吐量、低延时和高稳定等优点，可以用于本发明实施例线上服务系统中的消息队列。

flink是一种开源流处理框架，其核心是用Java(编程语言)和Scala(编程语言)编写的分布式流数据流引擎，flink中包括两种负责业务处理的单元：工作管理器(Jobmanager)和任务管理器(Task manager)。

需要说明的，由于业务请求端可以随时向服务器发送业务请求，相应的，服务器也实时接收该业务请求，所以在本发明实施例中，服务器提供线上服务的过程是一种流处理过程。

在实际应用中，由于flink支持高吞吐、低延迟且高性能的流数据处理，且kafka同样支持高吞吐、低延时且高稳定的流数据处理，所以本发明实施例可以将二者进行结合，构建本发明实施例提出的微服务架构，进而实现了用于处理流数据的线上服务的过程。

在本发明实施例中，Job manager负责对业务请求进行预处理(例如业务分流等)，然后将预处理后的业务请求(下文称为目标微服务任务)进行分发，Task manager负责从消息队列中拉取目标微服务任务，并执行目标微服务任务对应的操作。

具体的，主服务入口可以是flink框架中的Job manager模块，第一微服务、第二微服务和主服务出口可以是flink框架中的Task manager模块。

进而，上述步骤100可以由flink框架中的Job manager单元执行，上述步骤200可以由flink框架中的Task manager单元执行，上述步骤300可以由flink框架中的Taskmanager单元执行，上述任务消息队列以及结果消息队列可以是基于kafka系统构建的消息队列。

在实际应用中，服务器可以接收业务请求端发送的业务请求，然后主服务入口可以对接收到的业务请求进行规则过滤，滤除无效的业务请求，然后对有效的业务请求进行业务分流，确定目标微服务任务，然后将目标微服务任务写入对应微服务的任务消息队列中。

例如，若第一微服务对应第一任务消息队列，第二微服务对应第二任务消息队列，则服务器可以将第一微服务对应的目标微服务任务写入第一任务消息队列，将第二微服务对应的目标微服务任务写入第二任务消息队列。

进一步的，若第二微服务对应的目标微服务任务需要第一微服务的执行结果，则第一微服务在确定执行结果后，可以将该执行结果写入第二任务消息队列，反之，第二微服务也可以将执行结果写入第一任务消息队列。

另外，当业务请求的数量过大时，服务器可以基于flink框架的反压机制执行限流操作，也即，响应于预设单位时间内业务请求的数量达到业务数量阈值，暂停接收业务请求。

这样，通过flink框架的反压机制，服务器可以在业务流量过大时，实现限流的目的，同时，由于服务器仅暂停接收业务请求，所以业务请求端仅需等待服务器接收即可(在用户侧仅感知到稍许的延时)，即业务请求端无需反复发送业务请求，减轻了线上服务系统的压力。

在实际应用中，由于服务器实时接收业务请求端发送的业务请求，所以服务器可以针对各业务请求进行流式处理，为了维持线上服务系统的稳定，服务器还可以结合flink框架以及kafka系统，实现“严格一次(exactly-once)”业务逻辑。

具体的，服务器会定期为流式数据中每个运算符的所有状态创建检查点，一旦系统中任何位置出现失败，每个运算符的所有状态会回滚至最新的全局一致检查点。

回滚过程中，所有处理工作会暂停，随后源也会重置为与最新检查点相符的偏移量，整个流式数据会被回滚到最新一致状态，并从该状态开始重新处理，以实现exactly-once，进而保证了线上服务系统的稳定性。

结合flink框架以及kafka系统，第一微服务或者第二微服务在进行业务处理时，可以从各自对应的第一任务消息队列或者第二任务消息队列中拉取目标微服务任务，然后执行目标微服务任务对应的操作，确定目标操作结果，然后将目标操作结果写入结果消息队列中。

需要说明的，上述第一微服务和第二微服务中的第一和第二仅用于区分两个微服务，第一微服务和第二微服务之间不存在执行的先后顺序，而且，图3所示的微服务架构仅列举了两个微服务进行举例说明，本发明实施例对微服务架构中微服务的数量不做限定，即本发明实施例中的微服务的数量可以为任意整数。

进一步的，由于微服务与任务消息队列之间存在对应关系(例如第一微服务对应第一任务消息队列，第二微服务对应第二任务消息队列)，所以任务消息队列的数量也可以为任意整数，本发明实施例不做限定。

主服务出口在进行操作结果分发时，可以从结果消息队列中拉取第一微服务或者第二微服务写入的目标操作结果，然后将目标操作结果返回至对应的业务请求端。

可选的，步骤100可以为：根据接收到的业务请求确定对应的至少一个目标微服务；生成目标微服务对应的目标微服务任务；以及针对每个目标微服务任务，将目标微服务任务写入对应目标微服务的任务消息队列中。

例如，在一种应用场景中，请求端为网约车司机X所使用的司机终端(例如智能手机等)，业务请求A为查询网约车司机X最近一个月内的个人工作汇总。

结合图3所示的微服务架构，第一微服务可以用于从数据库中查询最近一个月内完成的各订单，第二微服务可以用于从数据库中查询最近一个月内的收入。

当主服务入口接收到业务请求A时，可以先对业务请求A进行解析以及规则过滤，响应于业务请求A为有效请求，主服务入口可以根据业务请求A所请求的内容，将业务请求A拆分为2个目标微服务任务：

第一微服务任务、从数据库中查询网约车司机X最近一个月内完成的各订单。

第二微服务任务、从数据库中查询网约车司机X最近一个月内的收入。

然后，主服务入口可以基于Job manager模块的功能，将第一微服务任务写入第一微服务对应的任务消息队列中，将第二微服务任务写入第二微服务对应的任务消息队列中。

通过本发明实施例，服务器接收到业务请求后，可以将目标微服务任务写入任务消息队列，而不是直接将任务发送给微服务模块，当业务请求量过大时，目标微服务任务仅会在任务消息队列中堆积，而不会压垮微服务，提高了系统稳定性。

当主服务入口将目标微服务任务写入任务消息队列之后，微服务可以根据任务消息队列执行目标微服务任务对应的操作，然后确定目标微服务任务对应的目标操作结果，然后将目标操作结果写入结果消息队列，具体的，本发明实施例提供以下3种可选的实施例：

实施例一、获取任务消息队列中的至少一个目标微服务任务；分别执行各目标微服务任务对应的操作，确定每个目标微服务任务对应的目标操作结果；以及将各目标操作结果写入结果消息队列。

具体的，本发明实施例提供一种针对实施例一的示例性流程图，如图4所示，具体包括以下步骤：

在步骤41，接收业务请求B。

更进一步的，服务器可以基于flink框架中的Job manager单元，对业务请求B进行规则过滤和业务分流等操作，确定第一微服务任务和第二微服务任务。

在步骤42，将第一微服务任务写入第一任务消息队列。

在实施例一中，第一微服务对应第一任务消息队列，服务器可以基于flink框架中的Job manager单元，将第一微服务任务写入第一任务消息队列。

在步骤43，将第二微服务任务写入第二任务消息队列。

在实施例一中，第二微服务对应第二任务消息队列，服务器可以基于flink框架中的Job manager单元，将第二微服务任务写入第二任务消息队列。

在步骤44，基于第一微服务执行第一微服务任务，确定第一操作结果。

在实施例一中，第一微服务任务和第二微服务任务可以是相互独立的两个任务，第一微服务可以从第一任务消息队列中拉取第一微服务任务，然后执行第一微服务任务对应的操作，确定第一操作结果。

其中，第一微服务可以是flink框架中的一个Task manager单元。

在步骤45，基于第二微服务执行第二微服务任务，确定第二操作结果。

具体的，第二微服务可以从第二任务消息队列中拉取第二微服务任务，然后执行第二微服务任务对应的操作，确定第二操作结果。

其中，第二微服务可以是flink框架中的另一个Task manager单元。

在步骤46，将第一操作结果写入结果消息队列。

具体的，第一微服务确定第一操作结果后，第一微服务可以将第一操作结果写入结果消息队列。

其中，结果消息队列是主服务出口对应的消息队列，主服务出口可以从结果消息队列中拉取第一操作结果并返回给请求端。

在步骤47，将第二操作结果写入结果消息队列。

第二微服务确定第二操作结果后，第二微服务可以将第二操作结果写入结果消息队列，进而，主服务出口可以从结果消息队列中拉取第二操作结果并返回给请求端。

综上，在实施例一中，因为第一微服务任务和第二微服务任务可以是相互独立的两个任务，所以服务器可以基于flink框架以及kafka系统构建的消息队列，并行处理第一微服务任务和第二微服务任务，在保证系统稳定性的前提下，提高了业务处理效率。

在一个实际应用的场景中，业务请求B为查询网约车司机X最近一个月内的个人工作汇总，第一微服务任务为从数据库中查询网约车司机X最近一个月内完成的各订单，第二微服务任务为从数据库中查询网约车司机X最近一个月内的收入。

基于上述实施例一，第一操作结果为网约车司机X最近一个月内完成的各订单，第二操作结果为网约车司机X最近一个月内的收入。

进而，主服务出口可以从结果消息队列中拉取网约车司机X最近一个月内完成的各订单，以及最近一个月内的收入作为网约车司机X最近一个月内的个人工作汇总，并返回给网约车司机X所使用的请求端。

实施例二、获取第一任务消息队列中的至少一个第一微服务任务；执行第一微服务任务对应的操作，确定第一微服务任务对应的第一操作结果，将第一操作结果写入第二任务消息队列；以及获取第二任务消息队列中的至少一个第一操作结果，基于至少一个第一操作结果，执行第二微服务任务对应的操作，确定第二微服务任务对应的第二操作结果，将第二操作结果写入任务消息队列。

具体的，本发明实施例提供一种针对实施例二的示例性流程图，如图5所示，具体包括以下步骤：

在步骤51，接收业务请求C。

更进一步的，服务器可以基于flink框架中的Job manager单元，对业务请求C进行规则过滤和业务分流等操作，确定第一微服务任务和第二微服务任务。

在步骤52，将第一微服务任务写入第一任务消息队列。

在实施例二中，第一微服务对应第一任务消息队列，服务器可以基于flink框架中的Job manager单元，将第一微服务任务写入第一任务消息队列。

在步骤53，将第二微服务任务写入第二任务消息队列。

在实施例二中，第二微服务对应第二任务消息队列，服务器可以基于flink框架中的Job manager单元，将第二微服务任务写入第二任务消息队列。

在步骤54，基于第一微服务执行第一微服务任务，确定第一操作结果。

在实施例二中，第一微服务任务和第二微服务任务可以是相互关联的两个任务，例如，第二微服务任务对应的操作是对第一操作结果进行进一步处理。

具体的，第一微服务可以从第一任务消息队列中拉取第一微服务任务，然后执行第一微服务任务对应的操作，确定第一操作结果。

在步骤55，将第一操作结果写入第二任务消息队列。

当第一微服务将第一操作结果写入第二任务消息队列后，第二任务消息队列中包括第一操作结果以及第二微服务任务，进而，第二微服务可以基于第一操作结果，执行第二微服务任务。

在步骤56，基于第二微服务以及第一操作结果，执行第二微服务任务，确定第二操作结果。

在步骤57，将第二操作结果写入结果消息队列。

其中，结果消息队列是主服务出口对应的消息队列，主服务出口可以从结果消息队列中拉取第二操作结果并返回给请求端。

在一个实际应用的场景中，业务请求C为查询流水线X在最近一周的每日平均产量，第一微服务任务为从数据库中查询流水线X在最近一周的总产量，第二微服务任务为根据第一微服务查询到的总产量确定流水线X在最近一周的每日平均产量。

基于上述实施例二，第一操作结果为流水线X在最近一周的总产量(例如14万件)，第二操作结果为流水线X在最近一周的每日平均产量(例如14/7＝2万件)。

进而，主服务出口可以从结果消息队列中拉取流水线X在最近一周的每日平均产量，并返回给流水线X对应的请求端。

实施例三、结合上述实施例一和实施例二，微服务架构中可以既包括相互关联的微服务，也包括相互独立的微服务。

具体的，本发明实施例提供一种针对实施例三的示例性流程图，如图6所示，具体包括以下步骤：

在步骤61，接收业务请求D。

在步骤62，将第一微服务任务写入第一任务消息队列。

在步骤63，将第二微服务任务写入第二任务消息队列。

在步骤64，将第三微服务任务写入第三任务消息队列。

在步骤65，基于第一微服务执行第一微服务任务，确定第一操作结果。

在步骤66，基于第二微服务执行第二微服务任务，确定第二操作结果。

在步骤67，将第一操作结果写入结果消息队列

在步骤68，将第二操作结果写入第三任务消息队列。

在步骤69，基于第三微服务以及第二操作结果，执行第三微服务任务，确定第三操作结果。

在步骤610，将第三操作结果写入结果消息队列。

在实施例三中，第一微服务是与第二、第三微服务相互独立的微服务，第二微服务与第三微服务是相互关联的微服务，结合实施例三所述的内容，本发明实施例提出的微服务架构可以既包括相互关联的微服务，也包括相互独立的微服务，提高了微服务系统的适用性以及可扩展性。

在一个实际的应用场景中，业务请求D为查询工厂X的生产效率概况，第一微服务为从数据库中查询工厂X的员工人数，第二微服务为从数据库中查询工厂X最近一年的总生产量，第三微服务为根据第二微服务查询到的总生产量确定工厂X最近一年的月平均产量。

基于上述实施例三，第一操作结果为工厂X的员工人数，第二操作结果为工厂X最近一年的总生产量，第三操作结果为工厂X最近一年的月平均产量。

进而，主服务出口可以从结果消息队列中拉取工厂X的员工人数，以及在最近一年的月平均产量作为工厂X的生产效率概况，返回给工厂X对应的请求端。

结合上述实施例一、实施例二以及实施例三，服务器接收到业务请求后，可以将目标微服务任务写入任务消息队列，而不是直接将任务发送给微服务模块，当业务请求量过大时，目标微服务任务仅会在任务消息队列中堆积，而不会压垮微服务，提高了系统稳定性，而且，由于消息队列使得任务分发和任务处理的模块相互独立，因此，在本发明实施例中无需配置过多的主服务线程，进而提高了服务资源的利用率。

在至少一个微服务执行目标微服务任务，并将目标操作结果写入结果消息队列后，主服务出口将目标操作结果返回给目标业务请求端的过程可以为：基于请求端标识，确定目标业务请求端；以及向目标业务请求端发送至少一个目标操作结果。

其中，本发明实施例中的业务请求包括请求端标识，目标操作结果包括请求端标识，请求端标识用于标记请求端，以使得服务器可以确定每个业务请求的目标操作结果所对应的目标业务请求端。

具体的，请求端标识可以为目标业务请求端的互联网协议地址(InternetProtocol Address，IP)地址，也可以为业务请求对应的唯一编号，当然，也可以为其它可用的请求端标识，本发明实施例不做限定。

基于相同的技术构思，本发明实施例还提供了一种线上服务装置，如图7所示，该装置包括：主服务入口模块71、微服务模块72和主服务出口模块73；

主服务入口模块71，用于根据接收到的业务请求确定对应的至少一个目标微服务任务，将目标微服务任务写入任务消息队列；

微服务模块72，用于根据任务消息队列执行目标微服务任务对应的操作，确定目标微服务任务对应的目标操作结果，将目标操作结果写入结果消息队列；以及

主服务出口模块73，用于获取结果消息队列中的至少一个目标操作结果，并发送至少一个目标操作结果。

可选的，主服务入口模块71，具体用于：

根据接收到的业务请求确定对应的至少一个目标微服务；

生成目标微服务对应的目标微服务任务；以及

针对每个目标微服务任务，将目标微服务任务写入对应目标微服务的任务消息队列中。

可选的，微服务模块72，具体用于：

获取任务消息队列中的至少一个目标微服务任务；

分别执行各目标微服务任务对应的操作，确定每个目标微服务任务对应的目标操作结果；以及

将各目标操作结果写入结果消息队列。

可选的，目标微服务包括第一微服务和第二微服务，第一微服务对应第一微服务任务和第一任务消息队列，第二微服务对应第二微服务任务和第二任务消息队列，任务消息队列包括第一任务消息队列和第二任务消息队列；

主服务入口模块71，具体用于：

将第一微服务任务写入第一微服务对应的第一任务消息队列中；以及

将第二微服务任务写入第二微服务对应的第二任务消息队列中。

可选的，微服务模块72，具体用于：

获取第一任务消息队列中的至少一个第一微服务任务；

执行第一微服务任务对应的操作，确定第一微服务任务对应的第一操作结果，将第一操作结果写入第二任务消息队列；以及

获取第二任务消息队列中的至少一个第一操作结果，基于至少一个第一操作结果，执行第二微服务任务对应的操作，确定第二微服务任务对应的第二操作结果，将第二操作结果写入任务消息队列。

可选的，主服务入口模块71，具体用于：

根据接收到的业务请求，执行预先设置的主服务操作，确定业务请求对应的至少一个目标微服务任务；以及

将目标微服务任务写入任务消息队列。

可选的，该装置还包括：

限流模块，用于响应于预设单位时间内，业务请求的数量达到业务数量阈值，暂停接收业务请求。

可选的，业务请求包括请求端标识，目标操作结果包括请求端标识；

主服务出口模块73，具体用于：

基于请求端标识，确定目标业务请求端；以及

向目标业务请求端发送至少一个目标操作结果。

可选的，基于flink框架中的任务管理器单元，执行微服务模块72对应的动作；基于kafka系统，构建消息队列。

通过本发明实施例，服务器中可以部署本发明实施例中提出的微服务架构，具体的，服务器接收到业务请求后，可以将目标微服务任务写入任务消息队列，而不是直接将任务发送给微服务模块，当业务请求量过大时，目标微服务任务仅会在任务消息队列中堆积，而不会压垮微服务，提高了系统稳定性，然后微服务模块在处理目标微服务任务时，可以从任务消息队列中拉取目标微服务任务并执行对应操作，然后确定目标操作结果，将目标操作结果写入结果消息队列中，然后服务器可以从结果消息队列中拉取目标操作结果并进行结果分发，在此过程中，由于任务分发、任务处理和结果返回三个过程基于消息队列相互独立，因此，在本发明实施例中无需配置过多的主服务线程，进而提高了服务资源的利用率。

图8是本发明实施例的电子设备的示意图。如图8所示，图8所示的电子设备为通用地址查询装置，其包括通用的计算机硬件结构，其至少包括处理器81和存储器82。处理器81和存储器82通过总线83连接。存储器82适于存储处理器81可执行的指令或程序。处理器81可以是独立的微处理器，也可以是一个或者多个微处理器集合。由此，处理器81通过执行存储器82所存储的指令，从而执行如上所述的本发明实施例的方法流程实现对于数据的处理和对于其它装置的控制。总线83将上述多个组件连接在一起，同时将上述组件连接到显示控制器84和显示装置以及输入/输出(I/O)装置85。输入/输出(I/O)装置85可以是鼠标、键盘、调制解调器、网络接口、触控输入装置、体感输入装置、打印机以及本领域公知的其他装置。典型地，输入/输出装置85通过输入/输出(I/O)控制器86与系统相连。

本领域的技术人员应明白，本发明的实施例可提供为方法、装置(设备)或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品。

本发明是参照根据本发明实施例的方法、装置(设备)和计算机程序产品的流程图来描述的。应理解可由计算机程序指令实现流程图中的每一流程。

这些计算机程序指令可以存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现流程图一个流程或多个流程中指定的功能。

也可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程中指定的功能的装置。

本发明的另一实施例涉及一种非易失性存储介质，用于存储计算机可读程序，所述计算机可读程序用于供计算机执行上述部分或全部的方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指定相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本发明各实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域技术人员而言，本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

本发明实施例公开了TS1、一种线上服务方法，其中，所述方法包括：

根据接收到的业务请求确定对应的至少一个目标微服务任务，将所述目标微服务任务写入任务消息队列；

根据所述任务消息队列执行所述目标微服务任务对应的操作，确定所述目标微服务任务对应的目标操作结果，将所述目标操作结果写入结果消息队列；以及

获取结果消息队列中的至少一个目标操作结果，并发送所述至少一个目标操作结果。

TS2、如TS1所述的方法，其中，所述根据接收到的业务请求确定对应的至少一个目标微服务任务，将所述目标微服务任务写入任务消息队列，包括：

根据接收到的业务请求确定对应的至少一个目标微服务；

生成所述目标微服务对应的目标微服务任务；以及

针对每个目标微服务任务，将所述目标微服务任务写入对应目标微服务的任务消息队列中。

TS3、如TS2所述的方法，其中，所述根据所述任务消息队列执行所述目标微服务任务对应的操作，确定所述目标微服务任务对应的目标操作结果，将所述目标操作结果写入结果消息队列，包括：

获取所述任务消息队列中的至少一个目标微服务任务；

分别执行各所述目标微服务任务对应的操作，确定每个所述目标微服务任务对应的目标操作结果；以及

将各目标操作结果写入结果消息队列。

TS4、如TS2所述的方法，其中，所述目标微服务包括第一微服务和第二微服务，所述第一微服务对应第一微服务任务和第一任务消息队列，所述第二微服务对应第二微服务任务和第二任务消息队列，所述任务消息队列包括所述第一任务消息队列和所述第二任务消息队列；

所述针对每个目标微服务任务，将所述目标微服务任务写入对应目标微服务的任务消息队列中，包括：

将所述第一微服务任务写入所述第一微服务对应的第一任务消息队列中；以及

将所述第二微服务任务写入所述第二微服务对应的第二任务消息队列中。

TS5、如TS4所述的方法，其中，所述根据所述任务消息队列执行所述目标微服务任务对应的操作，确定所述目标微服务任务对应的目标操作结果，将所述目标操作结果写入结果消息队列，包括：

获取所述第一任务消息队列中的至少一个第一微服务任务；

执行所述第一微服务任务对应的操作，确定所述第一微服务任务对应的第一操作结果，将所述第一操作结果写入所述第二任务消息队列；以及

获取所述第二任务消息队列中的至少一个第一操作结果，基于所述至少一个第一操作结果，执行所述第二微服务任务对应的操作，确定所述第二微服务任务对应的第二操作结果，将所述第二操作结果写入所述任务消息队列。

TS6、如TS1所述的方法，其中，所述根据接收到的业务请求确定对应的至少一个目标微服务任务，将所述目标微服务任务写入任务消息队列，包括：

根据接收到的业务请求，执行预先设置的主服务操作，确定所述业务请求对应的至少一个目标微服务任务；以及

将所述目标微服务任务写入所述任务消息队列。

TS7、如TS6所述的方法，其中，所述方法还包括：

响应于预设单位时间内，所述业务请求的数量达到业务数量阈值，暂停接收所述业务请求。

TS8、如TS1所述的方法，其中，所述业务请求包括请求端标识，所述目标操作结果包括所述请求端标识；

所述发送所述至少一个目标操作结果，包括：

基于所述请求端标识，确定目标业务请求端；以及

向所述目标业务请求端发送所述至少一个目标操作结果。

TS9、如TS1所述的方法，其中，基于flink框架中的任务管理器单元，执行所述根据所述任务消息队列执行所述目标微服务任务对应的操作，确定所述目标微服务任务对应的目标操作结果，将所述目标操作结果写入结果消息队列；基于kafka系统，构建消息队列。

TS10、一种线上服务装置，其中，所述装置包括：

主服务入口模块，用于根据接收到的业务请求确定对应的至少一个目标微服务任务，将所述目标微服务任务写入任务消息队列；

微服务模块，用于根据所述任务消息队列执行所述目标微服务任务对应的操作，确定所述目标微服务任务对应的目标操作结果，将所述目标操作结果写入结果消息队列；以及

主服务出口模块，用于获取结果消息队列中的至少一个目标操作结果，并发送所述至少一个目标操作结果。

TS11、如TS10所述的装置，其中，所述主服务入口模块，具体用于：

根据接收到的业务请求确定对应的至少一个目标微服务；

生成所述目标微服务对应的目标微服务任务；以及

针对每个目标微服务任务，将所述目标微服务任务写入对应目标微服务的任务消息队列中。

TS12、如TS11所述的装置，其中，所述微服务模块，具体用于：

获取所述任务消息队列中的至少一个目标微服务任务；

分别执行各所述目标微服务任务对应的操作，确定每个所述目标微服务任务对应的目标操作结果；以及

将各目标操作结果写入结果消息队列。

TS13、如TS11所述的装置，其中，所述目标微服务包括第一微服务和第二微服务，所述第一微服务对应第一微服务任务和第一任务消息队列，所述第二微服务对应第二微服务任务和第二任务消息队列，所述任务消息队列包括所述第一任务消息队列和所述第二任务消息队列；

所述主服务入口模块，具体用于：

将所述第一微服务任务写入所述第一微服务对应的第一任务消息队列中；以及

将所述第二微服务任务写入所述第二微服务对应的第二任务消息队列中。

TS14、如TS13所述的装置，其中，所述微服务模块，具体用于：

获取所述第一任务消息队列中的至少一个第一微服务任务；

执行所述第一微服务任务对应的操作，确定所述第一微服务任务对应的第一操作结果，将所述第一操作结果写入所述第二任务消息队列；以及

获取所述第二任务消息队列中的至少一个第一操作结果，基于所述至少一个第一操作结果，执行所述第二微服务任务对应的操作，确定所述第二微服务任务对应的第二操作结果，将所述第二操作结果写入所述任务消息队列。

TS15、如TS10所述的装置，其中，所述主服务入口模块，具体用于：

根据接收到的业务请求，执行预先设置的主服务操作，确定所述业务请求对应的至少一个目标微服务任务；以及

将所述目标微服务任务写入所述任务消息队列。

TS16、如TS15所述的装置，其中，所述装置还包括：

限流模块，用于响应于预设单位时间内，所述业务请求的数量达到业务数量阈值，暂停接收所述业务请求。

TS17、如TS10所述的装置，其中，所述业务请求包括请求端标识，所述目标操作结果包括所述请求端标识；

所述主服务出口模块，具体用于：

基于所述请求端标识，确定目标业务请求端；以及

向所述目标业务请求端发送所述至少一个目标操作结果。

TS18、如TS10所述的装置，其中，基于flink框架中的任务管理器单元，执行所述微服务模块对应的动作；基于kafka系统，构建消息队列。

TS19、一种电子设备，包括存储器和处理器，其中，所述存储器用于存储一条或多条计算机程序指令，其中，所述一条或多条计算机程序指令被所述处理器执行以实现如TS1-TS9中任一项所述的方法。

TS20、一种计算机可读存储介质，其中，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现TS1-TS9任一项所述的方法。