CN113434337B - 重试策略的控制方法、装置及电子设备 - Google Patents
重试策略的控制方法、装置及电子设备 Download PDFInfo
- Publication number
- CN113434337B CN113434337B CN202110706495.XA CN202110706495A CN113434337B CN 113434337 B CN113434337 B CN 113434337B CN 202110706495 A CN202110706495 A CN 202110706495A CN 113434337 B CN113434337 B CN 113434337B
- Authority
- CN
- China
- Prior art keywords
- service
- retry
- retry strategy
- strategy
- target
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 230000000977 initiatory effect Effects 0.000 claims abstract description 7
- 230000015654 memory Effects 0.000 claims description 32
- 238000012544 monitoring process Methods 0.000 claims description 21
- 238000004891 communication Methods 0.000 claims description 11
- 230000036541 health Effects 0.000 claims description 10
- 230000006870 function Effects 0.000 claims description 5
- 230000001105 regulatory effect Effects 0.000 claims description 3
- 230000001276 controlling effect Effects 0.000 claims 3
- 230000009286 beneficial effect Effects 0.000 abstract description 6
- 230000007246 mechanism Effects 0.000 description 12
- 238000010586 diagram Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 4
- 230000003321 amplification Effects 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 3
- 238000003199 nucleic acid amplification method Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明涉及微服务技术领域，具体涉及重试策略的控制方法、装置及电子设备，所述控制方法包括获取各服务的工作状态信息，并确定引发重试的原因；基于所述引发重试的原因，确定各服务间的目标重试策略；将所述目标重试策略下发到各服务，以使得所述各服务调用所述目标重试策略进行使用。利用各服务的工作状态信息，确定各服务间的目标重试策略，实现重试策略的动态调整而并不局限于一种重试策略，即通过重试策略的统一调配，有利于优先保证整体系统的稳定。
Description
技术领域
本发明涉及微服务技术领域，具体涉及重试策略的控制方法、装置及电子设备。
背景技术
重试机制是微服务架构分布式系统中常用的服务调用容错以及提升成功率的手段。例如，如图1a所示，正常的服务交互流程，ServiceA通过HTTP接口或者通过RPC去访问ServiceB，在系统没有出现任何问题的情况下，ServiceB会返回正常的数据。如图1b所示，当由于某些原因ServiceB无法正常返回时，接口请求会失败。其中，导致失败的原因有很多，例如，ServiceB自身的问题，ServiceB暂停维护导致短暂的不可用，又或者是网络抖动因素导致的等等。
重试就是为了解决这种暂时的不可用现象，提升服务调用的成功率。如图1c所示，一次请求结果的状态不可控、不稳定，多试几次就能很好的避开网络抖动或其他升级维护等原因带来的系统不可用问题。
现有技术中常用的重试策略有设置固定的重试次数或设置固定的重试间隔。然而，上述几种重试策略中若被调用的服务处于高负载状态，由于重试机制的存在，被调用的服务的调用次数会快速增大，也可能会造成调用次数的放大，进而导致整个系统的雪崩。
发明内容
有鉴于此，本发明实施例提供了一种重试策略的控制方法、装置及电子设备，以解决重试所导致的系统雪崩的问题。
根据第一方面，本发明实施例提供了一种重试策略的控制方法，包括：
获取各服务的工作状态信息，并确定引发重试的原因；
基于所述引发重试的原因，确定各服务间的目标重试策略；
将所述目标重试策略下发到各服务，以使得各服务调用所述目标重试策略进行使用。
本发明实施例提供的重试策略的控制方法，利用各服务的工作状态信息，确定各服务间的目标重试策略，实现重试策略的动态调整而并不局限于一种重试策略，即通过重试策略的统一调配，有利于优先保证整体系统的稳定。
结合第一方面，在第一方面第一实施方式中，所述获取各服务的工作状态信息，并确定引发重试的原因，包括：
获取各服务上报的重试数据；
获取各服务的监测数据；
基于所述重试数据以及所述监测数据，确定引发重试的原因。
本发明实施例提供的重试策略的控制方法，利用重试数据以及监测数据确定引发重试的原因，重试数据与监测数据均能够反应各服务的运行情况，可以保证所确定出的引发重试的原因的可靠性。
结合第一方面第一实施方式，在第一方面第二实施方式中，所述获取各服务的监测数据，包括：
从监控中心获取所述各服务的服务运行数据，以得到所述监测数据，和从注册中心获取所述各服务的健康检查数据，以得到所述监测数据。
结合第一方面，在第一方面第三实施方式中，所述基于所述引发重试的原因，确定各服务间的目标重试策略，包括：
获取重试原因与重试策略的对应关系；
基于所述对应关系以及所述引发重试的原因，确定各服务间的目标重试策略。
本发明实施例提供的重试策略的控制方法，利用重试原因与重试策略的对应关系，可以便捷的确定出各服务间的目标重试策略，提高了目标重试策略确定的效率。
结合第一方面第三实施方式，在第一方面第四实施方式中，所述基于所述对应关系以及所述引发重试的原因，确定各服务间的目标重试策略，包括：
获取各服务间的优先级；
基于所述对应关系、所述引发重试的原因以及所述各服务间的优先级，确定各服务间的目标重试策略。
本发明实施例提供的重试策略的控制方法，在目标重试策略的确定过程中结合各服务的优先级，可以使得所确定出的目标重试策略能够满足业务的实际需求。
结合第一方面，在第一方面第五实施方式中，所述将所述目标重试策略下发到各服务，以使得所述各服务调用所述目标重试策略进行使用，包括：
将所述目标重试策略下发至各服务的基于配置中心的动态重试策略实现库，以使得所述各服务引用与其对应的所述动态重试策略实现库中的目标重试策略进行使用；所述动态重试策略实现库与所述各服务一一对应且彼此独立，所述动态重试策略实现库用于单独实现与配置中心的信息上传和接收。
根据第二方面，本发明实施例还提供了一种重试策略的调整方法，包括，
各服务启动时，将各自的当前重试策略上传至配置中心，相应地，配置中心就可以获取到各服务的当前重试策略；
如配置中心决定需要调整各服务之间的重试策略，则将确定出的目标重试策略下发给各服务；
各服务调用所述目标重试策略进行使用，以调整所述各服务的工作状态；
当调整后的各服务工作稳定时，配置中心将获取到的所述当前重试策略再下发给各服务，各服务重新调用所述当前重试策略进行使用。
本发明实施例提供的重试策略的调整方法，在各服务工作稳定后，再将重试策略恢复成之前的重试策略，以保证各服务的正常运行。
根据第三方面，本发明实施例还提供了一种重试策略的控制装置，包括：
获取模块，用于获取各服务的工作状态信息，并确定引发重试的原因；
确定模块，用于基于所述引发重试的原因，确定各服务间的目标重试策略。
第一下发模块，用于将所述目标重试策略下发到各服务，以使得所述各服务调用所述目标重试策略进行使用。
本发明实施例提供的重试策略的控制装置，利用各服务的工作状态信息，确定各服务间的目标重试策略，实现重试策略的动态调整而并不局限于一种重试策略，即通过重试策略的统一调配，有利于优先保证整体系统的稳定。
根据第四方面，本发明实施例还提供了一种重试策略的调整装置，包括：
上传模块，用于各服务启动时，将各自的当前重试策略上传至配置中心，相应地，配置中心就可以获取到各服务的当前重试策略；
第二下发模块，用于如配置中心决定需要调整各服务之间的重试策略，则将确定出的目标重试策略下发给各服务；
调用模块，用于各服务调用所述目标重试策略进行使用，以调整所述各服务的工作状态；
第三下发模块，用于当调整后的各服务工作稳定时，配置中心将获取到的所述当前重试策略再下发给各服务，各服务重新调用所述当前重试策略进行使用。
根据第五方面，本发明实施例提供了一种电子设备，包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行第一方面或者第一方面的任意一种实施方式中所述的重试策略的控制方法，或者，执行第二方面所述的重试策略的调整方法。
根据第六方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行第一方面或者第一方面的任意一种实施方式中所述的重试策略的控制方法，或者，执行第二方面所述的重试策略的调整方法。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1a-图1c示出了重试的示意图；
图2示出了微服务架构的示意图；
图3是根据本发明实施例的重试策略的控制方法的流程图；
图4是根据本发明实施例的重试策略的控制方法的流程图；
图5是根据本发明实施例的微服务架构的示意图；
图6是根据本发明实施例的重试策略的控制方法的流程图；
图7是根据本发明实施例的微服务架构的示意图；
图8a是根据本发明实施例的重试策略的控制示意图；
图8b是根据本发明实施例的重试策略的控制示意图；
图9是根据本发明实施例的重试策略的调整方法的流程图；
图10是根据本发明实施例的重试策略的控制装置的结构框图；
图11是根据本发明实施例的重试策略的调整装置的结构框图；
图12是本发明实施例提供的电子设备的硬件结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
为下文描述方便，此处对本文涉及到的技术术语解释如下：
(1)微服务架构
微服务是一种架构风格，提倡将单一应用程序通过功能分解到这个离散、独立的服务中，服务之间相互协调配合为用户提供最终价值。
微服务间松耦合，微服务内高内聚，每个服务专注自己的业务领域，独立的生命周期管理(例如，部署、更新、扩展、删除)。
(2)重试机制
重试机制是微服务架构分布式系统中常用的服务调用容错以及提升成功率的手段，当一次调用失败时，再发起一次或者多次调用。使用重试机制可以提高请求的最终成功率，减少故障影响让系统运行得更稳定。
(3)配置中心
微服务架构中通过配置中心将各服务的配置、参数、开关，放到一个集中的地方进行统一管理，并提供一套标准的接口。当各个服务需要获取配置的时候，就来配置中心的接口拉取，当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的配置，使之动态更新。
(4)注册中心
注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址进行调用。
图2示出了微服务架构的一种实施方式，结合图2对现有技术中的重试机制进行分析如下：
(1)重试会加大下游的负载
ServiceA调用ServiceB，重试次数为r，当ServiceB高负载时很可能调用不成功，此时因为重试机制，ServiceB被调用的量快速增大。
最严重的情况可能会被放大到r倍，不仅不能请求成功，还可能导致ServiceB的负载继续升高，甚至可能会被压垮。
(2)指数级放大
ServiceA调用ServiceC，ServiceC调用ServiceD，均设置重试次数为3。
ServiceC调用ServiceD 3次都失败了，此时ServiceC也会给ServiceA返回调用失败，ServiceA也有自己的重试机制，所以ServiceA会调用ServiceC3次，实际上ServiceC调用了ServiceD 9次。所以当调用存在多个层级的时候就会出现指数级扩大。
假设访问量为n，链路有m层，每层重试次数为r，则最后一层受到的访问量为n*r^(m-1)，这种规模的放大效应很明显，可能导致整个系统雪崩。
(3)重试策略变更需要修改代码重新部署上线才能生效
出现重试事故，需要关闭重试功能或者修改重试策略的话，需要修改代码重新上线才能生效。
基于此，本发明实施例提供了一种重试策略的控制方法，对各服务的重试策略进行集中控制，以保证整个系统的稳定性。
根据本发明实施例，提供了一种重试策略的控制方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
在本实施例中提供了一种重试策略的控制方法，可用于电子设备，如电脑、手机、平板电脑等。进一步地，所述的重试策略的控制方法可用于电子设备中运行的配置中心。在下文的描述中，以配置中心为进行详细描述。图3是根据本发明实施例的重试策略的控制方法的流程图，如图3所示，该流程包括如下步骤：
S11，获取各服务的工作状态信息，并确定引发重试的原因。
微服务架构中各个服务的工作状态信息可以包括各服务的服务运行数据，也可以包括各服务的服务健康检查数据，或者重试成功率等等。具体获取哪个或哪些工作状态信息，可以根据实际情况进行相应的设置。
配置中心在获取到各服务的工作状态信息之后，对其进行分析，确定引发重试的原因。在不同的场景下，引发重试的原因不同。引发重试的原因可以说是确定的，例如，服务调用不通、超时等。
关于该步骤具体将在下文中进行详细描述。
S12，基于引发重试的原因，确定各服务间的目标重试策略。
配置中心在确定出引发重试的原因之后，可以针对重试的原因确定对应的目标重试策略。
具体的配置中心可以根据静态和动态的重试次数和重试间隔的组合，衍生出如下一系列的重试策略。
线性重试：每次等待固定时间后重试；
随机重试：在一定范围内随机等待一个时间后重试；
指数重试：连续重试时，每次等待时间都是前一次的倍数；
降级重试：部分服务的重试策略不变，部分服务的重试策略关闭；
熔断重试：关闭重试机制，的带系统稳定后再恢复原来的重试策略。
依据实际使用场景，在配置中心中设置相应的重试策略，且可以设置重试策略与引发重试原因之间的对应关系，后续利用该对应关系就可以确定出各服务间的目标重试策略。
在配置中心中设置何种重试策略，以及各个重试策略与引发重试原因之间的对应关系，均是依据实际需求进行相应设置的，在本实施例中对其并未有任何限定。
可选地，可以基于配置中心开发的动态重试策略实现库，即，retry-lib，各服务引用所述的retry-lib库即可使用其中动态重试策略的功能。retry-lib库对各服务没有侵入性，各服务只需引用使用即可。使用retry-lib库后整个系统的重试策略可以通过配置中心打通融为一体，针对系统中需要调整重试策略可以灵活调配。
需要说明的是，各服务之间可以设置有对应的初始重试策略。当利用该初始重试策略进行重试机制的处理时，可能会出现重试失败的情况，那么配置中心就可以利用各服务的工作状态信息，确定出各服务间引发重试的原因，进而对各服务间的重试策略进行调整，即确定出的各服务间的目标重试策略。其中，所述的初始重试策略可以是依据业务需求指定的，也可以是用户设置的，等等。
如上文所述，各服务引用所述的retry-lib库即可使用其中动态重试策略的功能，那么在各服务启动时，可以将自己的初始重试策略以及调用哪些下游服务上报给配置中心，以使得配置中心能够获知各服务间的关系。
关于该步骤具体将在下文中进行详细描述。
S13，将目标重试策略下发到各服务，以使得各服务调用目标重试策略进行使用。
注册中心在确定出各服务间的目标重试策略之后，将目标重试策略下发到对应的服务中，相应地，各服务在接收到目标重试策略后，就调用该目标重试策略进行使用。
例如，在各服务中设置有基于配置中心的动态重试策略实现库，配置中心将目标重试策略下发到对应的动态重试策略库中，各服务引用其对应的动态重试策略实现库中的目标重试策略进行使用。
本实施例提供的重试策略的控制方法，利用各服务的工作状态信息，确定各服务间的目标重试策略，实现重试策略的动态调整而并不局限于一种重试策略，即通过重试策略的统一调配，有利于优先保证整体系统的稳定。进一步地，不同场景下，引发重试的原因不同，针对不同原因的重试策略也不同，将重试策略的配置化放到配置中心进行动态控制，可以有效的解决由于重试所导致的系统雪崩的问题。采用配置中心统一控制各业务服务在不同场景使用的重试策略，有利于优先保证整体系统的稳定。
在本实施例中提供了一种重试策略的控制方法，可用于电子设备，如电脑、手机、平板电脑等，图4是根据本发明实施例的重试策略的控制方法的流程图，如图4所示，该流程包括如下步骤：
S21，获取各服务的工作状态信息，并确定引发重试的原因。
具体地，所述的工作状态信息包括重试数据以及监测数据。上述S21包括：
S211，获取各服务上报的重试数据。
各服务可以通过引用retry-lib库上报各自的重试数据，所述的重试数据可以是重试成功率，也可以是重试次数等等；相应地，配置中心就可以获取到各服务的重试数据。
S212，获取各服务的监测数据。
各服务的监测数据包括服务运行数据以及健康检查数据，即，在微服务架构中除了设置有配置中心，还设置有监控中心以及注册中心。具体地，配置中心从监控中心获取各服务的服务运行数据，从注册中心获取各服务的健康检查数据，以得到所述监测数据。
具体地，配置中心通过监控中心的数据，例如观察到商品服务的80％的API的调用超时率超过80％，那么分析结果就是商品服务不健康了，具体的比例规则可以配置。
S213，基于重试数据以及监测数据，确定引发重试的原因。
如图5所示，配置中心根据注册中心和监控中心中对各个服务的监测数据，确定引发重试的原因，以确定是否需要调整各服务之间的重试策略。例如，ServiceA与ServiceB之间、ServiceA与ServiceC之间或ServiceC与ServiceD之间的重试策略。
S22，基于引发重试的原因，确定各服务间的目标重试策略。
详细请参见图3所示实施例的S12，在此不再赘述。
S23，将目标重试策略下发到各服务，以使得各服务调用目标重试策略进行使用。
具体地，配置中心将目标重试策略下发至各服务的基于配置中心的动态重试策略实现库，以使得各服务引用与其对应的动态重试策略实现库中的目标重试策略进行使用。
所述的动态重试策略实现库与各个服务是一一对应的，其用于单独实现与配置中心的信息上传和接收。即，各服务与配置中心之间的信息传递是基于动态重试策略实现库实现的。
本实施例提供的重试策略的控制方法，利用重试数据以及监测数据确定引发重试的原因，重试数据与监测数据均能够反应各服务的运行情况，可以保证所确定出的引发重试的原因的可靠性。
在本实施例中提供了一种重试策略的控制方法，可用于电子设备，如电脑、手机、平板电脑等，图6是根据本发明实施例的重试策略的控制方法的流程图，如图6所示，该流程包括如下步骤：
S31，获取各服务的工作状态信息，并确定引发重试的原因。
可选地，引发重试的原因包括：服务负载高、业务逻辑错误或网络问题等等。其中，所述的服务负载高可以是CPU、内存使用率过高，导致服务响应不稳定；所述的业务逻辑错误可以是业务边界场景，多业务场景交叉等产生的不在预期内的错误；所述的网络问题可以是网络抖动导致的服务调用不稳定，调用超时报错等等。
其余详细请参见图4所示实施例的S21，在此不再赘述。
S32，基于引发重试的原因，确定各服务间的目标重试策略。
具体地，上述S32包括：
S321，获取重试原因与重试策略的对应关系。
重试原因与重试策略之间的对应关系，可以是依据业务需求设置的，也可以是用户指定的，在此对其并不做任何限定，具体可以依据实际需求进行相应的设置。
S322，基于对应关系以及引发重试的原因，确定各服务间的目标重试策略。
配置中心利用上述S31中确定出的引发重试的原因，查找重试原因与重试策略的对应关系，就可以确定各服务间的目标重试策略。
S33，将目标重试策略下发到各服务，以使得各服务调用目标重试策略进行使用。
详细请参见图4所示实施例的S23，在此不再赘述。
本实施例提供的重试策略的控制方法，利用重试原因与重试策略的对应关系，可以便捷的确定出各服务间的目标重试策略，提高了目标重试策略确定的效率。
在本发明的一些可选实施方式中，上述S322可以包括：
(1)获取各服务间的优先级。
各服务间的优先级也可以依据业务需求设置在配置中心中。在系统正常工作时，各服务间不会区分谁的优先级更高；在系统出现异常时，各服务间的优先级就会体现出来了。
(2)基于对应关系、引发重试的原因以及各服务间的优先级，确定各服务间的目标重试策略。
如图7所示，微服务架构中的微服务包括云商城、订单服务、支付服务以及商品服务。其中，上述的各个服务通过引用retry-lib库，进行数据和指令的上传和下发。
具体地，配置中心将确定出的目标重试策略下发给各服务的retry-lib库，retry-lib库复用配置中心原有与微服务之间的配置热更新通信机制，进行数据和指令的上传和下发。系统运行过程中，重试策略需要变更时不再需要修改各服务的代码后重新上线才能生效，重试策略实现了热更新。
如图7所示，支付服务和订单服务都依赖商品服务。在实际系统稳定的正常业务场景下，支付服务和订单服务对商品服务配置的重试策略可能是一样的，彼此之间并不会区分谁的优先级更高。在商品服务出现不稳定的情况下，业务的优先级就体现出来了，当前的支付功能的成功率比历史订单查询成功率的优先级更高，所以需要优先保证支付服务对商品服务的重试调用。
作为本实施例中微服务架构的重试策略的控制方法如下，如图8a所示，各服务定时通过retry-lib库上报重试成功率数据到配置中心。
配置中心结合各服务上报的重试数据和从监控中心获取到的服务运行数据，决策是否需要调整各服务的重试策略。
配置中心分析结果，商品服务负载过高，且调用方(即，所述的订单服务”和“支付服务”)的重试成功率不高。
配置中心更新重试策略，下发订单服务，关闭重试调用商品服务。其中，更新的是“订单服务”调用“商品服务”的重新策略。下发订单服务是指配置中心将新的重试策略以配置更新的形式发送给“订单服务”，新的重试策略可能是减少重试的次数，也可能是直接将重试次数改为0，也就是关闭重试。
配置中心更新重试策略，下发支付服务，线性重试调整为指数重试。商品服务恢复稳定后，再重新恢复“订单服务”、“支付服务”调用“商品服务”的重试策略。其中，微服务架构中每个微服务在注册到注册中心时，都可以提供一个标准的健康检查接口(/health)给注册中心定时检测该服务的健康情况。
作为本实施例微服务架构的另一种应用场景下重试策略的控制方法如下，如图8b所示，各服务定时通过retry-lib库上报重试成功率数据到配置中心。配置中心结合各服务上报的重试数据和从注册中心获取到的服务健康检查数据，决策是否需要调整服务的重试策略。配置中心分析结果，商品服务多个实例出现健康检查异常，剩余实例的负载升高，且调用方的重试成功率不高。配置中心更新重试策略，下发订单服务，关闭重试调用商品服务；配置中心更新重试策略，下发支付服务，关闭重试调用商品服务。商品服务恢复稳定后，再重新恢复“订单服务”、“支付服务”调用“商品服务”的重试策略。
云资源商品服务提供了所有云资源商品的信息，调用方多且调用方会频繁使用重试策略，一旦出现问题会应先整个平台的稳定性，因此商品服务是核心关键服务。当商品服务压力较大时可以通过配置中心实现此种动态更新各服务重试机制的策略，起到保护核心服务的可用性和稳定性的目标。
由于微服务架构中各个服务都是独立的进程，而且可能都不是部署在一起，所以系统层面的统一协调类问题都可以通过策略的形式借助配置中心在各个服务中传递。
在目标重试策略的确定过程中结合各服务的优先级，可以使得所确定出的目标重试策略能够满足业务的实际需求。
作为本发明的一种可选实施方式，所述的重试策略的控制方法，还包括各服务基于调整后的重试策略进行工作，待工作稳定后，再恢复至原有的重试策略。具体地，所述的重试策略的控制方法还可以包括如下步骤：
(1)获取各服务的当前重试策略。
各服务通过引用retry-lib库将各自的当前重试策略上传至配置中心，相应地，配置中心就可以获取到各服务的当前重试策略。
(2)将目标重试策略下发给各服务，以使得各服务进行重试策略的调整。
配置中心利用上述方式确定出各服务间的目标重试策略，引用retry-lib库，将目标重试策略下发给对应的服务，以使得各服务进行重试策略的调整。
(3)当调整后的各服务工作稳定时，配置中心将步骤(1)中获取到的当前重试策略下发给各服务。
如上文所述，配置中心通过监测中心以及注册中心的监测数据，确定各服务的工作状态信息。在各服务基于目标重试策略工作一段时间后，配置中心确定出各服务工作稳定时，调用retry-lib库将上述步骤(1)中获取到的当前重试策略下发给各服务，以恢复之前的重试策略。
需要说明的是，所述的各服务工作稳定，可以是某个或某些服务工作稳定，也可以是微服务架构中所有服务工作稳定，等等，在此对其并不做任何限制，具体可以依据实际需求进行相应的设置。
在各服务工作稳定后，再将重试策略恢复成之前的重试策略，以保证各服务的正常运行。
本发明实施例还提供了一种重试策略的调整方法，如图9所示，包括：
S41，各服务启动时，将各自的当前重试策略上传至配置中心，相应地，配置中心就可以获取到各服务的当前重试策略。
如上文所述，在各服务中设置有基于配置中心的动态重试策略实现库，各服务利用该动态重试策略实现库将当前重试策略上传至配置中心。相应地，配置中心就可以获取到各服务的当前重试策略。配置中心在获取到各服务的当前重试策略后，对其进行存储，并采用不同的标识区分各服务的当前重试策略。
或者，各服务也可以通过消息的方式将当前重试策略上传至配置中心，以使得配置中心获取到各服务的当前重试策略。
或者，各服务也可以采用其他方式将当前重试策略上传至配置中心，具体可以依据实际需求进行相应的设置，在此对其并不做任何限定。
S42，如配置中心决定需要调整各服务之间的重试策略，则将确定出的目标重试策略下发给各服务。
关于配置中心如何调整各服务间的重试策略，请参见上文实施例所示，在此不再赘述。在本实施例中，只需保证配置中心能够确定出各服务间的目标重试策略，并将其下发给各服务即可。
S43，各服务调用目标重试策略进行使用，以调整各服务的工作状态。
各服务通过调用动态重试策略实现库使用目标重试策略，对当前工作状态进行调整。
S44，当调整后的各服务工作稳定时，配置中心将获取到的当前重试策略再下发给各服务，各服务重新调用当前重试策略进行使用。
在各服务工作稳定时，配置中心再将S41中的当前重试策略下发给对应的服务，以使得各服务调用当前重试策略继续使用。其中，关于各服务的工作稳定的监测请参见上文所述，在此不再赘述。
在本实施例中还提供了一种重试策略的控制装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
本发明实施例提供一种重试策略的控制装置，如图10所示，包括：
获取模块51，用于获取各服务的工作状态信息，并确定引发重试的原因；
确定模块52，用于基于所述引发重试的原因，确定各服务间的目标重试策略；
第一下发模块53，用于将所述目标重试策略下发到各服务，以使得所述各服务调用所述目标重试策略进行使用。
本实施例提供的重试策略的控制装置，利用各服务的工作状态信息，确定各服务间的目标重试策略，实现重试策略的动态调整而并不局限于一种重试策略，即通过重试策略的统一调配，有利于优先保证整体系统的稳定。
进一步地，关于获取模块51、确定模块52以及第一下发模块53的具体实现细节请参见上文对应的方法描述，在此不再赘述。
本发明实施例还提供了一种重试策略的调整装置，如图11所示，包括：
上传模块61，用于各服务启动时，将各自的当前重试策略上传至配置中心，相应地，配置中心就可以获取到各服务的当前重试策略；
第二下发模块62，用于如配置中心决定需要调整各服务之间的重试策略，则将确定出的目标重试策略下发给各服务；
调用模块63，用于各服务调用所述目标重试策略进行使用，以调整所述各服务的工作状态；
第三下发模块64，用于当调整后的各服务工作稳定时，配置中心将获取到的所述当前重试策略再下发给各服务，各服务重新调用所述当前重试策略进行使用。
进一步地，关于上传模块61、第二下发模块62、调用模块63以及第三下发模块64的具体实现细节，请参见上文对应的方法描述，在此不再赘述。
本实施例中的重试策略的控制装置是以功能单元的形式来呈现，这里的单元是指ASIC电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。
上述各个模块的更进一步的功能描述与上述对应实施例相同，在此不再赘述。
本发明实施例还提供一种电子设备，具有上述图10所示的重试策略的控制装置，或图11所示的重试策略的调整装置。
请参阅图12，图12是本发明可选实施例提供的一种电子设备的结构示意图，如图12所示，该电子设备可以包括：至少一个处理器71，例如CPU(Central Processing Unit，中央处理器)，至少一个通信接口73，存储器74，至少一个通信总线72。其中，通信总线72用于实现这些组件之间的连接通信。其中，通信接口73可以包括显示屏(Display)、键盘(Keyboard)，可选通信接口73还可以包括标准的有线接口、无线接口。存储器74可以是高速RAM存储器(Random Access Memory，易挥发性随机存取存储器)，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器74可选的还可以是至少一个位于远离前述处理器71的存储装置。其中处理器71可以结合图10或图11所描述的装置，存储器74中存储应用程序，且处理器71调用存储器74中存储的程序代码，以用于执行上述任一方法步骤。
其中，通信总线72可以是外设部件互连标准(peripheral componentinterconnect，简称PCI)总线或扩展工业标准结构(extended industry standardarchitecture，简称EISA)总线等。通信总线72可以分为地址总线、数据总线、控制总线等。为便于表示，图12中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
其中，存储器74可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(英文：hard diskdrive，缩写：HDD)或固态硬盘(英文：solid-state drive，缩写：SSD)；存储器74还可以包括上述种类的存储器的组合。
其中，处理器71可以是中央处理器(英文：central processing unit，缩写：CPU)，网络处理器(英文：network processor，缩写：NP)或者CPU和NP的组合。
其中，处理器71还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，缩写：ASIC)，可编程逻辑器件(英文：programmable logic device，缩写：PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：FPGA)，通用阵列逻辑(英文：generic arraylogic,缩写：GAL)或其任意组合。
可选地，存储器74还用于存储程序指令。处理器71可以调用程序指令，实现如本申请图3、4以及6实施例中所示的重试策略的控制方法，或者，实现如本申请图9实施例中所示的重试策略的调整方法。
本发明实施例还提供了一种非暂态计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的重试策略的控制方法，或重试策略的调整方法。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)、随机存储记忆体(Random Access Memory，RAM)、快闪存储器(FlashMemory)、硬盘(Hard Disk Drive，缩写：HDD)或固态硬盘(Solid-State Drive，SSD)等；所述存储介质还可以包括上述种类的存储器的组合。
虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。
Claims (10)
1.一种重试策略的控制方法，其特征在于，适用于微服务架构，所述微服务架构将应用程序通过功能分解到各个离散、独立的服务中，所述方法包括：
获取各服务的工作状态信息，并确定引发重试的原因；
基于所述引发重试的原因，确定各服务间的目标重试策略；
将所述目标重试策略下发到各服务，以使得所述各服务调用所述目标重试策略进行使用；
其中，所述将所述目标重试策略下发到各服务，以使得所述各服务调用所述目标重试策略进行使用，包括：将所述目标重试策略下发至各服务的基于配置中心的动态重试策略实现库，以使得所述各服务引用与其对应的所述动态重试策略实现库中的目标重试策略进行使用；所述动态重试策略实现库与所述各服务一一对应且彼此独立，所述动态重试策略实现库用于单独实现与配置中心的信息上传和接收。
2.根据权利要求1所述重试策略的控制方法，其特征在于，所述获取各服务的工作状态信息，并确定引发重试的原因，包括：
获取各服务上报的重试数据；
获取各服务的监测数据；
基于所述重试数据以及所述监测数据，确定引发重试的原因。
3.根据权利要求2所述重试策略的控制方法，其特征在于，所述获取各服务的监测数据，包括：
从监控中心获取所述各服务的服务运行数据，
和从注册中心获取所述各服务的健康检查数据，以得到所述监测数据。
4.根据权利要求1所述重试策略的控制方法，其特征在于，所述基于所述引发重试的原因，确定各服务间的目标重试策略，包括：
获取重试原因与重试策略的对应关系；
基于所述对应关系以及所述引发重试的原因，确定各服务间的目标重试策略。
5.根据权利要求4所述重试策略的控制方法，其特征在于，所述基于所述对应关系以及所述引发重试的原因，确定各服务间的目标重试策略，包括：
获取各服务间的优先级；
基于所述对应关系、所述引发重试的原因以及所述各服务间的优先级，确定各服务间的目标重试策略。
6.一种重试策略的调整方法，其特征在于，适用于微服务架构，所述微服务架构将应用程序通过功能分解到各个离散、独立的服务中，所述方法包括，
各服务启动时，将各自的当前重试策略上传至配置中心，相应地，配置中心就可以获取到各服务的当前重试策略；
如配置中心决定需要调整各服务之间的重试策略，则将确定出的目标重试策略下发给各服务；
各服务调用所述目标重试策略进行使用，以调整所述各服务的工作状态；
当调整后的各服务工作稳定时，配置中心将获取到的所述当前重试策略再下发给各服务，各服务重新调用所述当前重试策略进行使用，具体为将所述目标重试策略下发至各服务的基于配置中心的动态重试策略实现库，以使得所述各服务引用与其对应的所述动态重试策略实现库中的目标重试策略进行使用；所述动态重试策略实现库与所述各服务一一对应且彼此独立，所述动态重试策略实现库用于单独实现与配置中心的信息上传和接收。
7.一种重试策略的控制模块，其特征在于，适用于微服务架构，所述微服务架构将应用程序通过功能分解到各个离散、独立的服务中，所述控制模块包括：
获取模块，用于获取各服务的工作状态信息，并确定引发重试的原因；
确定模块，用于基于所述引发重试的原因，确定各服务间的目标重试策略第一下发模块，用于将所述目标重试策略下发到各服务，以使得所述各服务调用所述目标重试策略进行使用，具体用于将所述目标重试策略下发至各服务的基于配置中心的动态重试策略实现库，以使得所述各服务引用与其对应的所述动态重试策略实现库中的目标重试策略进行使用；所述动态重试策略实现库与所述各服务一一对应且彼此独立，所述动态重试策略实现库用于单独实现与配置中心的信息上传和接收。
8.一种重试策略的调整装置，其特征在于，适用于微服务架构，所述微服务架构将应用程序通过功能分解到各个离散、独立的服务中，所述装置包括：
上传模块，用于各服务启动时，将各自的当前重试策略上传至配置中心，相应地，配置中心就可以获取到各服务的当前重试策略；
第二下发模块，用于如配置中心决定需要调整各服务之间的重试策略，则将确定出的目标重试策略下发给各服务；
调用模块，用于各服务调用所述目标重试策略进行使用，以调整所述各服务的工作状态；
第三下发模块，用于当调整后的各服务工作稳定时，配置中心将获取到的所述当前重试策略再下发给各服务，各服务重新调用所述当前重试策略进行使用，具体为将所述目标重试策略下发至各服务的基于配置中心的动态重试策略实现库，以使得所述各服务引用与其对应的所述动态重试策略实现库中的目标重试策略进行使用；所述动态重试策略实现库与所述各服务一一对应且彼此独立，所述动态重试策略实现库用于单独实现与配置中心的信息上传和接收。
9.一种电子设备，其特征在于，包括：
存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行权利要求1-5中任一项所述的重试策略的控制方法，或，执行权利要求6所述的重试策略的调整方法。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使计算机执行权利要求1-5中任一项所述的重试策略的控制方法，或，执行权利要求6所述的重试策略的调整方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110706495.XA CN113434337B (zh) | 2021-06-24 | 2021-06-24 | 重试策略的控制方法、装置及电子设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110706495.XA CN113434337B (zh) | 2021-06-24 | 2021-06-24 | 重试策略的控制方法、装置及电子设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113434337A CN113434337A (zh) | 2021-09-24 |
| CN113434337B true CN113434337B (zh) | 2024-03-19 |
Family
ID=77754115
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110706495.XA Active CN113434337B (zh) | 2021-06-24 | 2021-06-24 | 重试策略的控制方法、装置及电子设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113434337B (zh) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114237748A (zh) * | 2021-12-17 | 2022-03-25 | 广州华多网络科技有限公司 | 服务重试配置方法及其装置、设备、介质、产品 |
| CN114827280B (zh) * | 2022-04-26 | 2024-04-26 | 中国建设银行股份有限公司 | 请求处理方法、装置、设备、介质 |
| CN116909815B (zh) * | 2023-08-30 | 2024-01-09 | 杭州阿里巴巴海外数字商业有限公司 | 任务重试方法、介质和计算机设备 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1835452A (zh) * | 2005-03-17 | 2006-09-20 | 联想(北京)有限公司 | 一种计算机网络策略管理系统及策略管理方法 |
| CN101068381A (zh) * | 2007-06-07 | 2007-11-07 | 中兴通讯股份有限公司 | 短消息系统及短消息重新发送方法 |
| CN101895846A (zh) * | 2010-07-23 | 2010-11-24 | 中兴通讯股份有限公司 | 自适应短消息重试控制方法及装置 |
| CN108345977A (zh) * | 2017-01-25 | 2018-07-31 | 阿里巴巴集团控股有限公司 | 一种业务处理方法及装置 |
| CN109408207A (zh) * | 2018-09-20 | 2019-03-01 | 北京小米移动软件有限公司 | 微服务访问控制方法、装置及存储介质 |
| CN109614245A (zh) * | 2018-10-11 | 2019-04-12 | 阿里巴巴集团控股有限公司 | 消息中间件的消息传递方法、装置、电子设备及存储介质 |
| CN111611057A (zh) * | 2020-04-23 | 2020-09-01 | 瑞庭网络技术（上海）有限公司 | 分布式重试方法、装置、电子设备和存储介质 |
-
2021
- 2021-06-24 CN CN202110706495.XA patent/CN113434337B/zh active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1835452A (zh) * | 2005-03-17 | 2006-09-20 | 联想(北京)有限公司 | 一种计算机网络策略管理系统及策略管理方法 |
| CN101068381A (zh) * | 2007-06-07 | 2007-11-07 | 中兴通讯股份有限公司 | 短消息系统及短消息重新发送方法 |
| CN101895846A (zh) * | 2010-07-23 | 2010-11-24 | 中兴通讯股份有限公司 | 自适应短消息重试控制方法及装置 |
| CN108345977A (zh) * | 2017-01-25 | 2018-07-31 | 阿里巴巴集团控股有限公司 | 一种业务处理方法及装置 |
| CN109408207A (zh) * | 2018-09-20 | 2019-03-01 | 北京小米移动软件有限公司 | 微服务访问控制方法、装置及存储介质 |
| CN109614245A (zh) * | 2018-10-11 | 2019-04-12 | 阿里巴巴集团控股有限公司 | 消息中间件的消息传递方法、装置、电子设备及存储介质 |
| CN111611057A (zh) * | 2020-04-23 | 2020-09-01 | 瑞庭网络技术（上海）有限公司 | 分布式重试方法、装置、电子设备和存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113434337A (zh) | 2021-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113434337B (zh) | 重试策略的控制方法、装置及电子设备 | |
| US11108859B2 (en) | Intelligent backup and recovery of cloud computing environment | |
| US7111026B2 (en) | Method and device for acquiring snapshots and computer system with snapshot acquiring function | |
| CN110399260B (zh) | 用于预测性地服务和支持解决方案的系统和方法 | |
| CN110365762B (zh) | 服务处理方法、装置、设备及存储介质 | |
| CN111209110B (zh) | 一种实现负载均衡的任务调度管理方法、系统和存储介质 | |
| CN108633311A (zh) | 一种基于调用链的并发控制的方法、装置及控制节点 | |
| RU2614569C2 (ru) | Стойка с функцией автоматического восстановления и способ автоматического восстановления для этой стойки | |
| CN112351051A (zh) | 云服务处理方法、装置、云服务器、系统及存储介质 | |
| EP2597818A1 (en) | Cluster management system and method | |
| EP2645635A1 (en) | Cluster monitor, method for monitoring a cluster, and computer-readable recording medium | |
| CN111147274B (zh) | 为集群解决方案创建高度可用的仲裁集的系统和方法 | |
| EP3591530B1 (en) | Intelligent backup and recovery of cloud computing environment | |
| CN111510480A (zh) | 一种请求发送方法、装置以及第一服务器 | |
| CN110620798A (zh) | Ftp连接的控制方法、系统、设备和存储介质 | |
| CN112214551A (zh) | 数据同步方法、系统、装置、电子设备、存储介质 | |
| CN110688252A (zh) | 一种数据的恢复方法、备份方法、装置及存储介质 | |
| CN113596195B (zh) | 公共ip地址管理方法、装置、主节点及存储介质 | |
| CN115766715A (zh) | 一种高可用的超融合集群监控方法和系统 | |
| CN113391759B (zh) | 一种通信方法和设备 | |
| KR101758337B1 (ko) | 메시지의 중복알림을 방지하는 방법, 저장 매체 및 이를 운용하는 사용자 장치 | |
| JP2015114952A (ja) | ネットワークシステム、監視制御装置およびソフトウェア検証方法 | |
| CN109510867B (zh) | 数据请求处理的方法、装置、存储介质及电子设备 | |
| CN113326052A (zh) | 业务组件的升级方法、装置、计算机设备和存储介质 | |
| CN112559084A (zh) | 用于治理服务的方法、装置、设备、存储介质及程序产品 |
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 |