如何把一个接口设计好?
如何设计一个接口?是在我们日常开发或者面试时经常问及的一个话题。
很多人觉得这不就是CRUD,能实现不就行了。单纯实现来说,并非难事,但要做到易用、易扩展、易维护并不是一件简单的事。这里并不强调一些个接口设计的原则或者设计方法,仅从如何设计一个好的接口出发,简单讨论。
1、命名规范
我们写代码,不仅仅是为了实现当前的功能,也要有利于后面的维护。所谓的维护,就是代码不仅仅是写给自己看的,也是给别人看的。所以接口定义要清晰易懂、命名规范。
除了接口、方法、出入参命名规范,也要注意代码规范问题。一开始接触到各种代码坏味道的小伙伴,大多都会觉得这些规范很多余、很烦人,但实际上,这些好的编码习惯是让大家都能按照基本规约开发,易于阅读易于维护的基础。
在接口定义时,也请注意接口功能的单一性。其实这也是微服务的一些思想,接口功能的单一职责、明确简单。比如登录接口,它做的事情就是校验账户名和密码相关;订单服务、积分服务、商品信息相关的接口都是划分开的。
2、参数校验
入参出参校验是每个程序员必备的基本素养。你设计的接口,必须先校验参数。比如入参是否允许为空、入参长度要求、入参是否在枚举值范围内等等。日常开发中,很多低级bug都是不校验参数导致的。
提到参数,就必须提到接口状态和错误码。无论是失败还是成功,一个完备的接口都应该告诉调用方返回信息。如果接口失败,具体失败的原因是什么,这就需要定义明确的错误码和对应描述。同时,尽量对报错信息进行封装,不要直接将服务端异常信息抛出去。
3、监控/性能
如何评判一个接口的性能就必须要有监控,这对于服务端监视接口性能和异常报警至关重要。调用次数、可用率、TP99、TP999等监视指标,极其重要的核心接口,还需要细分至秒级监控加以标识。
一个接口的性能不单单只看自己业务逻辑,外部远程调用也是消耗性能的重要部分。如果你调用第三方接口或者远程服务,就需要考虑异常和超时。如果异常了,怎么处理,是重试还是当作失败还是告警处理。如果重试,重试几次?这就需要站在业务角度思考这个问题。这些措施也是直接影响当前接口性能。
提高性能的利器还可以考虑缓存。缓存用得好,可以承载更多的请求,提升查询效率,减少数据库的压力。但是使用缓存需要考虑缓存和数据库一致性保证、缓存击穿等问题。
4、日志
接口的关键代码,要有日志的保驾护航。首先日志级别需要合理使用:error > warn > info > debug。
其次日志信息包含哪些呢,核心代码块调用前的入参打印、接口调用后的异常捕获日志等。需要注意的是,如果日志中涉及比较大的JSON富文本,请使用log.isInfoEnable(),在高并发和复杂log信息拼接的情况下,使用这种标准的方法输出log能够省去不小的系统开销。另外,如果构造log信息的过程需要大量字符串操作,建议使用StringBuilder来完成字符串拼接。
5、异常/超时
实现一个好的接口,离不开优雅的异常处理。比如异常匹配的顺序,优先捕获具体的异常;使用流时记得使用finally关闭流资源;
对于运行时错误,比如数据边界越界、空指针也在日常开发中出现,该判断、该校验的还是一项不能少哦。
超时问题也经常会导致接口不可用。设置合理的超时时间,也是在保护你的接口。超时一般与重试搭配使用,不过请注意,设置超时时间时,需要充分考虑你的上下游设置的超时时间。比如一个请求率先访问你的上游,而你的上游设置的超时时间是500ms,上游调用你的接口,但你设置的超时是2000ms,这其实就是无效超时时间。
对于接口耗时优化,也是有一些手段的,比如远程串行改为并行调用、单次调用改为批量调用等等。但请注意尽量不在循环或者事务里远程调用。
6、异步
接口有些场景,使用异步更合理。举个简单的例子,对于一些运营操作的接口,往往需要记录对应操作的操作日志,记录下是谁在什么时间操作了什么对象,便于追踪“事发现场”。但是记录操作日志并不在接口主流程上,记录操作日志是否成功失败也不应该影响正常主流程的执行,这个时候就应该考虑用消息队列等方式进行异步解耦。
7、注释
可以说,注释也是良好代码的重要组成部分。有些人,一直相信show me the code,却不想写一行注释,认为没有必要。但是你无法保证代码逻辑一直清晰、高效。如果是比较复杂的话,就建议把注释写清楚,这对于后续维护和缕清代码逻辑很重要。
8、降级/限流
如今的请求调用基本都是分布式调用链路,当分布式系统中某个基础服务不可用时,就会最终导致整个系统不可用,所以当下游系统或者自身服务出现问题时,一定要考虑降级。如果做的更完备的话,还可以考虑熔断。
同时,针对高并发的流量洪峰接口,必须考虑限流应对超出系统的承载能力挑战。限流措施也同样可以限制爬虫,保护系统,丢弃多余的请求。
9、安全
这里说的安全,范围可太大了。比如线性安全,很多人反手上来就是HashMap,因为它是非线性安全的,可以考虑高并发下的ConcurrentHashMap。
如果前端重复请求,你的逻辑如何处理?是不是考虑接口去重处理(有时候是防刷处理)。简单点,可以使用redis防重处理,同样的请求,一定时间间隔内进行过滤。当然,对于一些并发不高的接口,比如转账类接口,推荐使用数据库主键或者唯一索引。
如果消息队列出现重复消费的情况,你的业务逻辑怎么控制?是不是考虑幂等性校验。
防重主要为了避免产生重复数据,把重复请求拦截下来即可。而幂等设计除了拦截已经处理的请求,还要求每次相同的请求都返回一样的结果。不过很多时候,它们的处理流程和方式是类似的。
还有一些其他安全方面的考虑,比如读写分离、代码锁的粒度控制、数据加密等等。
10、沟通
为什么要有沟通?又为什么把沟通放在最后呢?遇到一些技术难题,跟技术leader对齐方案。实现需求的过程中,有什么问题,需要及时跟产品沟通。需要跟客户端对齐接口,一定不能上来就自己埋头把接口定义完了。种种场景,学会沟通是非常重要的,有效、高效沟通不仅会带来愉悦心情,开发起来很顺畅,也会提高人际关系。
好啦,以上就是根据自身经验,对“如何设计一个接口?”问题的小小回答,如有不足,敬请指教。