接口补偿机制需求分析&方案设计
需求分析
背景
- 业务系统逐渐开始与多个第三方系统进行对接，在对接时，需要调用外部系统接口进行数据的交换，如果在接口请求的过程中发生了网络抖动或其他问题，会导致接口调用失败；
- 对于此类问题，需要一个长效的接口重新调用机制，在发生网络抖动时可以进行自动地补偿调用，或者记录下来通知人工处理。
解决方案
- 建立 “补偿接口信息表” ，主要字段：
- 全类名(即包名+类名)：
class_name
- 方法名：
method_name
- 参数类型数组：
method_param_types 按照方法签名的顺序插入数组
- 参数值数组：
method_param_valuesTips:对象-->JsonString、null-->'null'，按照方法签名的顺序插入数组 ，组成字符串数组
- 错误信息：
error_msg
- 重试次数：
retry_count
- 最大次数：
max_retry_count
- 重试有效期：
retry_expiry_date
- 数据防重code：
unique_hash_code Unique_key Hash(class_name+method_name+method_param_values)
- 状态：
status 10：未解决；20：已解决
- 编写
InterfaceRetryInfo类用以记录类名、方法名、参数值数组、最大次数、重试有效期等信息，开发人员在需要重试的业务方法中调用第三方系统接口失败时，给这些信息赋值并调用InterfaceRetryInfoService.asyncRetry(retryInfo)方法异步存入数据库，之后抛出RetryFlagException异常，以方便补偿方法可以判断重试调用成功与否；
- 编写接口补偿方法
public boolean processRetryInfo(InterfaceRetryInfo retryInfo)，通过反射获取方法和参数并调用；
- 编写遍历方法
doRetry()，遍历数据库中的所有未解决的接口补偿数据，并提供Restful接口；
- 接入公司定时任务系统DING，定时调用
doRetry()进行接口补偿，如果补偿成功，则修改数据状态为**20：已解决**。
业务示例
注意事项
- 需要补偿的第三方接口需满足幂等性
- 调用第三方接口的逻辑需为单独的处理方法，和业务逻辑分离；
- 第三方接口调用失败或异常的情况下，需保证处理方法一定要抛出
RetryFlagException异常。
- 处理方法的参数，类型可以为
T、List<String>、List<T>、Map<String,String>，T代表Java基础类型或者POJO，且POJO的属性中如果有Map<K,V>，则K、V必须是String或其他Java基础类型；否则处理会出错。
- 如果处理方法使用了
@Async注解实现异步处理，则返回值必须为Future且异常处理最后一定要return false。
示例
业务Controller
@RestController
@Slf4j
@RequestMapping(value = "/retry/demo")
public class RetryDemoController {
@Autowired
private InterfaceRetryInfoService interfaceRetryInfoService;
@RequestMapping(meth
本文分析了在业务系统与第三方接口对接时，因网络问题导致调用失败的场景，提出了建立补偿机制的需求。该机制包括“补偿接口信息表”用于记录重试信息，通过反射调用接口，并通过定时任务进行补偿尝试。补偿接口需满足幂等性，且调用逻辑需独立于业务逻辑。文中还提供了业务示例及注意事项。
最低0.47元/天 解锁文章
扫一扫
521
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
