第三方接口设计方案注意事项

1、封装统一的http请求工具类

集成apache httpclient开源框架；
集成okhttp开源框架；

2、打印请求接口入参、出参、耗时日志(可以在请求工具类统一打印)

在请求工具类统一打印，例如:
long start = System.currentTimeMillis(）;
// todo 请求接口返回result结果
looinfo("耗时:{}ms,url:{},param:{},result:{}",System.currentTimeMillis()-start,result,reqUrl,param,result);

3、参数合法性校验(减少对下游无效的调用)

• 数据格式的校验(例如非空、合法性判断)
• 业务合法性的校验

4、接口设置超时时间

http工具类提供配置的超时时间参数，供其他业务场景传递；

• 不同的业务场景设置不同的超时时间；
• 禁止不设置超时间，设置默认的超时时间；
• 评估超时时间，要结合业务，不能拍脑袋，比如可以根据接口监控，看一下P95、P99的响应时间，然后在这个基础上放大一点；

5、接口是否需要重试以及重试次数

• 事务类接口不要随便重试，如果下游没做好接口幂等容易超发，像活动的奖品发放。但是一定要有业务告警，通过人工接入的方式，进行补发处理查询类接口的重试；
• 查询类接口的重试，也要慎重考虑，如果下游接口支持的QPS有限，重试放量，容易把下游的接口打垮，所以如果决定重试，要调研下游接口的并发能力，酌情处理；

6、事务一致性保障

自身服务:

• 调用下游接口失败，根据业务需要判断是否回滚其他的业务或者记录业务数据到本地事务消息表，然后启动一个job定时补偿数据；
• 管理后台提供一个事务消息表查询的功能。可以在界面上手工点击进行人工补偿；

数据下游服务:

• 提供的接口定义一个唯一值的字段，接口做好幂等处理；
• 提供一个根据唯一值的字段查询业务数据的接口，便于上游对账；

7、接口实现熔断返回兜底值及降级

自动熔断实现方案：

接入开源的Hystrx或sentne框架，配置合理断的值(例如1分钟接口100个报错，断30s)，实现超时或接口报错自动熔断，同时跟业务商量给出一个默认兜底值。例如调用大数据客群接口，如果第三方提供的客群接口大量报错或服务超时，为了保护我们自己的系统，框架自动熔断同时返回默认不命中的兜底值；

手动熔断实现方案：

接入开源的动态配置中心apollo或disconf，配置熔断开关，当收到大量业务告警，动态秒级关闭，恢复后打开开关；

无论是自动或手动，都需要配置业务告警。

8、多次调用改为单次批量调用

• for循环根据id调用外部接口改为单次批量根据id调用，减少多次网络io带来的时间消耗；

• 要考虑单次批量调用参数的大小，比如单次传1000个id参数，这个也不行，可能导致接口直接超时，所以要对参数进行分组切割批量调用，比如1000个参，1次100个，分10次调用；

9、接口返回的数据考虑是否缓存(防止对下游接口造成流量冲击)

查询客户命中的客群标签，同一人一天内理论上都是不变的，可以使用redis缓存，但是过期时间不适合太长，因为同一个人使用系统的时间也不长；