文章目录

1.接口参数校验

入参是否允许为空，入参长度是否符合你的预期长度。

比如你的数据库表字段设置为varchar(16),对方传了一个32位的字符串过来，如果你不校验参数，插入数据库直接异常了。

出参也是，比如你定义的接口报文，参数是不为空的，但是你的接口返回参数，没有做校验，因为程序某些原因，直返回别人一个null值。

2.注意接口的兼容性

//老接口
void oldService(A,B){
  //兼容新接口，传个null代替C
  newService(A,B,null);
}

//新接口，暂时不能删掉老接口，需要做兼容。
void newService(A,B,C){
  ...
}

3.充分考虑接口的可扩展性

复用接口

如何设计好接口 (一)_数据库

4.接口考虑是否需要防重处理

如果是查询类的请求，其实不用防重。如果是更新修改类的话，尤其金融转账类的，就要过滤重复请求了。

简单点，你可以使用​​Redis​​​防重复请求，同样的请求方，一定时间间隔内的相同请求，考虑是否过滤。当然，转账类接口，并发不高的话，推荐使用​​数据库防重表​​，以唯一流水号作为主键或者唯一索引。

如何设计好接口 (一)_第三方接口_02

5.重点接口考虑线程池隔离

登陆、转账交易、下单等重要接口, 考虑线程池隔离。如果所有业务一个线程池的话, 如果线程池打满的话, 就问题了。

如何设计好接口 (一)_开发语言_03

6.调用第三方接口要考虑异常和超时处理

如果你调用第三方接口，或者分布式远程服务的的话：

  • 异常处理
    比如，你调别人的接口，如果异常了，怎么处理，是重试还是当做失败还是告警处理。
  • 接口超时
    没法预估对方接口一般多久返回，一般设置个超时断开时间，以保护你的接口。
  • 重试次数

7.接口实现考虑熔断和降级

当前互联网系统一般都是分布式部署的。而分布式系统中经常会出现某个基础服务不可用，最终导致整个系统不可用的情况, 这种现象被称为​​服务雪崩效应​​。

如何设计好接口 (一)_java_04
如果服务C出现问题，比如是因为慢SQL导致调用缓慢，那将导致B也会延迟，从而A也会延迟。堵住的A请求会消耗占用系统的线程、IO等资源。当请求A的服务越来越多，占用计算机的资源也越来越多，最终会导致系统瓶颈出现，造成其他的请求同样不可用，最后导致业务系统崩溃。

为了应对服务雪崩, 常见的做法是​​熔断​​​和​​降级​​​。最简单是加开关控制，当下游系统出问题时，开关降级，不再调用下游系统。还可以选用开源组件​​Hystrix, Sentinal, Redis, Guava​​。

8.接口的功能定义要具备单一性

单一性是指接口做的事情比较单一、专一。比如一个登陆接口，它做的事情就只是校验账户名密码，然后返回登陆成功以及userId即可。但是如果你为了减少接口交互，把一些注册、一些配置查询等全放到登陆接口，就不太妥。

口的功能单一、明确。比如订单服务、积分、商品信息相关的接口都是划分开的。

9.日志打印好

日志保驾护航: