CN111814178A - 一种针对第三方应用的数据回调熔断保护方法 - Google Patents

Abstract

本发明公开了一种针对第三方应用的数据回调熔断保护方法，无需使用统一的注册中心，就可以针对第三方应用颗粒度实现熔断保护功能，即当回调平台探知第三方应用A不可用后，在一段时间内不会对第三方应用A做数据回调，但不会影其它健康的第三方应用的数据回调，从而避免了回调资源的浪费。防止了由于应用A的不可用，而拖垮整个回调***情况的发生。

Description

一种针对第三方应用的数据回调熔断保护方法

技术领域

本发明涉及互联网、物联网技术领域，尤其涉及一种针对第三方应用的数据回调熔断保护方法。

背景技术

在物联网应用中，有大量对第三方应用进行数据回调的场景，由于第三方应用的状态不可知，一般需要使用熔断器对回调平台的资源进行保护，以防止某个第三方应用不可用时，消耗过多的回调资源，拖垮整个回调服务平台。目前行业主流的熔断器是以Hystrix为代表，基于微服务治理框架，实现服务颗粒度的熔断保护；即哪个服务不可用就针对这个服务进行熔断保护，但缺点是必须要求被调用的服务在注册中心(如Eureka、Zookeeper等)进行统一注册。对于第三方应用的数据回调场景，不能要求第三方应用注册到统一的注册中心，所以传统的熔断保护方法不能满足此业务场景的需求。

发明内容

本发明的目的就在于为了解决上述问题而提供一种针对第三方应用的数据回调熔断保护方法，本发明将原本由微服务治理框架维护的服务信息，交由平台方自身独立维护，从而支持了第三方应用不需要注册到统一的注册中心，就可以实现对第三方应用颗粒度的熔断保护。

本方法通过回调平台和第三方应用业务方之间沟通协调后，由回调平台方独立地将第三方应用的基本信息，统一维护到自身的第三方应用回调信息状态表。具体来说，是将被回调的第三方应用的appId、回调地址url、熔断器状态、失败次数、breaker_time等要素按照第三方应用的颗粒度，分别保存到数据库、缓存或者可读写的文件***中，以保证回调平台能够方便的读取和修改这些要素。当有数据需要回调第三方应用时，首先根据回调数据找到此回调数据归属的第三方应用以及第三方应用appId，根据appId从回调信息状态表中找到此应用对应的那条回调状态信息记录，根据此记录的熔断器状态、失败次数、breaktime综合决定是否回调第三方应用。如果回调第三方应用，再根据回调结果的成功与否，更新熔断器的熔断状态、失败次数、break time，从而决定下一次发生数据回调时，是否回调第三方应用。最终达到在第三方应用没有统一注册到注册中心的前提下，实现第三方应用颗粒度熔断保护的目的。

本发明通过以下技术方案来实现上述目的：

一种针对第三方应用的数据回调熔断保护方法，包括以下步骤：

s1在回调平台方和第三方应用业务方之间确定回调平台需要对第三方应用进行数据回调的接口，记录接口对应的第三方应用以及回调地址url；

s2初始化回调信息状态表的静态应用信息；

s3初始化回调信息状态表的熔断动态要素；为了表示初始没有发生熔断的概念，设定初始化操作如下：初始化熔断状态为熔断器关闭，初始化回调失败次数值为0，初始化breaker_time为空或者null；其中breaker_time表示发生熔断的时刻；

s4将需要被回调的第三方应用的appId、回调地址url、熔断器状态、失败次数、breaker_time保存到数据库、缓存或者可读写的文件***中，以保证回调平台能够方便的读取和修改这些要素；

s5当有数据需要回调第三方应用时，根据回调数据找到此回调数据归属的第三方应用；例如根据回调数据A找到归属的应用A；在软件***中，会根据回调数据A映射到appId_A，再通过appId_A从回调信息状态表中找到A应用对应的回调状态信息记录A；

s6回调平台根据记录A中的熔断器状态、失败次数等要素，决定是否对第三方应用进行数据回调；根据回调结果是否成功，修改记录A的失败次数，以及对熔断器的熔断状态进行转换；

s7当有新的数据回调时，则重复执行s1-s6的步骤。

进一步方案为，所述步骤s2具体为：

s2.1汇总需要被回调的第三方应用，并为每个第三方应用分配一个唯一标识，可以是appId；如第三方应用A对应appId_A，第三方应用B对应appId_B，以此类推；

s2.2为每个第三方应用的appId关联应用回调地址url。

