接下来呢,我会带领大家整体的过一遍,大家刷到了就留个印象,后边的笔记呢,我也准备好了,评论区扣1然后私信我领取哈。大家也可以来吐槽吐槽自己遇到的一些坑,让更多的小伙伴看到,一起交流。
闲话少说,接下来我们就进入正题。
域名访问不到
首先第一个问题,域名访问不通,一般我们在第一次对接第三方平台的API接口时,可能会先通过浏览器或者postman调用一下。
对于这个点分两个方面看,要么是我有问题,要么是对方有问题。
- 自己的网络问题
- 对方域名访问不通
- 对方DNS解析有问题
- 对方服务未部署等等
- 对方设置了访问白名单
有可能你调用第三方平台的API接口时,他们的接口真的挂了,他们还不知道。还有一种最重要的情况,就是你的工作网络,是否可以访问这个外网的接口。
有些公司为了安全考虑,对内网的开发环境,是设置了防火墙的,或者有一些其他的限制,有些ip白名单,只能访问一些指定的外网接口。
如果你发现你访问的域名,在开发环境访问不通,就要到运维同学给你添加ip白名单了。
接口突然没返回数据
如果你调用第三方平台的某个API接口查询数据,刚开始一直都有数据返回。但突然某一天没返回数据了。但是该API接口能够正常响应。不要感到意外,有可能是第三方平台将数据删除了。
我对接完第三方平台的API接口后,部署到了测试环境,发现他们接口竟然没有返回数据,原因是他们有一天将测试环境的数据删完了。因此,在部署测试环境之前,要先跟对方沟通,要用哪些数据测试,不能删除。
还有一点,在我们自己程序中,我们永远不要相信三方平台的数据,如果出错了,我们要写容错策略。不能因为三方的错误,把自己系统给拖死。
token失效
有些平台的API接口在请求之前,先要调用另外一个API接口获取token,然后再header中携带该token信息才能访问其他的业务API接口。其实大多数我们自己的系统也是这么设计的。
在获取token的API接口中,我们需要传入账号、密码和密钥等信息。每个接口对接方,这些信息都不一样。
我们在请求其他的API接口之前,每次都实时调用一次获取token的接口获取token?还是请求一次token,将其缓存到redis中,后面直接从redis获取数据呢?
很显然我们更倾向于后者,因为如果每次请求其他的API接口之前,都实时调用一次获取token的接口获取token,这样每次都会请求两次接口,性能上会有一些影响。
如果将请求的token,保存到redis,又会出现另外一个问题:token失效的问题。
我们调用第三方平台获取token的接口获取到的token,一般都有个有效期,比如:1天,1个月等。
在有效期内,该API接口能够正常访问。如果超过了token的有效期,则该API接口不允许访问。
好办,我们把redis的失效时间设置成跟token的有效期一样不就OK了?
想法是不错,但是有问题。
你咋保证,你们系统的服务器时间,跟第三方平台的服务器时间一模一样?
我之前遇到过某大厂,提供了获取token接口,在30天内发起请求,每次都返回相同的token值。如果超过了30天,则返回一个新的。
有可能出现这种情况,你们系统的服务器时间要快一些,第三方平台的时间要慢一些。结果到了30天,你们系统调用第三方平台的获取token接口获取到了token还是老的token,更新到redis中了。
过一段时间,token失效了,你们系统还是用老的token访问第三方平台的其他API接口,一直都返回失败。但获取新的token却要等30天,这个时间太漫长了。
对于具体的错误码要设计重试机制:
为了解决这个问题,需要捕获token失效的异常。如果在调用其他的API接口是发现token失效了,马上请求一次获取token接口,将新的token立刻更新到redis中。
这样基本可以解决token失效问题,也能尽可能保证访问其他接口的稳定性和性能。
接口超时
系统上线之后,调用第三方API接口,最容易出现的问题,应该是接口超时问题了。系统到外部系统之间,有一条很复杂的链路,中间有很多环节出现问题,都可能影响API接口的相应时间。
这点很尴尬,别人的系统,咱们控制不了,你说让别人优化系统,人家立项调整上线估计就半个月,这还是情况好的,拖个半年的都有。别人体验的是你的系统,速度慢一点还能说得过去,要是老是超时失败反馈到用户层面。用户第一个找的就是你。。。。
作为API接口的调用方,面对第三方API接口超时问题,除了给他们反馈问题,优化接口性能之外。
我们更有效的方式,可能是增加接口调用的失败重试机制。
例如:
- 如果接口调用失败,则程序会立刻自动重试3次。
- 如果重试之后成功了,则该API接口调用成功。
- 如果重试3次之后还是失败,则该API接口调用失败。
偷偷改参数了
我之前调用过某平台的API接口获取指标的状态,之前根据双方约定的状态有:正常和禁用 两种。
然后将状态更新到我们的指标表中。后来,双方系统上线运行了好几个月。突然有一天,用户反馈说某一条数据明明删除了,为什么在页面上还是可以查到。此时,我查我们这边的指标表,发现状态是正常的。
然后查看调用该平台的API接口日志,发现返回的该指标的状态是:下架。
什么鬼,心里已经问候了八百遍了。。。
跟该平台的开发人员沟通后,发现他们改了状态的枚举,增加了:上架、下架等多个值,而且没有通知我们。这就坑了。我们这边的代码中判断,如果状态非禁用状态,都认为是正常状态。
而下架状态,自动被判断为正常状态。经过跟对方沟通后,他们确认下架状态,是非正常状态,不应该显示指标。他们改了数据,临时解决了该指标的问题。后来,他们按接口文档又改回了之前的状态枚举值。
这里还有一种其他的方案,把枚举信息也通过一个接口返回,然后做展示,这样就能避免前面提到的问题了。
接口时好时坏
不知道你在调用第三方接口时,有没有遇到过接口时好时坏的情况。5分钟前,该接口还能正常返回数据。
5分钟后,该接口返回503不可用。又过了几分钟,该接口又能正常返回数据了。
可能情况:
- 这种情况大概率是第三方平台在重启服务,在重启的过程中,可能会出现服务暂时不可用的情况。
- 第三方接口部署了多个服务节点,有一部分服务节点挂了。也会导致请求第三方接口时,返回值时好时坏的情况。
- 网关的配置没有及时更新,没有把已经下线的服务剔除掉。这样用户请求经过网关时,网关转发到了已经下线的服务,导致服务不可用。网关转发请求到正常的服务,该服务能够正常返回。
如果遇到该问题,要尽快将问题反馈给第三方平台,然后增加接口失败重试机制。