最近两年一直在和银行、公安、保险、民政等第三方单位之间做接口，写的接口文档不下30份，最初的接口文档漏洞百出，改了又改，丢了不少人，也被批评、埋怨，指责了很多次，久而久之，明白了一个最重要的道理，协作决定接口。双方谈接口时，技术不是最重要的，要兼顾双方技术，成本，工期等等很多因素。但仍有很多技术层面的心得，恰巧上周参与温昱老师的一个性能设计的外训，里面老师讲到了接口设计，正好回来一起整理一下接口设计的经验。主要从3个方面总结一下系统间接口设计：接口定义、接口实现、其他一些注意事项。
一、接口定义
接口是双方（可能是系统、模块、服务等）之间数据交互的一个标准，定制接口方要想让对方没有疑问，接口考虑到的因素一定要全面，一般情况下，主要考虑3个步骤：
交互机制：如同步请求/应答方式、异步请求/应答方式、会话方式、广播通知方式、事件订阅方式、可靠消息传输方式、文件传输等。
接口技术：WebService、Scoket、交易中间件、消息中间件、文件方式、共享数据库等。
接口格式：这个就根据所选技术，实际情况来定义即可。
拿我们（具体行业不便透露）和银行的接口为例（和每个地区银行都不同，以1个为例）
交互机制：异步请求/应答方式，我们有查控请求时调用银行接口，将请求信息发过去，银行查控完毕后，调用我们接口，将查控结果反馈给我们。调用失败后，会有重试，重试每30分钟一次。
接口技术：WebService接口，Java开发，xml格式报文，数据采用3DES加密。
接口定义：具体字段说明，xml格式等略。
有了这些说明，在对方拿到接口文档后，不出意外（比如对方完全不懂技术，无法看懂）对方都能看懂接口，也能描述清楚，如果回答不上这些问题，恐怕就是有漏洞了。
这个接口还有很多不完善的，很多地方有更好的选择，还是前面说的，协作决定接口，合适即可。
二、接口实现
接口定义完成了，开发过程中要考虑的就是非功能层面的了，比如各种约束，像我们这边数据量、并发都较大，需要考虑下面几个情况：
1.高性能，支持高并发，大容量，速度快；
2.健壮性，防止因大量数据，或大量占用资源导致系统不可用；
3.可监控，随时看到接口的运行情况，便于及时发现错误及排除故障；
4.可扩展，两个方面，一是可支持扩展新功能，二是并发增加时支持扩展新硬件。
考虑这些可能会引起接口的改变，比如我们考虑高性能，速度快时，由于我们同时对应30多家银行，每个银行每天大约1000人次查询，单个调用需要3w次，所以改成了支持批量，单次调用最多100人，发送和接收大约5s左右。同时由原来串行改成了并发调用，，使用了一个线程池（线程不能太多，可能造成银行接口并发太大导致崩溃）。
有时主动发起的接口可能不如定时轮询的接口，比如上面我们的接口是主动发起，需要做连接池限制并发，免得并发多了给银行造成问题，后来再其他省改成了完全由我们做服务端，银行定时调用获取要查询的请求信息，虽然有几分钟延迟（依据银行轮询时间决定），但是开发简单不少，考虑的情况也少了不少，接口速度也快了不少。
考虑可监控时，有很多开源监控组件，比如我们用的JavaMelody，可以监控某个类执行次数。
考虑可扩展，功能可扩展，比如我们用XML、JSON格式报文，或者其他自定义格式，有一定的规则，千万别用具体含义的参数，一旦增删就会影响接口。
三、注意事项
1.支持批量，这个一定要有，主要是为了性能考虑，后续数据量大了，再修改支持批量就会导致整个接口修改，所以前期一定要支持批量。
2.支持部分拆包，比如报文中最好解析报文头就能知道具体业务或能找到处理的逻辑，避免全部解析后才能知道如何处理，比如我们和一个公司做接口（他们制定接口），有10多个实现类，他们文件加密的，必须整体解密后才能读取到用哪个实现类处理，文件大约200M，每次处理5s左右，有3s都在选择用哪个实现类，并发时及其慢，后来改成了前面32个字节标示哪个实现类，后来处理每个包2s左右，性能提升40%多。
大海，别为森林的渺小而沮丧，
