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

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

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

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、期待中的第三方接口是啥模样？

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

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

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

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

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

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

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