进一步方案为，所述步骤s6中，具体如下：

s6.1当有数据A回调且记录A对应的熔断器是熔断关闭状态时，则直接将数据回调给第三方应用A；根据回调结果的成功与否，分为以下两个子步骤：

s6.1.1如果回调第三方应用A成功，则不修改记录A的熔断器状态和失败次数；

s6.1.2如果回调第三方应用A失败，则对记录A的失败次数加1；回调平台需要提前设置一个回调允许的最大失败次数阈值max_error，如果错误的次数大于这一阈值max_error，则将熔断器修改为熔断打开状态，并保存熔断发生的时刻breaker_time_A_1；

s6.2当有数据A回调且对应记录A的熔断器状态是熔断打开时，则回调平台需要事先设置一个熔断时间范围；根据当前时刻、breaker_time、熔断时间，三者之间的关系分为以下两种情况：

s6.2.1若满足条件：当前时刻-breaker_time_A_1＜＝熔断时间，则不对第三方应用进行回调，从而减少回调资源的浪费；

s6.2.2若满足条件：当前时刻-breaker_time_A_1＞熔断时间，则尝试对第三方应用进行回调，如果此次回调成功，则将记录A的失败次数清零，熔断器修改为熔断关闭状态；如果此时回调失败，则只更新记录A的breaker_time为当前最新时刻breaker_time_A_2，其余参数不做处理。

本发明的有益效果在于：

本发明的一种针对第三方应用的数据回调熔断保护方法，无需使用统一的注册中心，就可以针对第三方应用颗粒度实现熔断保护功能，即当回调平台探知第三方应用A不可用后，在一段时间内不会对第三方应用A做数据回调，但不会影其它健康的第三方应用的数据回调，从而避免了回调资源的浪费。防止了由于应用A的不可用，而拖垮整个回调***情况的发生。

附图说明

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

图1为本发明熔断器和回调信息状态示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将对本发明的技术方案进行详细的描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本发明所保护的范围。

本发明的核心为熔断器和回调信息状态表：熔断器决定是否对第三方应用进行回调；回调信息状态表维护第三方应用的静态应用信息和动态熔断要素。

静态应用信息包含第三方应用唯一标识符、第三方应用回调地址url。一般应该在发生实际数据回调前，由回调平台方和第三方应用业务方协商确定。如果第三方应用不发生变化，这两个信息一般不会修改。动态要素包含第三方应用对应的熔断器状态和回调平台请求第三方数据失败的失败次数。

在任一实施例中，如图1所示，本发明的一种针对第三方应用的数据回调熔断保护方法，包括：

s1在回调平台方和第三方应用业务方之间确定回调平台需要对第三方应用进行数据回调的接口，记录接口对应的第三方应用以及回调地址url；

s2初始化回调信息状态表的静态应用信息；

s2.1汇总需要被回调的第三方应用，为每个第三方应用分配一个唯一标识，可以是但不仅限于appId；比如第三方应用A对应appId_A，第三方应用B对应appId_B，以此类推；

s2.2为每个第三方应用的appId关联应用回调地址url；

s3初始化回调信息状态表的熔断动态要素；为了表示初始没有发生熔断的概念，规定以下初始化操作：初始化熔断状态为熔断器关闭，初始化回调失败次数值为0，初始化breaker_time为空或者null；其中breaker_time表示发生熔断的时刻；

s4将需要被回调的第三方应用的appId、回调地址url、熔断器状态、失败次数、breaker_time等要素统一保存到数据库、缓存或者可读写的文件***中，以保证回调平台能够方便的读取和修改这些要素；这里统称保存的这些信息要素集合为回调信息状态表；

s5当有数据需要回调第三方应用时，首先根据回调数据找到此回调数据归属的第三方应用，例如根据回调数据A找到归属的应用A；一般在软件***中，会根据回调数据A映射到appId_A，再通过appId_A从回调信息状态表中找到A应用对应的回调状态信息记录A；

s6回调平台根据记录A中的熔断器状态、失败次数等要素，决定是否对第三方应用进行数据回调；根据回调结果是否成功，修改记录A的失败次数，以及对熔断器的熔断状态进行转换，具体如下：

s6.1当有数据A回调且记录A对应的熔断器是熔断关闭状态时，则直接将数据回调给第三方应用A；根据回调结果的成功与否，分为以下两个子步骤：

s6.1.1如果回调第三方应用A成功，则不修改记录A的熔断器状态和失败次数；

