目录
-
前言
-
设计好接口的 36 个锦囊
-
总结
前言
作为后端开发,不管是什么语言,Java、Go 还是 C++,其背后的后端思想都是类似的。我们做后端开发工程师,主要工作就是:如何把一个接口设计好。所以,今天就给大家介绍,设计好接口的 36 个锦囊。
设计好接口的 36 个锦囊
| 接口参数校验
入参出参校验是每个程序员必备的基本素养。你设计的接口,必须先校验参数。
比如入参是否允许为空,入参长度是否符合你的预期长度。这个要养成习惯哈,日常开发中,很多低级 bug 都是不校验参数导致的。
比如你的数据库表字段设置为 varchar(16),对方传了一个 32 位的字符串过来,如果你不校验参数,插入数据库直接异常了。
出参也是,比如你定义的接口报文,参数是不为空的,但是你的接口返回参数,没有做校验,因为程序某些原因,直返回别人一个 null 值…
| 修改老接口时,注意接口的兼容性
很多 bug 都是因为修改了对外旧接口,但是却不做兼容导致的。关键这个问题多数是比较严重的,可能直接导致系统发版失败的。新手程序员很容易犯这个错误哦~
所以,如果你的需求是在原来接口上修改,尤其这个接口是对外提供服务的话,一定要考虑接口兼容。
举个例子吧,比如 dubbo 接口,原本是只接收 A,B 参数,现在你加了一个参数 C,就可以考虑这样处理:
| 设计接口时,充分考虑接口的可扩展性
要根据实际业务场景设计接口,充分考虑接口的可扩展性。
比如你接到一个需求:是用户添加或者修改员工时,需要刷脸。那你是反手提供一个员工管理的提交刷脸信息接口是先思考:提交刷脸是不是通用流程呢/p>
比如转账或者一键贴现需要接入刷脸的话,你是否需要重新实现一个接口呢是当前按业务类型划分模块,复用这个接口就好,保留接口的可扩展性。
如果按模块划分的话,未来如果其他场景比如一键贴现接入刷脸的话,不用再搞一套新的接口,只需要新增枚举,然后复用刷脸通过流程接口,实现一键贴现刷脸的差异化即可。
| 接口考虑是否需要防重处理
如果前端重复请求,你的逻辑如何处理不是考虑接口去重处理。
当然,如果是查询类的请求,其实不用防重。如果是更新修改类的话,尤其金融转账类的,就要过滤重复请求了。
简单点,你可以使用 Redis 防重复请求,同样的请求方,一定时间间隔内的相同请求,考虑是否过滤。
当然,转账类接口,并发不高的话,推荐使用数据库防重表,以唯一流水号作为主键或者唯一索引。
| 重点接口,考虑线程池隔离
一些登陆、转账交易、下单等重要接口,考虑线程池隔离哈。如果你所有业务都共用一个线程池,有些业务出 bug 导致线程池阻塞打满的话,那就杯具了,所有业务都影响了。
因此进行线程池隔离,重要业务分配多一点的核心线程,就更好保护重要业务。
| 调用第三方接口要考虑异常和超时处理
如果你调用第三方接口,或者分布式远程服务的的话,需要考虑:
-
异常处理:比如,你调别人的接口,如果异常了,怎么处理,是重试还是当做失败还是告警处理。
-
接口超时:没法预估对方接口一般多久返回,一般设置个超时断开时间,以保护你的接口。之前见过一个生产问题,就是http调用不设置超时时间,最后响应方进程假死,请求一直占着线程不释放,拖垮线程池。
-
重试次数:你的接口调失败,需不需要重试试几次要站在业务上角度思考这个问题。
| 接口实现考虑熔断和降级
当前互联网系统一般都是分布式部署的。而分布式系统中经常会出现某个基础服务不可用,最终导致整个系统不可用的情况,这种现象被称为服务雪崩效应。
比如分布式调用链路 A->B->C….,下图所示:
如果服务 C 出现问题,比如是因为慢 SQL 导致调用缓慢,那将导致 B 也会延迟,从而 A 也会延迟。堵住的 A 请求会消耗占用系统的线程、IO 等资源。当请求 A 的服务越来越多,占用计算机的资源也越来越多,最终会导致系统瓶颈出现,造成其他的请求同样不可用,最后导致业务系统崩溃。
为了应对服务雪崩, 常见的做法是熔断和降级。最简单是加开关控制,当下游系统出问题时,开关降级,不再调用下游系统。还可以选用开源组件 Hystrix。
| 日志打印好,接口的关键代码,要有日志保驾护航
关键业务代码无论身处何地,都应该有足够的日志保驾护航。
比如:你实现转账业务,转个几百万,然后转失败了,接着客户投诉,然后你还没有打印到日志,想想那种水深火热的困境下,你却毫无办法…
那么,你的转账业务都需要哪些日志信息呢少,方法调用前,入参需要打印需要吧,接口调用后,需要捕获一下异常吧,同时打印异常相关日志吧,如下:
| 接口的功能定义要具备单一性
单一性是指接口做的事情比较单一、专一。比如一个登陆接口,它做的事情就只是校验账户名密码,然后返回登陆成功以及 userId 即可。
但是如果你为了减少接口交互,把一些注册、一些配置查询等全放到登陆接口,就不太妥。
其实这也是微服务一些思想,接口的功能单一、明确。比如订单服务、积分、商品信息相关的接口都是划分开的。将来拆分微服务的话,是不是就比较简便啦。
| 接口有些场景,使用异步更合理
举个简单的例子,比如你实现一个用户注册的接口。用户注册成功时,发个邮件或者短信去通知用户。
这个邮件或者发短信,就更适合异步处理。因为总不能一个通知类的失败,导致注册失败吧。
至于做异步的方式,简单的就是用线程池。还可以使用消息队列,就是用户注册成功后,生产者产生一个注册成功的消息,消费者拉到注册成功的消息,就发送通知。
不是所有的接口都适合设计为同步接口。比如你要做一个转账的功能,如果你是单笔的转账,你是可以把接口设计同步。用户发起转账时,客户端在静静等待转账结果就好。
如果你是批量转账,一个批次一千笔,甚至一万笔的,你则可以把接口设计为异步。就是用户发起批量转账时,持久化成功就先返回受理成功。
然后用户隔十分钟或者十五分钟等再来查转账结果就好。又或者,批量转账成功后,再回调上游系统。
| 优化接口耗时,远程串行考虑改并行调用
假设我们设计一个 APP 首页的接口,它需要查用户信息、需要查 banner 信息、需要查弹窗信息等等。那你是一个一个接口串行调,还是并行调用呢/p>
如果是串行一个一个查,比如查用户信息 200ms,查 banner 信息 100ms、查弹窗信息 50ms,那一共就耗时 350ms 了,如果还查其他信息,那耗时就更大了。
这种场景是可以改为并行调用的。也就是说查用户信息、查 banner 信息、查弹窗信息,可以同时发起。
在 Java 中有个异步编程利器:CompletableFuture,就可以很好实现这个功能。
| 接口合并或者说考虑批量处理思想
数据库操作或或者是远程调用时,能批量操作就不要 for 循环调用。
一个简单例子,我们平时一个列表明细数据插入数据库时,不要在 for 循环一条一条插入,建议一个批次几百条,进行批量插入。
同理远程调用也类似想法,比如你查询营销标签是否命中,可以一个标签一个标签去查,也可以批量标签去查,那批量进行,效率就更高嘛。
小伙伴们是否了解过 kafka 为什么这么快呢实其中一点原因,就是 kafka 使用批量消息提升服务端处理能力。
| 接口实现过程中,恰当使用缓存
哪些场景适合使用缓存多写少且数据时效要求越低的场景。缓存用得好,可以承载更多的请求,提升查询效率,减少数据库的压力。
比如一些平时变动很小或者说几乎不会变的商品信息,可以放到缓存,请求过来时,先查询缓存,如果没有再查数据库,并且把数据库的数据更新到缓存。
但是,使用缓存增加了需要考虑这些点:缓存和数据库一致性如何保证、集群、缓存击穿、缓存雪崩、缓存穿透等问题。
-
保证数据库和缓存一致性:缓存延时双删、删除缓存重试机制、读取biglog异步删除缓存
-
缓存击穿:设置数据永不过期
-
缓存雪崩:Redis 集群高可用、均匀设置过期时间
-
缓存穿透:接口层校验、查询为空设置个默认空值标记、布隆过滤器。
一般用 Redis 分布式缓存,当然有些时候也可以考虑使用本地缓存,如 Guava Cache、Caffeine 等。
使用本地缓存有些缺点,就是无法进行大数据存储,并且应用进程的重启,缓存会失效。
| 接口考虑热点数据隔离性
瞬时间的高并发,可能会打垮你的系统。可以做一些热点数据的隔离。比如业务隔离、系统隔离、用户隔离、数据隔离等。
-
业务隔离性,比如 12306 的分时段售票,将热点数据分散处理,降低系统负载压力。
-
系统隔离:比如把系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库,做到从接入层到应用层再到数据层三层完全隔离。
-
用户隔离:重点用户请求到配置更好的机器。
-
数据隔离:使用单独的缓存集群或者数据库服务热点数据。
| 可变参数配置化,比如红包皮肤切换等
假如产品经理提了个红包需求,圣诞节的时候,红包皮肤为圣诞节相关的,春节的时候,为春节红包皮肤等。
如果在代码写死控制,可有类似以下代码:
如果到了元宵节的时候,运营小姐姐突然又有想法,红包皮肤换成灯笼相关的,这时候,是不是要去修改代码了,重新发布了/p>
从一开始接口设计时,可以实现一张红包皮肤的配置表,将红包皮肤做成配置化呢换红包皮肤,只需修改一下表数据就好了。
当然,还有一些场景适合一些配置化的参数:一个分页多少数量控制、某个抢红包多久时间过期这些,都可以搞到参数配置化表里面。这也是扩展性思想的一种体现。
| 接口考虑幂等性
接口是需要考虑幂等性的,尤其抢红包、转账这些重要接口。最直观的业务场景,就是用户连着点击两次,你的接口有没有 hold 住。或者消息队列出现重复消费的情况,你的业务逻辑怎么控制/p>
回忆下,什么是幂等算机科学中,幂等表示一次和多次请求某一个资源应该具有同样的副作用,或者说,多次请求所产生的影响与一次请求执行的影响效果相同。
大家别搞混哈,防重和幂等设计其实是有区别的。防重主要为了避免产生重复数据,把重复请求拦截下来即可。
而幂等设计除了拦截已经处理的请求,还要求每次相同的请求都返回一样的效果。不过呢,很多时候,它们的处理流程、方案是类似的哈。
接口幂等实现方案主要有 8 种:
-
select+insert+主键/唯一索引冲突
-
直接 insert + 主键/唯一索引冲突
-
状态机幂等
-
抽取防重表
-
token 令牌
-
悲观锁
-
乐观锁
-
分布式锁
| 读写分离,优先考虑读从库,注意主从延迟问题
我们的数据库都是集群部署的,有主库也有从库,当前一般都是读写分离的。
比如你写入数据,肯定是写入主库,但是对于读取实时性要求不高的数据,则优先考虑读从库,因为可以分担主库的压力。
如果读取从库的话,需要考虑主从延迟的问题。
| 接口注意返回的数据量,如果数据量大需要分页
一个接口返回报文,不应该包含过多的数据量。过多的数据量不仅处理复杂,并且数据量传输的压力也非常大。
因此数量实在是比较大,可以分页返回,如果是功能不相关的报文,那应该考虑接口拆分。
| 好的接口实现,离不开 SQL 优化
我们做后端的,写好一个接口,离不开 SQL 优化。
SQL 优化从这几个维度思考:
-
explain 分析 SQL 查询计划(重点关注 type、extra、filtered 字段)
-
show profile 分析,了解 SQL 执行的线程的状态以及消耗的时间
-
索引优化 (覆盖索引、最左前缀原则、隐式转换、order by 以及 group by 的优化、join 优化)
-
大分页问题优化(延迟关联、记录上一页最大 ID)
-
数据量太大(分库分表、同步到 es,用 es 查询)
| 代码锁的粒度控制好
什么是加锁粒度呢实就是就是你要锁住的范围是多大。比如你在家上卫生间,你只要锁住卫生间就可以了吧,不需要将整个家都锁起来不让家人进门吧,卫生间就是你的加锁粒度。
我们写代码时,如果不涉及到共享资源,就没有必要锁住的。这就好像你上卫生间,不用把整个家都锁住,锁住卫生间门就可以了。
比如,在业务代码中,有一个 ArrayList 因为涉及到多线程操作,所以需要加锁操作,假设刚好又有一段比较耗时的操作(代码中的 slowNotShare 方法)不涉及线程安全问题,你会如何加锁呢/p>
反例:
正例:
??????????????????????????????????????????
| 接口状态和错误需要统一明确
提供必要的接口调用状态信息。比如你的一个转账接口调用是成功、失败、处理中还是受理成功等,需要明确告诉客户端。如果接口失败,那么具体失败的原因是什么。
这些必要的信息都必须要告诉给客户端,因此需要定义明确的错误码和对应的描述。同时,尽量对报错信息封装一下,不要把后端的异常信息完全抛出到客户端。
| 接口要考虑异常处理
实现一个好的接口,离不开优雅的异常处理。
对于异常处理,提十个小建议吧:
-
尽量不要使用 e.printStackTrace(),而是使用 log 打印。因为 e.printStackTrace() 语句可能会导致内存占满
-
catch 住异常时,建议打印出具体的 exception,利于更好定位问题
-
不要用一个 Exception 捕捉所有可能的异常
-
记得使用 finally 关闭流资源或者直接使用 try-with-resource
-
捕获异常与抛出异常必须是完全匹配,或者捕获异常是抛异常的父类
-
捕获到的异常,不能忽略它,至少打点日志吧
-
注意异常对你的代码层次结构的侵染
-
自定义封装异常,不要丢弃原始异常的信息 Throwable cause
-
运行时异常 RuntimeException ,不应该通过 catch 的方式来处理,而是先预检查,比如:NullPointerException 处理
-
注意异常匹配的顺序,优先捕获具体的异常
| 优化程序逻辑
优化程序逻辑这块还是挺重要的,也就是说,你实现的业务代码,如果是比较复杂的话,建议把注释写清楚。还有,代码逻辑尽量清晰,代码尽量高效。
比如,你要使用用户信息的属性,你根据 session 已经获取到 userId 了,然后就把用户信息从数据库查询出来,使用完后,后面可能又要用到用户信息的属性,有些小伙伴没想太多,反手就把 userId 再传进去,再查一次数据库。。。我在项目中,见过这种代码。。。直接把用户对象传下来不好嘛。。
反例伪代码:
-
public Response test(Session session){
- UserInfo user = UserDao.queryByUserId(session.getUserId());
-
-