调用第三方接口需要关注的信息
一 鉴权方式
鉴权 一般采用ak sk
AK：Access Key Id,用于标示用户。
SK：Secret Access Key,是用户用于加密认证字符串和用来验证认证字符串的密钥，其中SK必须保密。
通过使用Access Key Id / Secret Access Key加密的方法来验证某个请求的发送者身份。
请求头信息
Nonce 随机数
Timestamp 时间戳
sign 签名
sign 根据双方约定的加密算法 根据 请求类型+请求url+请求参数 +Nonce+Timestamp+ak +sk签名
所有结合起来，可以有效地防止重放攻击和数据篡改
二 日志
第三方服务远程调用打印请求和响应的参数和接口耗时，方便在和各个终端定位问题，不会因为第三方服务日志的缺失变得手足无措。
三 校验
必要参数校验 第三方接口可能随时修改 调用方和使用方都要注意关键参数的校验，减少非必要的处理 不能完全依赖接口文档
四 对接方式
文件
FTP
定时将文件放入指定FTP的指定文件夹中
HTTP
传统调用方式 需要注意必须有超时时间
MQ
通过MQ接受 消费消息
MQ + HTTP
通过MQ接受事件 在调用相应接口查询数据
五 超时时间
超时时间意义 在极端情况下，采⽤主动的快速失败策略，使得资源消耗与释放资源之间达到平衡，避免调⽤双⽅因资源耗尽⽽宕机
如何设置 设置调用方的超时时间之前，先了解清楚依赖服务的TP99响应时间是多少（如果依赖服务性能波动大，也可以看TP95），调用方的超时时间可以在此基础上加50%
六 重试
调用失败根据规则 重新发起请求 尽可能提高成功率
重复请求 就算接口调用超时了或者出问题了，但是接口的逻辑还是会执行，若重试了就会重复请求接口，需要考虑接口是否幂等。
影响下游系统 重试意味着响应会变慢，若是高QPS接口可能会引发一系列问题。
爆炸式的重试风暴。假如一条调用链路经过了4个服务（A->B->C->D），最底层的服务D出现超时，这样上游服务都将发起重试，假设重试次数都设置的3次，那么B将面临正常情况下3倍的负载量，C是9倍，D是27倍，整个服务集群可能因此雪崩。
七 幂等
重复调用返回相同结果 查询天然幂等 别的需要找业务的唯一键 没有需要生成唯一键
八 黑白名单
可以手动 自动拉黑接口 防止因为外部接口导致的雪崩
手动熔断：
接入开源的动态配置中心apollo或naocos，配置熔断开关，当收到业务告警，动态秒级关闭，恢复后打开开关 快速止血
提供web页面支持运营拉黑 减少开发工作
自动熔断：
接入开源的Hystrx或sentne框架，配置合理值，实现超时或接口报错自动熔断，
同时跟业务商量给出一个默认兜底值。为了保护我们自己的系统，框架自动熔断同时返回的兜底值；
九 降级
提供相应的兜底策略
查询： 可以将下游结果暂时缓存到当前的系统中
数据修改：可以将修改信息暂时存储下来 等对方系统恢复再把数据发送过去
或直接返回友好提醒
十 限流
提前约定好接口调用频率 QPS等 配置对应限流规则
十一 数据一致性
调用外部接口涉及到数据变更需要注意数据一致性 对于要求强一致性的 需要考虑对账和补偿
自身服务:
调用下游接口失败，根据业务需要判断是否回滚其他的业务或者记录业务数据到本地事务消息表，然后启动一个job定时补偿数据；
管理后台提供一个事务消息表查询的功能。可以在界面上手工点击进行人工补偿；
数据下游服务:
提供的接口定义一个唯一值的字段，接口做好幂等处理；
提供一个根据唯一值的字段查询业务数据的接口，便于上游对账；
十二 监控告警
配置 响应时间 QPS 错误率 吞吐量 的监控告警。
十三 三方性能 可用性不满足要求怎么办
上策-压测
如果接口对于稳定性和性能有要求， 需要提前将相应指标告知第三方。 开发完成进行对应的测试并且出具对应的测试报告， 因为代码是一直迭代的所以定期进行压测确保没有问题。
下策-将处理统一做到本系统再异步通知第三方
如果第三方系统性能较差 数据一致性要求没有特别高的业务
查询：可以定时将第三方的数据同步到我们的系统中 按照相应规则去更新缓存数据
修改数据: 需要注意如果查询是用的本系统的数据， 由于缓存可能出现数据不一致的情况， 所以我们要注意修改数据要做一次数据校验，如果数据不一致需要提醒用户数据有变化（由于此方法用户体感较差），一般采用多级页面的方式 由于大部分是查询，修改QPS并没有很高，可以采用进入修改也强制刷新数据的逻辑。
批量
数据拉取可以采用批量的方式减少io消耗，修改可根据业务选择 因为修改要保证一致性 批量可能存在部分成功 部分失败
异步
如果我们只关注将数据给下游即可 可以采用消息队列 异步处理
