业务重试方法、装置、存储介质及电子设备与流程

1.本公开涉及计算机技术领域，具体地，涉及一种业务重试方法、装置、存储介质及电子设备。


背景技术：

2.互联网时代信息量巨大，需要超强的计算能力对信息进行处理，并且还存在对用户响应速度快、吞吐量大等业务需求。因此，单节点的业务服务提供方式已无法满足需求，需要进行分布式的业务服务。但是，分布式业务服务可能会出现特定场景下的特定问题，比如业务服务之间远程调用失败、数据库保存失败、数据同步缓存失败等问题，导致业务执行失败。在此种情况下，则需要进行业务重试。
3.相关技术中，针对不同的业务场景，通常需要单独编写业务重试代码，如果业务场景发生改变，则需要耗费大量的人力和时间重新编写业务重试代码，研发成本较高，无法较好的适用于不同的业务场景。


技术实现要素：

4.本公开的目的是提供一种业务重试方法、装置、存储介质及电子设备，以提供一种通用的业务重试方法。
5.为了实现上述目的，第一方面，本公开提供一种业务重试方法，所述方法包括：
6.记录每类业务下的目标业务项的执行参数，所述业务包括多个业务项，所述目标业务项是指所属业务发生异常的情况下需要重试的业务项；
7.在所述目标业务项所属的业务发生异常的情况下，将所述目标业务项的名称和执行参数发送给业务重试服务器，以使所述业务重试服务器根据所述目标业务项的名称和执行参数，生成针对所述业务的虚拟业务请求；
8.响应于所述业务重试服务器发送的虚拟业务请求，重新执行所述目标业务项。
9.可选地，所述方法还包括：
10.设置用于业务重试的回调接口；
11.所述重新执行所述目标业务项，包括：
12.通过所述回调接口，根据所述目标业务项的名称和执行参数，调用所述目标业务项对应的类和/或方法，以重新执行所述目标业务项。
13.可选地，所述虚拟业务请求是所述业务重试服务器通过泛化调用的方式生成的。
14.可选地，所述业务重试服务器用于将接收到的所述目标业务项的执行参数和名称存入延迟队列中，所述虚拟业务请求是所述业务重试服务器在预设业务重试时间后，从所述延迟队列中获取所述目标业务项的执行参数和名称后生成的。
15.可选地，所述记录每类业务下的目标业务项的执行参数，包括：
16.针对每类业务，响应于所述业务的运行，监听所述业务的目标业务项；
17.通过面向切面编程aop的方式，在执行所述目标业务项之前，记录所述目标业务项
的执行参数。
18.可选地，所述方法还包括：
19.针对每类业务发生异常的情况下需要重试的业务项，添加重试标识；
20.所述监听所述业务的目标业务项，包括：
21.监听所述业务下添加有所述重试标识的业务项。
22.可选地，所述将所述目标业务项的名称和执行参数发送给业务重试服务器，包括：
23.通过消息中间件将所述目标业务项的名称和执行参数发送给所述业务重试服务器。
24.第二方面，本公开还提供一种业务重试方法，所述方法包括：
25.接收目标业务项的名称和执行参数，所述目标业务项的名称和执行参数是用于业务执行的业务服务器在所述业务发生异常的情况下发送给所述业务重试服务器的，其中，所述业务包括多个业务项；
26.根据所述目标业务项的名称和执行参数，生成针对所述业务的虚拟业务请求；
27.发送所述虚拟业务请求给所述业务服务器。
28.第三方面，本公开还提供一种业务重试装置，所述装置包括：
29.记录模块，被配置为记录每类业务下的目标业务项的执行参数，所述业务包括多个业务项，所述目标业务项是指所属业务发生异常的情况下需要重试的业务项；
30.第一发送模块，被配置为在所述目标业务项所属的业务发生异常的情况下，将所述目标业务项的名称和执行参数发送给业务重试服务器，以使所述业务重试服务器根据所述目标业务项的名称和执行参数，生成针对所述业务的虚拟业务请求；
31.执行模块，被配置为响应于所述业务重试服务器发送的虚拟业务请求，重新执行所述目标业务项。
32.第四方面，本公开还提供一种业务重试装置，所述装置包括：
33.接收模块，被配置为接收目标业务项的名称和执行参数，所述目标业务项的名称和执行参数是用于业务执行的业务服务器在所述业务发生异常的情况下发送给所述业务重试服务器的，其中，所述业务包括多个业务项；
34.生成模块，被配置为根据所述目标业务项的名称和执行参数，生成针对所述业务的虚拟业务请求；
35.第二发送模块，被配置为发送所述虚拟业务请求给所述业务服务器。
36.第五方面，本公开还提供一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现第一方面中任一项所述方法的步骤。
37.第六方面，本公开还提供一种电子设备，包括：
38.存储器，其上存储有计算机程序；
39.处理器，用于执行所述存储器中的所述计算机程序，以实现第一方面中任一项所述方法的步骤。
40.通过上述技术方案，可以在业务发生异常的情况下，将需要重试的业务项的名称和执行参数发送给业务重试服务器，以使业务重试服务器根据接收到的业务项的名称和执行参数生成虚拟业务请求，然后用于执行业务的业务服务器可以响应于业务重试服务器发送的虚拟业务请求，重新执行需要重试的业务项，无需单独开发业务重试代码，业务服务器
可以响应于虚拟业务请求通过重新执行原有业务代码实现业务重试，可以适用于不同的业务场景，提高了业务重试方法的通用性。
41.本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
42.附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：
43.图1是根据本公开一示例性实施例示出的一种业务重试方法的实施场景示意图；
44.图2是根据本公开一示例性实施例示出的一种业务重试方法的流程图；
45.图3是根据本公开另一示例性实施例示出的一种业务重试方法的实施场景示意图；
46.图4是根据本公开另一示例性实施例示出的一种业务重试方法的流程图；
47.图5是根据本公开一示例性实施例示出的一种业务重试装置的框图；
48.图6是根据本公开另一示例性实施例示出的一种业务重试装置的框图；
49.图7是根据本公开一示例性实施例示出的一种电子设备的框图。
具体实施方式
50.以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。
51.正如背景技术所言，分布式业务服务可能会出现特定场景下的特定问题，比如业务服务之间远程调用失败、数据库保存失败、数据同步缓存失败等问题，导致业务执行失败。在此种情况下，则需要进行业务重试。
52.发明人研究发现，相关技术中，针对不同的业务场景，通常是编写单独的业务重试代码，实现业务重试。比如，通常是编写业务重试代码，比对业务执行过程中每个执行步骤的结果数据，确定结果数据与前后步骤的结果数据不相符的执行步骤，然后重新执行该步骤。针对具有不同执行步骤的业务场景，则需要耗费大量的人力和时间重新编写业务重试代码，研发成本较高，无法较好的适用于不同的业务场景。
53.有鉴于此，本公开实施例提供一种业务重试方法、装置、存储介质及电子设备，以提供一种通用的业务重试方法，减少用于业务重试的代码研发成本，更好的适用于不同的业务重试场景。
54.首先说明本公开实施例中业务重试方法可能的实施场景。参照图1，该实施场景包括用于执行业务的业务服务器和用于生成虚拟业务请求的业务重试服务器。其中，业务服务器可以接收客户端发送的、由用户触发的实际业务请求，并响应于该实际业务请求，执行业务，然后向客户端返回业务执行结果。业务重试服务器可以接收业务服务器在业务异常的情况下发送的、需要重试的业务项的名称和执行参数，并根据该名称和执行参数，生成虚拟业务请求，以触发业务服务器重新执行需要重试的业务项，从而实现通用的业务重试方法。应当理解的是，本公开实施例中所述的服务器可以是硬件服务器，也可以是云服务器，等等，本公开实施例对此不作限定，图1以硬件服务器进行示意。
55.图2是根据本公开一示例性实施例示出的一种业务重试方法的流程图。参照图2，
该业务重试方法可以用于业务服务器，包括：
56.步骤201，记录每类业务下的目标业务项的执行参数，该业务包括多个业务项，目标业务项是指所属业务发生异常的情况下需要重试的业务项。
57.步骤202，在目标业务项所属的业务发生异常的情况下，将目标业务项的名称和执行参数发送给业务重试服务器，以使业务重试服务器根据目标业务项的名称和执行参数，生成针对业务的虚拟业务请求。
58.步骤203，响应于业务重试服务器发送的虚拟业务请求，重新执行目标业务项。
59.通过上述技术方案，可以在业务发生异常的情况下，将需要重试的业务项的名称和执行参数发送给业务重试服务器，以使业务重试服务器根据接收到的业务项的名称和执行参数生成虚拟业务请求，然后业务服务器可以响应于业务重试服务器发送的虚拟业务请求，重新执行需要重试的业务项，无需单独开发业务重试代码，业务服务器可以响应于虚拟业务请求通过重新执行原有业务代码实现业务重试，可以适用于不同的业务场景，提高了业务重试方法的通用性。
60.另外，通过上述技术方案，由于是通过业务服务器的原有业务代码实现业务重试，因此每一次业务重试过程也可以看作是一次正常的业务执行过程，那么当业务重试失败后，即可以认为是业务发生异常，从而可以再次执行本公开提供的业务重试方法，直到业务执行成功。相较于业务重试失败则丢弃该业务执行结果的方式，本公开的业务重试方法，可以减少由于单次业务重试失败而导致其他业务线程阻塞的问题，充分保证其他业务的正常执行。
61.为了使得本领域技术人员更加理解本公开提供的业务重试方法，下面对上述各步骤进行详细举例说明。
62.示例地，本公开实施例中的业务可以包括多个业务项，例如在外卖应用程序中，用户的点餐业务，可以包括记录用户已点餐品的业务项、结算用户待支付费用的业务项、提交用户已支付订单的业务项等等。业务的每个业务项可以通过对应的类和/或方法实现对应的业务功能，比如通过面向对象编程语言java实现本公开实施例中的业务重试方法，那么每个业务项可以通过对应的java类和/或java方法实现对应的业务功能。因此，需要重试的业务项可以对应于需要重试的类和/或方法，业务项的执行参数可以包括类的执行参数和/或方法的执行参数。
63.在实际应用中，业务服务器可以执行多类业务，比如在外卖应用程序中，除了上述用户点餐业务外，可能还包括结算配送员配送费的业务等。因此，在步骤201中，可以记录每类业务下的目标业务项的执行参数。其中，目标业务项是指所属业务发生异常的情况下需要重试的业务项，对于不同类的业务，需要重试的业务项可能不同，因此目标业务项也可能有所不同。
64.在可能的方式中，记录目标业务项的执行参数可以是：先针对每类业务，响应于业务的运行，监听业务的目标业务项，再通过面向切面编程aop的方式，在执行目标业务项之前，记录目标业务项的执行参数。
65.示例地，监听业务的目标业务项可以是：先针对每类业务发生异常的情况下需要重试的业务项，添加重试标识，然后监听业务下添加有重试标识的业务项。
66.也即是说，可以对业务异常时需要重试的业务项进行预先标记，从而在业务异常
时，通过监听具有预先标记的业务项，则可以确定目标业务项。前文已有说明，业务项可以通过对应的类和/或方法实现对应的业务功能。因此，对需要重试的业务项添加重试标记，可以是对需要重试的业务项所对应的类和/或方法添加重试标记。
67.示例地，重试标记的具体形式可以根据实际需要设定，本公开实施例对此不作限定。例如，针对需要重试的类，其重试标记可以为@redoclass注解，而针对需要重试的方法，其添加的重试标记可以为@redomethod注解，或者，针对需要重试的类和方法，其重试标记可以为任意数字和字母的组合，等等。通过添加重试标记的方式，可以在业务发生异常的情况下，快速确定需要重试的业务项，从而更加快速的执行后续业务重试步骤，一定程度上可以提高业务重试效率。
68.在确定需要重试的目标业务项之后，可以通过面向切面编程aop的方式，在执行目标业务项之前，记录目标业务项的执行参数。其中，aop可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序代码的可重用性，进一步提升业务重试方法的通用性。
69.例如，本公开的业务重试方法可以集成在软件开发工具包sdk中，并且可以在sdk中实现org.springframework.context.applicationlistener监听接口，因此当业务运行时，可以通过该监听接口监听所有带重试标记的类和/或方法，然后可以通过aop的方式，在执行这些类和/或方法之前，记录这些类和/或方法的执行参数，从而实现记录目标业务项的执行参数的目的。
70.在记录目标业务项的执行参数之后，可以在步骤202中，在目标业务项所属的业务发生异常的情况下，将目标业务项的名称和执行参数发送给业务重试服务器，以使业务重试服务器根据目标业务项的名称和执行参数，生成针对该业务的虚拟业务请求。
71.在可能的方式中，可以通过消息中间件将目标业务项的名称和执行参数发送给业务重试服务器。示例地，消息中间件可以是mq(message queue)消息队列，或者也可以是其他类型的消息中间件，本公开实施例对此不作限定。
72.应当理解的是，mq消息队列是基础数据结构中先进先出的一种数据机构，生产者产生消息并把消息放入队列，然后由消费者去处理。消费者可以到指定队列拉取消息，或者订阅相应的队列，然后由mq服务端给其推送消息。通过mq消息队列可以解决应用解耦、异步消息、流量削锋等问题，实现高性能、高可用、可伸缩和最终一致性的业务架构。因此，在本公开实施例中，优选地，可以通过mq消息队列将目标业务项的名称和执行参数发送给业务重试服务器。
73.例如，参照图3，通过mq消息队列将目标业务项的名称和执行参数发送给业务重试服务器。业务服务器作为生产者可以在业务发生异常时，将需要重试的目标业务项的名称和执行参数构造成重试事件，放入mq队列中。然后，业务重试服务器作为消费者可以从mq队列获取该重试事件，从而获取目标业务项的名称和执行参数。进一步，业务重试服务器可以根据获取到的目标业务项的名称和执行参数，生成虚拟业务请求发送给业务服务器。
74.在可能的方式中，虚拟业务请求可以是业务重试服务器通过泛化调用的方式生成的。其中，泛化调用可以使得服务消费者端在没有服务提供者端提供的服务接口的情况下完成服务的调用。在本公开实施例中，服务消费者端可以是业务重试服务器，服务提供者端可以是业务服务器，业务重试服务器通过泛化调用的方式生成虚拟业务请求，从而业务服
务器可以响应于该虚拟业务请求，调用需要重试的业务项，最终实现业务重试。通过此种方式，无需针对不同的业务服务器编写对应的接口调用代码，可以跨平台生成虚拟业务请求，进一步提升了业务重试的通用性。
75.应当理解的是，泛化调用的方式可以包括thrift泛化调用方式、dubbo泛化调用方式等等，本公开实施例对此不作限定。
76.在可能的方式中，业务重试服务器可以用于将接收到的目标业务项的执行参数和名称存入延迟队列中，相应地，虚拟业务请求可以是业务重试服务器在预设业务重试时间后，从延迟队列中获取目标业务项的执行参数和名称后生成的。
77.在实际应用中，业务执行失败可能是由于暂时的网络问题导致的，如果在业务执行失败后立即进行业务重试，很大程度上还是会得到业务执行失败的结果，但是如果在一定时间之后再进行业务重试，则可以得到业务执行成功的结果，实现业务重试的目的。因此，在本公开实施例中，虚拟业务请求可以是业务重试服务器在预设业务重试时间后，从延迟队列中获取目标业务项的执行参数和名称后生成的。
78.其中，预设业务重试时间可以是针对不同的业务项进行预先设定的，本公开实施例对此不作限定。示例地，预设业务重试时间可以是业务服务器发送给业务重试服务器的，在此种情况下，业务服务器发送给业务重试服务器的数据除了目标业务项的名称和执行参数，还可以包括目标业务项对应的预设业务重试时间。或者，预设业务重试时间可以是业务运维人员根据实际情况设定、并预先存入业务重试服务器的。在此种情况下，每一预设业务重试时间可以具有唯一的业务项标识，从而可以根据该业务标识确定该预设业务重试时间对应的业务项。
79.按照上述方式，业务重试服务器在接收到业务服务器发送的目标业务项的名称和执行参数后，可以先将该目标业务项的名称和执行参数进行存储，比如将目标业务项的名称和执行参数存储到延迟队列中。然后，在业务重试服务器的系统时间达到预设业务重试时间后，或者可以从业务重试服务器接收到目标业务项的名称和执行参数后进行计时，当计时达到预设业务重试时间后，从延迟队列中获取目标业务项的执行参数和名称，最后业务重试服务器可以根据目标业务项的执行参数和名称，生成虚拟业务请求，并将虚拟业务请求发送给业务服务器。
80.相应地，业务服务器可以响应于业务重试服务器发送的虚拟业务请求，重新执行目标业务项。在可能的方式中，可以设置用于业务重试的回调接口，那么重新执行目标业务项，可以是：通过回调接口，根据目标业务项的名称和执行参数，调用目标业务项对应的类和/或方法，以重新执行目标业务项。
81.示例地，业务重试服务器发送的虚拟业务请求可以包括目标业务项的名称和执行参数，因此业务服务器在接收到该虚拟业务请求后，可以通过回调接口，根据目标业务项的名称和执行参数，调用该目标业务项对应的类和/或方法。比如，可以先根据目标业务项的名称，确定待调用的类和/或方法的名称，然后通过回调接口，将执行参数传入待调用的类/或方法中进行执行，从而实现重新执行目标业务项的目的。
82.正如前文举例说明的，本公开实施例中的业务重试方法可以集成在sdk中，相应地，可以在sdk中预置一个回调接口，从而在业务执行过程中，若发生业务异常，则可以通过回调接口，回调需要重试的业务项所对应的类和/或方法，以通过业务服务器原有的业务代
码实现业务重试。通过此种方式，无需单独编写业务重试代码，可以适用于不同的业务场景，提高了业务重试方法的通用性。
83.应当理解的是，java反射机制可以在运行状态中确定任意类的所有方法和属性，并调用任意对象的方法和属性。因此，在本公开实施例中，若通过java语言实现业务重试方法，那么在获取到目标业务项的名称和执行参数后，基于java反射机制，是可以实现业务重试的。
84.基于同一发明构思，本公开实施例还提供一种业务重试方法，应用于业务重试服务器。参照图4，该业务重试方法包括：
85.步骤401，接收目标业务项的名称和执行参数，目标业务项的名称和执行参数是用于业务执行的业务服务器在业务发生异常的情况下发送给业务重试服务器的，其中，所述业务包括多个业务项。
86.步骤402，根据目标业务项的名称和执行参数，生成针对该业务的虚拟业务请求。
87.步骤403，发送虚拟业务请求给业务服务器。
88.通过上述技术方案，业务重试服务器可以在业务发生异常的情况下，接收目标业务项的名称和执行参数，并根据接收到的业务项的名称和执行参数生成虚拟业务请求，然后可以将该虚拟业务请求发送给业务服务器，从而使得业务服务器可以响应于该虚拟业务请求，重新执行需要重试的业务项，无需单独开发业务重试代码，可以适用于不同的业务场景，提高了业务重试方法的通用性。
89.在可能的方式中，步骤402可以是根据目标业务项的名称和执行参数，通过泛化调用的方式生成针对该业务的虚拟业务请求。通过此种方式，可以跨平台生成虚拟业务请求，进一步提升了业务重试的通用性。
90.在实际应用中，业务执行失败可能是由于暂时的网络问题导致的，如果在业务执行失败后立即进行业务重试，很大程度上还是会得到业务执行失败的结果，但是如果在一定时间之后再进行业务重试，则可以得到业务执行成功的结果，实现业务重试的目的。因此，在可能的方式中，业务重试服务器还可以将接收到的目标业务项的执行参数和名称存入延迟队列中，相应地，步骤402可以是：在预设业务重试时间后，从延迟队列中获取目标业务项的执行参数和名称，然后根据获取到的、目标业务项的名称和执行参数，生成针对该业务的虚拟业务请求。通过这样的方式，可以在业务异常之后，延迟进行业务重试，避免业务重试的失败。
91.在可能的方式中，步骤401可以是：通过消息中间件接收目标业务项的名称和执行参数。通过此种方式，业务服务器可以将目标业务项的名称和执行参数发送到消息中间件，然后业务重试服务器从消息中间件获取目标业务项的名称和执行参数，通过此种方式，可以实现异步消息，实现业务服务器和业务重试服务器之间的解耦，进一步提升业务重试方法的通用性。
92.关于上述实施例中的业务重试服务器侧的业务重试方法的执行过程，其中各个步骤的具体方式已经在业务服务器侧的方法实施例中进行了详细描述，此处将不做详细阐述说明。
93.下面参照图3的实施场景示意图，通过另一示例性实施例对业务服务器和业务重试服务器之间的交互过程进行说明。
94.业务服务器可以针对每类业务发生异常的情况下需要重试的业务项，添加重试标识，然后针对每类业务，可以响应于业务的运行，监听每类业务下添加有重试标识的业务项。接着，可以通过面向切面编程aop的方式，在执行目标业务项(即添加有重试标识的业务项)之前，记录目标业务项的执行参数。在目标业务项所属的业务发生异常的情况下，将目标业务项的名称和执行参数构造成重试事件，并通过消息中间件将重试事件发送给业务重试服务器。
95.业务重试服务器接收业务服务器发送的重试事件，从而获得目标业务项的名称和执行参数，然后将目标业务项的执行参数和名称存入延迟队列中。在预设业务重试时间后，业务重试服务器可以从延迟队列中获取目标业务项的执行参数和名称，然后根据获取到的、目标业务项的名称和执行参数，通过thrift泛化调用的方式生成虚拟业务请求。最后，业务重试服务器可以将虚拟业务请求发送给业务服务器。
96.业务服务器可以响应于业务重试服务器发送的虚拟业务请求，通过回调接口，根据虚拟业务请求包括的目标业务项的名称和执行参数，调用目标业务项对应的类和/或方法，以重新执行目标业务项，实现业务重试的目的。
97.通过上述方式，无需单独开发业务重试代码，可以响应于虚拟业务请求通过重新执行业务服务器的原有业务代码实现业务重试，可以适用于不同的业务场景，提高了业务重试方法的通用性。并且，业务重试服务器可以对存储在延迟队列中的业务重试事件进行管理，比如进行重试事件查询、重试时间调整等，满足不同业务重试场景下的业务需求，进一步提升业务重试方法的通用性。
98.基于同一发明构思，本公开实施例还提供一种业务重试装置，该装置可以通过软件、硬件或者两者结合的方式成为业务服务器的部分或全部。参照图5，该业务重试装置500可以包括：
99.记录模块501，被配置为记录每类业务下的目标业务项的执行参数，所述业务包括多个业务项，所述目标业务项是指所属业务发生异常的情况下需要重试的业务项；
100.第一发送模块502，被配置为在所述目标业务项所属的业务发生异常的情况下，将所述目标业务项的名称和执行参数发送给业务重试服务器，以使所述业务重试服务器根据所述目标业务项的名称和执行参数，生成针对所述业务的虚拟业务请求；
101.执行模块503，被配置为响应于所述业务重试服务器发送的虚拟业务请求，重新执行所述目标业务项。
102.通过上述装置，可以在业务发生异常的情况下，将需要重试的业务项的名称和执行参数发送给业务重试服务器，以使业务重试服务器根据接收到的业务项的名称和执行参数生成虚拟业务请求，然后业务服务器可以响应于业务重试服务器发送的虚拟业务请求，重新执行需要重试的业务项，无需单独开发业务重试代码，业务服务器可以响应于虚拟业务请求通过重新执行原有业务代码实现业务重试，可以适用于不同的业务场景，提高了业务重试方法的通用性。
103.可选地，所述装置500还包括：
104.设置模块，被配置为设置用于业务重试的回调接口；
105.所述执行模块503被配置为：
106.通过所述回调接口，根据所述目标业务项的名称和执行参数，调用所述目标业务
项对应的类和/或方法，以重新执行所述目标业务项。
107.也即是说，本公开实施例提供的业务重试装置可以通过回调接口，回调需要重试的业务项所对应的类和/或方法，以通过业务服务器原有的业务代码实现业务重试，无需单独编写业务重试代码，可以适用于不同的业务场景，提高了业务重试方法的通用性。
108.可选地，所述虚拟业务请求是所述业务重试服务器通过泛化调用的方式生成的。因此，本公开实施例提供的业务重试装置可以跨平台生成虚拟业务请求，进一步提升了业务重试的通用性。
109.可选地，所述业务重试服务器用于将接收到的所述目标业务项的执行参数和名称存入延迟队列中，所述虚拟业务请求是所述业务重试服务器在预设业务重试时间后，从所述延迟队列中获取所述目标业务项的执行参数和名称后生成的。因此，可以在业务异常之后，延迟进行业务重试，避免业务重试的失败。
110.可选地，所述记录模块501被配置为：
111.针对每类业务，响应于所述业务的运行，监听所述业务的目标业务项；
112.通过面向切面编程aop的方式，在执行所述目标业务项之前，记录所述目标业务项的执行参数。
113.其中，aop可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序代码的可重用性，进一步提升业务重试的通用性。
114.可选地，所述装置500还包括：
115.添加模块，被配置为针对每类业务发生异常的情况下需要重试的业务项，添加重试标识；
116.所述记录模块501被配置为：
117.监听所述业务下添加有所述重试标识的业务项。
118.通过添加重试标记的方式，可以在业务发生异常的情况下，快速确定需要重试的业务项，从而更加快速的执行后续业务重试步骤，一定程度上可以提高业务重试效率。
119.可选地，所述第一发送模块502被配置为：
120.通过消息中间件将所述目标业务项的名称和执行参数发送给所述业务重试服务器。
121.通过此种方式，业务服务器可以将目标业务项的名称和执行参数发送到消息中间件，然后业务重试服务器从消息中间件获取目标业务项的名称和执行参数，通过此种方式，可以实现异步消息，实现业务服务器和业务重试服务器之间的解耦，进一步提升业务重试方法的通用性。
122.基于同一发明构思，本公开实施例还提供一种业务重试装置，该装置可以通过软件、硬件或者两者结合的方式成为业务重试服务器的部分或全部。参照图6，该业务重试装置600可以包括：
123.接收模块601，被配置为接收目标业务项的名称和执行参数，所述目标业务项的名称和执行参数是用于业务执行的业务服务器在所述业务发生异常的情况下发送给所述业务重试服务器的，其中，所述业务包括多个业务项；
124.生成模块602，被配置为根据所述目标业务项的名称和执行参数，生成针对所述业务的虚拟业务请求；
125.第二发送模块603，被配置为发送所述虚拟业务请求给所述业务服务器。
126.通过上述技术方案，业务重试服务器可以在业务发生异常的情况下，接收目标业务项的名称和执行参数，并根据接收到的业务项的名称和执行参数生成虚拟业务请求，然后可以将该虚拟业务请求发送给业务服务器，从而使得业务服务器可以响应于该虚拟业务请求，重新执行需要重试的业务项，无需单独开发业务重试代码，可以适用于不同的业务场景，提高了业务重试方法的通用性。
127.关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
128.基于同一发明构思，本公开实施例还提供一种电子设备，其特征在于，包括：
129.存储器，其上存储有计算机程序；
130.处理器，用于执行所述存储器中的所述计算机程序，以实现上述任一项业务重试方法的步骤。
131.在可能的方法中，该电子设备可以被提供为一服务器，比如业务服务器，以实现业务服务器侧的业务重试方法，或者业务重试服务器，以实现业务重试服务器侧的业务重试方法。参照图7，该电子设备700包括处理器722，其数量可以为一个或多个，以及存储器732，用于存储可由处理器722执行的计算机程序。存储器732中存储的计算机程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理器722可以被配置为执行该计算机程序，以执行上述的业务重试方法。
132.另外，电子设备700还可以包括电源组件726和通信组件750，该电源组件726可以被配置为执行电子设备700的电源管理，该通信组件750可以被配置为实现电子设备700的通信，例如，有线或无线通信。此外，该电子设备700还可以包括输入/输出(i/o)接口758。电子设备700可以操作基于存储在存储器732的操作系统，例如windows servertm，mac os xtm，unixtm，linuxtm等等。
133.在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的业务重试方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器732，上述程序指令可由电子设备700的处理器722执行以完成上述的业务重试方法。
134.在另一示例性实施例中，还提供一种计算机程序产品，该计算机程序产品包含能够由可编程的装置执行的计算机程序，该计算机程序具有当由该可编程的装置执行时用于执行上述的业务重试方法的代码部分。
135.以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。
136.另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。
137.此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。