s6.1.2如果回调第三方应用A失败，则对记录A的失败次数加1；回调平台需要提前设置一个回调允许的最大失败次数阈值max_error，如果错误的次数大于这一阈值max_error，则将熔断器修改为熔断打开状态，并保存熔断发生的时刻breaker_time_A_1；

s6.2当有数据A回调且对应记录A的熔断器状态是熔断打开时，则回调平台需要事先设置一个熔断时间范围；根据当前时刻、breaker_time(熔断发生时间)、熔断时间(熔断器熔断的时间长度)，三者之间的关系分为以下两种情况：

s6.2.1若满足条件：当前时刻-breaker_time_A_1＜＝熔断时间，则不对第三方应用进行回调，从而减少回调资源的浪费；

s6.2.2若满足条件：当前时刻-breaker_time_A_1＞熔断时间，则尝试对第三方应用进行回调，如果此次回调成功，则将记录A的失败次数清零，熔断器修改为熔断关闭状态；如果此时回调失败，则只更新记录A的breaker_time为当前最新时刻breaker_time_A_2，其余参数不做处理；

s7当有新的数据回调时，则重复执行s1-s6的步骤。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本发明对各种可能的组合方式不再另行说明。此外，本发明的各种不同的实施方式之间也可以进行任意组合，只要其不违背本发明的思想，其同样应当视为本发明所公开的内容。

Claims (3)

1.一种针对第三方应用的数据回调熔断保护方法，其特征在于，包括以下步骤：

s1在回调平台方和第三方应用业务方之间确定回调平台需要对第三方应用进行数据回调的接口，记录接口对应的第三方应用以及回调地址url；

s2初始化回调信息状态表的静态应用信息；

s3初始化回调信息状态表的熔断动态要素；为了表示初始没有发生熔断的概念，设定初始化操作如下：初始化熔断状态为熔断器关闭，初始化回调失败次数值为0，初始化breaker_time为空或者null；其中breaker_time表示发生熔断的时刻；

s4将需要被回调的第三方应用的appId、回调地址url、熔断器状态、失败次数、breaker_time保存到数据库、缓存或者可读写的文件***中，以保证回调平台能够方便的读取和修改这些要素；

s5当有数据需要回调第三方应用时，根据回调数据找到此回调数据归属的第三方应用；例如根据回调数据A找到归属的应用A；在软件***中，会根据回调数据A映射到appId_A，再通过appId_A从回调信息状态表中找到A应用对应的回调状态信息记录A；

s6回调平台根据记录A中的熔断器状态、失败次数等要素，决定是否对第三方应用进行数据回调；根据回调结果是否成功，修改记录A的失败次数，以及对熔断器的熔断状态进行转换；

s7当有新的数据回调时，则重复执行s1-s6的步骤。

2.如权利要求1所述的一种针对第三方应用的数据回调熔断保护方法，其特征在于，所述步骤s2具体为：

s2.1汇总需要被回调的第三方应用，并为每个第三方应用分配一个唯一标识，可以是appId；如第三方应用A对应appId_A，第三方应用B对应appId_B，以此类推；

s2.2为每个第三方应用的appId关联应用回调地址url。

3.如权利要求1所述的一种针对第三方应用的数据回调熔断保护方法，其特征在于，所述步骤s6中，具体如下：

s6.1当有数据A回调且记录A对应的熔断器是熔断关闭状态时，则直接将数据回调给第三方应用A；根据回调结果的成功与否，分为以下两个子步骤：

s6.1.1如果回调第三方应用A成功，则不修改记录A的熔断器状态和失败次数；

s6.1.2如果回调第三方应用A失败，则对记录A的失败次数加1；回调平台需要提前设置一个回调允许的最大失败次数阈值max_error，如果错误的次数大于这一阈值max_error，则将熔断器修改为熔断打开状态，并保存熔断发生的时刻breaker_time_A_1；

s6.2当有数据A回调且对应记录A的熔断器状态是熔断打开时，则回调平台需要事先设置一个熔断时间范围；根据当前时刻、breaker_time、熔断时间，三者之间的关系分为以下两种情况：

s6.2.1若满足条件：当前时刻-breaker_time_A_1＜＝熔断时间，则不对第三方应用进行回调，从而减少回调资源的浪费；

s6.2.2若满足条件：当前时刻-breaker_time_A_1＞熔断时间，则尝试对第三方应用进行回调，如果此次回调成功，则将记录A的失败次数清零，熔断器修改为熔断关闭状态；如果此时回调失败，则只更新记录A的breaker_time为当前最新时刻breaker_time_A_2，其余参数不做处理。

Images