更新记录：

  • 2016年02月26日 加入对于 接口错误返回的处理。
    今天遇到一个错误。这个接口在正确时，返回的结果节点里有子xml，通过CDATA的。错误的时候不会返回，程序就出错了。其实我在接入好几个接口时完全没考虑到错误情况，大大的不应该啊。

  • 2016年02月26日 接口的测试账号一般有使用次数限制，不要当成正式的用。
    产品需要跑一个数据。我就直接在开发环境跑了，结果跑了一点接口就报错：查询数量已达到上限。这导致开发环境以后无法测试了。。。

    如果没有什么问题的话，最好把开发机的IP也加入第三方接口的生产环境。这样跑数据什么的就不用上线执行了。

  • 2016年02月26日 如果接口提供方有IP白名单的限制，一般还会同时限制白名单IP个数，一般是10个这样。
    这种情况，就需要特殊的机子专门复杂与接口交互，其他的机子调用这个机子。

最近接入了几个第三方接口。现在总结一下。

概述

接入接口，最重要的是稳定性。而接入接口的这个系统，和其他的普通系统不一样，是由两个部分决定的。一个是接口的稳定性，一个是接入系统的稳定性。

接入系统是我们自己写的，是可控的，所以稳定性是可以不断优化的。而第三方接口的稳定性，我们很难干预，如果在投入使用后发现第三方接口的稳定性不达标，是很难补救的。原因有几点，第一，我们使用第三方提供的接口，接口对我们来说是个黑盒，所以如果出了问题，我们是不明白其中的原理的，如果是偶发的问题，在与第三方交涉上，会更加麻烦。第二，如果第三方的技术实力有限导致了接口不稳定，这就不是几句话能解决的问题了。一旦你陷入了不稳定接口的坑里，代价是非常大的，因为在不稳定系统上建立稳定系统是非常非常困难的。如果最后选择了换一个接口，那么付出的时间成本和人力成本也是非常浪费的。

所以在接口接入的调试期，必须调研清楚，多和接口提供方的对接人员沟通。以下几点你需要搞明白：

1.接口是异步的还是同步的？
这一点对于系统的设计影响非常大，同步的接口在一个请求内就会返回结果，简单直接。而异步接口，第一次请求发送参数，第三方一般会返回一个请求识别码。过一段时间后，我们再用识别码去请求结果。对于一些接口，并不保证获取结果时，结果已经可用，那有可能还得继续请求。期间识别码还可能失效，总之各种复杂。

2.如果接口是同步的，调用耗时大致是多少？
接口的耗时直接影响了你的系统的响应时间。所以一般需要测试一下接口的耗时，是否使用，看的是你对于系统的要求了。对于响应时间超过10秒的接口你一定要注意。如果你在脚本中调用这个接口或许还好，但是如果你在用户的请求中调用改接口，就会导致页面长时间等待，甚至超时。

3.接口的调用次数有什么限制？
许多接口，尤其是免费接口，有每天调用次数限制。对于有限制的接口，需要在代码里准好准备。

设计

同步接口的设计：

sync

对接程序是对接口的最直接包装，函数与接口一一对应。

而外部系统只能调用对外封装，对外封装结合了现在系统的特点，针对业务定制。

异步接口设计：

async

相较于同步复杂很多。大体上可以分为两步。

第一步，调用接口登记参数，在数据库中记录返回的中间结果。

第二步，调用获取结果结果，在数据库中更新结果，同时如果业务需要的话，调用callback继续第一步中中断的业务。

数据库设计

1
2
3
4
5
6
7
8
9
10
11
create table xxx_api(
    id int(10) unsigned not null auto_increment,
    user_id int(11) not null comment '用户id',
    api_type varchar(64) not null comment '接口类型',
    params varchar(1024) not null comment '调用参数',
    result varchar(4096) not null comment '接口返回结果',
    used_time int(11) not null comment '接口耗时,单位微秒',
    create_time timestamp not null default current_timestamp comment '创建时间',
    index (user_id,api_type),
    primary key (id)
)engine=InnoDB default charset=utf8 comment='xxx接口调用信息';

该数据库设计上，在记录参数和结果时，记录的是完整的原始请求参数和原始返回结果。

我在接入第一个接口时，设计的接口不是这样的，我是把接口中的信息提取出来，每个作为一个字段。因为我觉得我们需要的就是这些信息，作为字段，看起来方便查起来方便用起来方便。但是后来我就发现，这种设计，出问题就不方便啦。。。因为因为对方一般会说：把接口的放回结果发给我们看一下。然后我就懵逼了。。。

注意

日志

一定要多打日志，每一步主要逻辑都要打日志。数据库里的信息也记得全一点。因为一旦涉及接口调用的系统出了问题，需要排除是我方问题还是他方问题，如果他方问题，也得收集详细信息供他们调试。

坚决拒绝爬虫式接口

我曾经接入过一种爬虫式接口，是查询x保的。一开始，这种接口的文档看起来和正常的同步接口无异，只是有点麻烦，需要先获取特定城市页面输入格式，页面验证码，然后提交输入，获取结果。

后面才意识到，这家公司其实根本没有x保的信息，他们是写了全国各个城市网站的爬虫，首先他们获取页面输入，返回给我们，然后我们输入信息后（包括验证码），他再模拟登录，爬取下一个页面。

这种恶魔般的接口会带来非常多的问题。第一，接口的流程变长了，需要调用4个接口（获取城市，获取城市输入，获取验证码，获取结果）才能获取结果。而且这4个接口的调用是必须在那个爬虫的生命周期里的。流程变长，本身就会带来很多不稳定因素。加上必须是在一个爬虫生命周期里的，那么意味着对方不能同时接口很多的查询。（我是在开发中才发现，对方其实同时只能8个查询在进行。。。）。第二，因为结果是对方爬虫现爬的，速度没有保障，和读取数据库是有好几个数量级的差别的。我接入的那个结果，获取结果需要近20s。这个直接导致了用户页面的超时。第三，爬虫不稳定性很高。所以经常会得到各种莫名其妙的错误。实在是没精力帮对方测试啊。。

这个结果我折腾了两周都没有稳定下来（一般同步接口需要3天）。算是一个血的教训。

总结

  • 测试期，调研清楚，不靠谱的接口，和PM反馈
  • 开发期，注意打日志，数据库记录原始信息

这些是我一些浅薄的总结，有问题直说啊。