无法逃避的第三方接口对接

现在的系统几乎很少是自成一个封闭的体系的,要么会开放给其他系统接入,要么会调用第三方提供的接口。开放给其他系统接入暂且不谈,调用第三方提供的接口肯定是逃避不了的。比如支付、短信等通用服务的对接,又比如行业内监管、监察、绩效考核要求,必须把相关数据按照规定的要求(时间、频次、格式、数据等)提供给第三方平台,总之,无法逃避。

在项目的实施过程中,也遇到过各种各样的坑:

1、接入说明缺失、错误

期望大家永远不要遇到这样情况,会折磨的你毫无脾气。根据上级要求,需要将系统中的部分数据按照要求提交给第三方平台,在上级组织召开的会议上,默默记录了第三方平台的对接联系人。一段时间过后,等到具体对接联系对接人时,他通过QQ发来了几十个url连接,一脸懵逼的样子(自行想象)。。。。

经过2天的追问和解说,终于大致明白需要如何对接,以及发过来的几十个url到底是干什么用了。

接下来,很自然就开始打开Eclipse,亲自操刀,自行编写测试代码进行测试了,Ctrl + F11运行,嗯调用正确,有返回值。返回值是-1,啥意思?

前前后后半个月,就贡献给第三方平台了。o(︶︿︶)o 唉

接入说明缺失,就像是摸着石头过河,谁也不知道什么时候才能真正对接上。差评!

还有一次做单点登录的接入,对方提供了接口文档、示例工程以及对应的jar包。我兴高采烈的,按照说明完成了对接的功能,提交代码,本以为可以按时下班了,可惜测试用例一跑,错误近10处!看来烛光晚餐是没有了,调试了近1个小时,发现提供的40多个接口中有3个是错误的!!我想静静~

我如此的信任你,却一次次的伤害我。

提供的说明,竟然有错误,有错误还赶发出来吗?!

2、无测试环境,直接上生产

接着上面的讲吧,终于明白了接口的作用后,我就开始跑测试了,一遍又一遍,一次有一次,突然,电话铃声想起,把我大脑从高速运转中一下子拉回了现实中,什么情况?接起电话,对方一阵咆哮,大致意思就是,不要在生产环境提交无用数据。生产环境?我急忙解释说在对接口做测试,问是否有测试环境可供测试?没有!

没有测试环境你让我如何验证我对接的是否正确啊!

是的,你没看错,就是没有测试环境,有本事,拿生产数据测试啊。

3、接口更新无通知

好不容易,终于对接完成,为此我还专门整理了详细的开发文档,包括通过语言交流得到的接口说明。经过这么长时间的折磨,我终于可以小憩一段时间了,悠然自得的开发工作,还是比较开心的。可惜好景不长,突然有一天晚七时许,后台监控突然批量出现同一个错误,那就是推送给第三方平台数据出错了。一个鲤鱼打挺,急忙排查:网络?畅通,服务?畅通,系统?运行稳定,这是什么情况?打开之前写的单元测试,一跑,发现和生产环境一样的错误,而且集中在一个接口上。打开之前写的文档进行查看,没有问题,这又是什么情况?数据如果没有推送成功会扣绩效的!不管三七二十一,一个电话就打过去了,纳尼?接口升级呢?升级了为什么没有通知我们?(内心独白,没有质问对方)。

你还让不让人省心,当初就不应该这么早接入进去!

4、服务不稳定影响自有系统

还记得对接的单点登录系统吧,对接还算顺利,既有文档和示例,又服务周到,用起来得心应手,好不快活。但是,突然的某一天,客服艾特我,系统访问不了了,工单就是绩效,绩效就是生产力。

我连忙远程登录主机,内网访问,嗯?正常啊。切回外网,一直在等待。嗯,我怀疑负载均衡宕机了(之前出现过问题)。联系了系统运行部,答复,没问题,能够正常将请求转发,一切正常。挂完电话,正准备去后台查看监控日志,咦?外网可以访问了,F5刷新,又开始等待了。初步怀疑,后台负载太重,服务能力不够。查看监控日志,查看错误信息,Exception,这是什么错误?查看包名,这不是单点登录提供的jar包吗?超时?往上查看,好多同类错误!电话给对接人,对方服务过载,已经安排开发人员去解决了。查看了配置文件,竟然设置的超时时间为12秒!

对方提供的服务不稳定,如果设计不得当,极有可能影响到自有系统的对方服务!

5、接口调用有要求

推送数据的接口已经基本稳定,推送了好几个月了,都没有任何问题。马上自有系统的业务要进入计划中的高峰期,项目组都在按部就班的做准备:运维人员在扩充硬件,最大化服务能力;测试人员正在忙着对核心的功能进行全方位的测试,避免线上出现低级错误,导致工单爆满;开发人员正在忙着需求的变更,对,你没看错,需求的变更!一个运维的项目,时时刻刻都在变更。

终于迎来了业务高峰,经过前期的准备,系统总体上运行平稳,工单数量也没有突然暴增,但是,又接到了第三方平台对接人的电话,不要频繁调用接口,平台服务快宕了!扩容呗,扩容最简单了,哈哈哈哈~

哎,谁让别人是上级,我又陷入了优化接口调用的工作中了,不要吵过,我想静静~

随着自有业务的增长,对第三方接口的调用也水涨船高,如果没有相互沟通和测试,极有可能导致第三方接口宕机或者被怀疑为恶意攻击,进入第三方的黑名单。所以,最好首先对自有业务量进行预估,并拍脑袋拍出第三方接口的调用量,和对方深入沟通,确保服务的正常运行。对于第三方接口的调用,也不要直接做转发,根据具体的业务,做削峰处理(又叫平滑处理)。

6、提供的接口无幂等性,调用方对结果自负

接口调用的平滑处理后,请求量曲线就没有那么激进了,血压也稳定了。但是,偶尔还是会出现一些错误,虽然不严重,但是一直都是临时处理了,没有深入分析和解决。今天同事们都去秋游了,留下我在办公室坐班(别的事耽搁了),想来还是解决了,不然每隔一段时间都要手动处理几单业务,烦躁得很。

说干就干,打开监控日志,嗯?为什么会有两条记录,前面还网络超时?为什么网络超时就会有两条记录?嗯,数据一致性问题,看来没有想象的那么简单!

经过度娘的服务,初步断定接口有问题,打开Eclipse,编写测试代码,运行,再运行,再运行,3条记录!话说,我想去秋游了~

同一份数据,请求多次,会产生不一样的结果,幂等性啊,就不能设计满足幂等性的接口来吗?算了,上级肯定不会的,还是我自己来实现吧。

7、期待中的第三方接口是啥模样?

一个一个的坑啊,总算是走过来了,现在沟通机制已建立,代码也经过优化,逐步稳定了。我想静静的时候,也期待了下一个第三方接口对接时的模样:

提供详尽的文档、说明和丰富的示例代码;

能够提供可以给调用方折腾的环境,而不是直接对接生产系统;

接口更新要多听听使用者的意见,更新前能够给与使用方足够的更新时间,最好是双版本同步运行一段时间,新版接口稳定后再平滑过度;

尽最大努力,保证服务的稳定,不然不要出来服务别人;

接口调用的要求要明确出来,调用超出要求,通过返回值来告知,而不是电话;

尽量保证接口的幂等性,内部去解决问题,不要往外推给使用者来处理。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180511G251YP00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券