为什么要有接口
为什么要有接口？很简单因为术业有专攻且客户的系统不止你一个，个个业务系统之间需要打通，所以活就来了；公司是要有收入的没收入只有喝西北风了来活意味着有收入。
接口非业务方面注意事项
可能有些地方说的不到位，或者说错的可以在评论区留言
第一个问题接口要分服务端和客户端
- 字面意思服务端就是提供服务的，客户端就是要连接服务端的一方。
第二个问题通信协议
| 服务提供方式 | 框架 | 使用频率 | 是否便捷 | 测试工具 |
|---|---|---|---|---|
| tcp/udp/quick | Netty | 低 | 不太方便，因为开发出稳定的tcp服务有点难度。 | 一般是专门自己搞的 |
| webservices | axis/axis2/cxf | 低 | 不太方便，服务端还可以。客户端的话我基本都是生成的代码，对于出问题调试很是头疼。另一个问题是对于https的支持问题。https的支持我这里想到的基本就是走http请求自己拼接协议头 | soapui |
| http/https | okhttp/httpclient/spring | 高现在大部分是Restful风格的 | 方便 | postman |
第三个问题就是通信协议格式
常用的xml/json；自定义格式（这个在tcp上用的比较多）；还有一部分是框架自己给转换了表面上是对象；
第四个问题客户端需要定时器
客户端一般都是需要一个定时框架的，所以得选择一个定时框架来支撑接口的。一些定时器框架quartz/xxl-job/spring-boot。这里还有个问题就是是否需要集群部署，所以得关注每个框架的集群配置，最好是有配置UI支持手工调整不用重启项目（或者这部分自己实现管理）。
第五个问题服务端注意项
- 日志所有的入参出参最基本的就是首先第一件事要记录到日志中。方便扯皮，重现问题。
- 服务端的话有些批处理需要限制下数据量的大小，如果你没限制的话那就要看客户端有没有突发情况了，对服务稳定性有影响的。
- 服务端限流这个算是特殊需求，对那些要中转的数据，有些可能要收费的需要注意下。
- 服务端还有个问题数据是否需要加密看客户需求了，有些加密服务客户有钱买的第三方服务但是加密认证的。（这里有个注意的问题是中英文需要测试好）。
- 服务端暴露服务是否需要认证，一般常见的是basic认证。
第六客户端注意事项
- 日志所有的入参出参、返回的状态最基本的就是首先第一件事要记录到日志中。方便扯皮，重现问题。
- 协议，报文，加解密，认证跟着服务端的文档搞了。
- 数据量的推送问题，有些上来直接全量数据推送，等到某些特殊原因服务停了几天量上来就是个问题了。
- 推送的时候取数最好用视图的方式，方便后面出问题能够迅速调整。
- 推送的定时器最好能够让实施可控。
- 尽量支持双数据源因为可能某些客户会通过中间库的方式处理数据的。
- 这里还有个失败重试的问题 看需求了。
- 还有些推送数据因为效率问题是服务端异步通知的。
今天就扯这么多吧。
