调用三方接口需要注意的那些事 _生活知道

调用第三方接口在很多系统中都很常见，不管是调用本公司其他业务平台的接口，还是调用三方公司的接口，都需要一定的规范，否则系统容错性会较差，而且出问题的时候不利于问题排查，也可能会造成双方互相推卸责任的情况，大公司很容易出现这种扯皮的问题。为避免相应的麻烦，需要制定相应的规范，以下规范可做参考。
注意事项通讯标准确定协议 Http/Https确定参数传输格式 json/x-www-form-urlencoded/…具体接口参数的数据类型；这样既不会造成系统资源的浪费，也保证业务正常运行。
幂等重试
针对幂等问题，首先要和接口提供方确认接口是否能够保证幂等性，在保证幂等的情况下，根据错误码进行重试。
通常以下三种情况下，可以进行重试：
1.报文丢失，真的丢了，server没收到，所以业务实际没执行
2.报文响应丢失，报文到达server，server也处理了。但是response后，client未收到
3.报文响应，返回可重试错误码
以上1,2情况通常是网络闪断导致，这3种情况应该处理的方式是不一样的，client进行重试请求。
也就是说client无法区分到底发生了第一种错误还是第二种错误。自然也就无法判断目前是那种情况，自己应该采用何中应对之策。而且第二种处理，对不同类型消息，查询到的响应信息是不同的，也就是说各接口需要独立实现额外的查询功能，有较大开发量。
解决方案：对所有请求的唯一标志，requestId建立独立日志表，记录request、requestId和response 。
如果新报文的requestId存在如下情况：
01.不在表中，说明全新请求，正常执行业务逻辑即可。
02.在表中，但是response为空，说明这个请求正在处理中，返回约定错误码，让其稍后再试。
03.在表中，且response不为空，说明这个请求已经处理过，且响应过报文，直接将上次的response再返回一次即可。
在这种方案下，如果对方未收到response，重试即可。
幂等核心防止业务数据重复保存，要有唯一识别的编号用于标识相同的业务数据，相同业务数据可以重复调用，返回相同处理结果。
【调用三方接口需要注意的那些事】日志
针对请求参数和响应结果，需要记录日志，并进行持久化保存，日志记录里需要有明确的唯一requestId ，接口要方便调式追踪，记录好输入和输出信息，方便查找问题。
接口环境
要和接口提供方，明确有哪些环境，是否提供灰度环境，通常会有开发、测试、预发布、生产环境，要和接口提供方明确有哪些环境，进行相关的配置。
线上业务如果依赖于第三方服务，而且线上线下使用的不是同一个账号/环境，一定要在模拟环境测试通过后，再在模拟环境用依赖的正式账号走一遍，确认依赖的正式账号/资源可用，以及配置正确。不要等到第一次上线的时候，再配置依赖的正式账号/环境。有可能外部资源时间配置会比较长，最终导致当天上线不成功/延期。
监控与告警
遵循的原则其实是『对任何第三方应当保持不可信原则』，在很多经典书都能看到这番话的，最简单的第三方超时进而导致业务执行失败，通过异常捕获和转换，让业务更清晰。
接口异常要记录，尽可能地保存业务信息，方便还原信息，错误达到阈值要报警，还有另外一种情况，对方接口升级存在不兼容的情况，也需要进行异常告警。
同时需要将接口的响应时间进行监控，针对响应时间慢的接口需要和接口提供方沟通是否有优化空间。
最佳实践
1. 需要通过第三方接口获取数据的服务，禁止直接调用第三方接口，必须通过旁路系统进行调用。旁路系统可以是一个后端程序，如java程序。
2. 需要通过第三方接口获取数据的服务，必须做容错性处理。在第三方数据出错的情况下程序必须保证稳定性。当数据出错时可以进行友好的提示。
3. 把控第三方接口数据的旁路系统，在第三方接口异常、数据出错时必须记录相应日志。方便紧急相应人员根据日志排查定位问题。
以上就是朝夕生活（www.30zx.com）关于“调用三方接口需要注意的那些事”的详细内容，希望对大家有所帮助！

调用三方接口需要注意的那些事

猜你喜欢