异步三方接口调用

优化异步三方接口调用

问题原因：

三方接口可能会出现网络波动，外部依赖的服务，直接影响到了页面的稳定性表现，出现检验之后一直加载，超时之后再点击就会很快就完成验证。

背景

人员手机号验证功能。当时我们发现，三方接口的稳定性不高（可能是由于网络波动或者其他原因），并且三方接口还会有每秒中的请求限制。导致人员检验时会有超时，甚至是检验失败等情况，但是重复点击就会成功。
排查下来发现，外部依赖的服务，直接影响到了平台的稳定性表现。
改造前

• 同步接口

• 耗时长

• 超时多，稳定性差

• 重试可解决

设计

异步化改造

​ 由于重试可解，所以抽取了一个检验中的中间状态。SubmitDetectionService 的 SubmitDetection方法中，设置状态为检验中，异步调用trySubmitDetection方法。执行实际送审

public interface SubmitMaterialUnitService {
    /**
     * 提交物料单元
     *
     * 先修改状态为审核中，返回
     * 异步处理提审过程，失败则在日志表中进行记录
     *
     * @param muId 物料单元
     * @param info 提交时所需的补充信息，如代理商、订单级别等
     */
    void SubmitDetection(Long muId, ExtraSubmitInfo info);

    /**
     * 提交物料单元，不会再进行免审校验
     * 用于异步提交，以及定时任务扫日志表重试提审
     */
    void trySubmitDetection(Long muId, ExtraSubmitInfo info);
}

异常处理

为了避免异步处理失败从而造成实际未送审，在 trySubmitDetection中，我们进行异常捕获，将处理失败的请求落入 event_log

重试任务

RetrySubmitTask 每隔10分钟定时扫 event_log 表，重试检验数据

报警时机管理

设置了两处报警点

• event_log 入库失败时（AbstractEventLogDealHandler）
• 重试任务失败时（MaterialUnitRetrySubmitTask）
  如果 event_log 入库成功，不会触发报警，因为我们已经有重试任务了，所以此刻的报警没有意义
• 同时日志表中有次数字段，如果调用三次以上依旧失败，则放弃掉这条消息，并且发送消息告知开发人员进行人工介入

成果

改造后

• 异步
• 耗时短
• 稳定性提升
• 系统自动重试，取代手动重试

思考

1. 异步化改造可提升系统性能与稳定性
2. 需要配合相应保障机制，重试、报警，或者一致性监控
3. 三方接口稳定性差，但无业务报错的情况下，可以不引入新状态