设计类参考网站推荐,有什么网站可以帮人做模具吗,wordpress粘贴媒体库,中国建设银行官网站e路通下载目录
设计好接口的 36 个锦囊
| 接口参数校验
| 修改老接口时#xff0c;注意接口的兼容性
| 设计接口时#xff0c;充分考虑接口的可扩展性
| 接口考虑是否需要防重处理
| 重点接口#xff0c;考虑线程池隔离
| 调用第三方接口要考虑异常和超时处理
| 接口实现考虑…目录
设计好接口的 36 个锦囊
| 接口参数校验
| 修改老接口时注意接口的兼容性
| 设计接口时充分考虑接口的可扩展性
| 接口考虑是否需要防重处理
| 重点接口考虑线程池隔离
| 调用第三方接口要考虑异常和超时处理
| 接口实现考虑熔断和降级
| 日志打印好接口的关键代码要有日志保驾护航
| 接口的功能定义要具备单一性
| 接口有些场景使用异步更合理
| 优化接口耗时远程串行考虑改并行调用
| 接口合并或者说考虑批量处理思想
| 接口实现过程中恰当使用缓存
| 接口考虑热点数据隔离性
| 可变参数配置化比如红包皮肤切换等
| 接口考虑幂等性
| 读写分离优先考虑读从库注意主从延迟问题
| 接口注意返回的数据量如果数据量大需要分页
| 好的接口实现离不开 SQL 优化
| 代码锁的粒度控制好
| 接口状态和错误需要统一明确
| 接口要考虑异常处理
| 优化程序逻辑
| 接口实现过程中注意大文件、大事务、大对象
| 你的接口需要考虑限流
| 代码实现时注意运行时异常比如空指针、下标越界等
| 保证接口安全性
| 分布式事务如何保证
| 事务失效的一些经典场景
| 掌握常用的设计模式
| 写代码时考虑线性安全问题
| 接口定义清晰易懂命名规范
| 接口的版本控制
| 注意代码规范问题
| 保证接口正确性其实就是保证更少的 bug
| 学会沟通跟前端沟通跟产品沟通 前言 作为后端开发不管是什么语言Java、Go 还是 C其背后的后端思想都是类似的。我们做后端开发工程师主要工作就是如何把一个接口设计好。所以今天就给大家介绍设计好接口的 36 个锦囊。 设计好接口的 36 个锦囊 | 接口参数校验
入参出参校验是每个程序员必备的基本素养。你设计的接口必须先校验参数。 比如入参是否允许为空入参长度是否符合你的预期长度。这个要养成习惯哈日常开发中很多低级 bug 都是不校验参数导致的。 比如你的数据库表字段设置为 varchar(16)对方传了一个 32 位的字符串过来如果你不校验参数插入数据库直接异常了。 出参也是比如你定义的接口报文参数是不为空的但是你的接口返回参数没有做校验因为程序某些原因直返回别人一个 null 值... | 修改老接口时注意接口的兼容性
很多 bug 都是因为修改了对外旧接口但是却不做兼容导致的。关键这个问题多数是比较严重的可能直接导致系统发版失败的。新手程序员很容易犯这个错误哦~
所以如果你的需求是在原来接口上修改尤其这个接口是对外提供服务的话一定要考虑接口兼容。 举个例子吧比如 dubbo 接口原本是只接收 AB 参数现在你加了一个参数 C就可以考虑这样处理
//老接口
void oldService(A,B){//兼容新接口传个null代替CnewService(A,B,null);
}//新接口暂时不能删掉老接口需要做兼容。
void newService(A,B,C){...
}| 设计接口时充分考虑接口的可扩展性
要根据实际业务场景设计接口充分考虑接口的可扩展性。 比如你接到一个需求是用户添加或者修改员工时需要刷脸。那你是反手提供一个员工管理的提交刷脸信息接口还是先思考提交刷脸是不是通用流程呢 比如转账或者一键贴现需要接入刷脸的话你是否需要重新实现一个接口呢还是当前按业务类型划分模块复用这个接口就好保留接口的可扩展性。 如果按模块划分的话未来如果其他场景比如一键贴现接入刷脸的话不用再搞一套新的接口只需要新增枚举然后复用刷脸通过流程接口实现一键贴现刷脸的差异化即可。 | 接口考虑是否需要防重处理
如果前端重复请求你的逻辑如何处理是不是考虑接口去重处理。 当然如果是查询类的请求其实不用防重。如果是更新修改类的话尤其金融转账类的就要过滤重复请求了。 简单点你可以使用 Redis 防重复请求同样的请求方一定时间间隔内的相同请求考虑是否过滤。 当然转账类接口并发不高的话推荐使用数据库防重表以唯一流水号作为主键或者唯一索引。 | 重点接口考虑线程池隔离
一些登陆、转账交易、下单等重要接口考虑线程池隔离哈。如果你所有业务都共用一个线程池有些业务出 bug 导致线程池阻塞打满的话那就杯具了所有业务都影响了。 因此进行线程池隔离重要业务分配多一点的核心线程就更好保护重要业务。 | 调用第三方接口要考虑异常和超时处理
如果你调用第三方接口或者分布式远程服务的的话需要考虑 异常处理比如你调别人的接口如果异常了怎么处理是重试还是当做失败还是告警处理。 接口超时没法预估对方接口一般多久返回一般设置个超时断开时间以保护你的接口。之前见过一个生产问题就是http调用不设置超时时间最后响应方进程假死请求一直占着线程不释放拖垮线程池。 重试次数你的接口调失败需不需要重试重试几次需要站在业务上角度思考这个问题。 | 接口实现考虑熔断和降级
当前互联网系统一般都是分布式部署的。而分布式系统中经常会出现某个基础服务不可用最终导致整个系统不可用的情况这种现象被称为服务雪崩效应。 比如分布式调用链路 A-B-C....下图所示 如果服务 C 出现问题比如是因为慢 SQL 导致调用缓慢那将导致 B 也会延迟从而 A 也会延迟。堵住的 A 请求会消耗占用系统的线程、IO 等资源。当请求 A 的服务越来越多占用计算机的资源也越来越多最终会导致系统瓶颈出现造成其他的请求同样不可用最后导致业务系统崩溃。 为了应对服务雪崩, 常见的做法是熔断和降级。最简单是加开关控制当下游系统出问题时开关降级不再调用下游系统。还可以选用开源组件 Hystrix。 | 日志打印好接口的关键代码要有日志保驾护航
关键业务代码无论身处何地都应该有足够的日志保驾护航。 比如你实现转账业务转个几百万然后转失败了接着客户投诉然后你还没有打印到日志想想那种水深火热的困境下你却毫无办法... 那么你的转账业务都需要哪些日志信息呢至少方法调用前入参需要打印需要吧接口调用后需要捕获一下异常吧同时打印异常相关日志吧如下
public void transfer(TransferDTO transferDTO){log.info(invoke tranfer begin);//打印入参log.info(invoke tranfer,paramters:{},transferDTO);try {res transferService.transfer(transferDTO);}catch(Exception e){log.error(transfer fail,account{},transferDTO.getAccount)log.error(transfer fail,exception:{},e);}log.info(invoke tranfer end);}| 接口的功能定义要具备单一性
单一性是指接口做的事情比较单一、专一。比如一个登陆接口它做的事情就只是校验账户名密码然后返回登陆成功以及 userId 即可。 但是如果你为了减少接口交互把一些注册、一些配置查询等全放到登陆接口就不太妥。 其实这也是微服务一些思想接口的功能单一、明确。比如订单服务、积分、商品信息相关的接口都是划分开的。将来拆分微服务的话是不是就比较简便啦。 | 接口有些场景使用异步更合理
举个简单的例子比如你实现一个用户注册的接口。用户注册成功时发个邮件或者短信去通知用户。 这个邮件或者发短信就更适合异步处理。因为总不能一个通知类的失败导致注册失败吧。 至于做异步的方式简单的就是用线程池。还可以使用消息队列就是用户注册成功后生产者产生一个注册成功的消息消费者拉到注册成功的消息就发送通知。 不是所有的接口都适合设计为同步接口。比如你要做一个转账的功能如果你是单笔的转账你是可以把接口设计同步。用户发起转账时客户端在静静等待转账结果就好。 如果你是批量转账一个批次一千笔甚至一万笔的你则可以把接口设计为异步。就是用户发起批量转账时持久化成功就先返回受理成功。 然后用户隔十分钟或者十五分钟等再来查转账结果就好。又或者批量转账成功后再回调上游系统。 | 优化接口耗时远程串行考虑改并行调用
假设我们设计一个 APP 首页的接口它需要查用户信息、需要查 banner 信息、需要查弹窗信息等等。那你是一个一个接口串行调还是并行调用呢 如果是串行一个一个查比如查用户信息 200ms查 banner 信息 100ms、查弹窗信息 50ms那一共就耗时 350ms 了如果还查其他信息那耗时就更大了。 这种场景是可以改为并行调用的。也就是说查用户信息、查 banner 信息、查弹窗信息可以同时发起。 在 Java 中有个异步编程利器CompletableFuture就可以很好实现这个功能。 | 接口合并或者说考虑批量处理思想
数据库操作或或者是远程调用时能批量操作就不要 for 循环调用。
一个简单例子我们平时一个列表明细数据插入数据库时不要在 for 循环一条一条插入建议一个批次几百条进行批量插入。 同理远程调用也类似想法比如你查询营销标签是否命中可以一个标签一个标签去查也可以批量标签去查那批量进行效率就更高嘛。
//反例
for(int i0;in;i){remoteSingleQuery(param)
}//正例
remoteBatchQuery(param);小伙伴们是否了解过 kafka 为什么这么快呢其实其中一点原因就是 kafka 使用批量消息提升服务端处理能力。 | 接口实现过程中恰当使用缓存
哪些场景适合使用缓存读多写少且数据时效要求越低的场景。缓存用得好可以承载更多的请求提升查询效率减少数据库的压力。 比如一些平时变动很小或者说几乎不会变的商品信息可以放到缓存请求过来时先查询缓存如果没有再查数据库并且把数据库的数据更新到缓存。 但是使用缓存增加了需要考虑这些点缓存和数据库一致性如何保证、集群、缓存击穿、缓存雪崩、缓存穿透等问题。 保证数据库和缓存一致性缓存延时双删、删除缓存重试机制、读取biglog异步删除缓存 缓存击穿设置数据永不过期 缓存雪崩Redis 集群高可用、均匀设置过期时间 缓存穿透接口层校验、查询为空设置个默认空值标记、布隆过滤器。 一般用 Redis 分布式缓存当然有些时候也可以考虑使用本地缓存如 Guava Cache、Caffeine 等。 使用本地缓存有些缺点就是无法进行大数据存储并且应用进程的重启缓存会失效。 | 接口考虑热点数据隔离性
瞬时间的高并发可能会打垮你的系统。可以做一些热点数据的隔离。比如业务隔离、系统隔离、用户隔离、数据隔离等。 业务隔离性比如 12306 的分时段售票将热点数据分散处理降低系统负载压力。 系统隔离比如把系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库做到从接入层到应用层再到数据层三层完全隔离。 用户隔离重点用户请求到配置更好的机器。 数据隔离使用单独的缓存集群或者数据库服务热点数据。 | 可变参数配置化比如红包皮肤切换等
假如产品经理提了个红包需求圣诞节的时候红包皮肤为圣诞节相关的春节的时候为春节红包皮肤等。 如果在代码写死控制可有类似以下代码
if(duringChristmas){img redPacketChristmasSkin;
}else if(duringSpringFestival){img redSpringFestivalSkin;
}如果到了元宵节的时候运营小姐姐突然又有想法红包皮肤换成灯笼相关的这时候是不是要去修改代码了重新发布了 从一开始接口设计时可以实现一张红包皮肤的配置表将红包皮肤做成配置化呢更换红包皮肤只需修改一下表数据就好了。 当然还有一些场景适合一些配置化的参数一个分页多少数量控制、某个抢红包多久时间过期这些都可以搞到参数配置化表里面。这也是扩展性思想的一种体现。 | 接口考虑幂等性
接口是需要考虑幂等性的尤其抢红包、转账这些重要接口。最直观的业务场景就是用户连着点击两次你的接口有没有 hold 住。或者消息队列出现重复消费的情况你的业务逻辑怎么控制 回忆下什么是幂等计算机科学中幂等表示一次和多次请求某一个资源应该具有同样的副作用或者说多次请求所产生的影响与一次请求执行的影响效果相同。 大家别搞混哈防重和幂等设计其实是有区别的。防重主要为了避免产生重复数据把重复请求拦截下来即可。 而幂等设计除了拦截已经处理的请求还要求每次相同的请求都返回一样的效果。不过呢很多时候它们的处理流程、方案是类似的哈。
接口幂等实现方案主要有 8 种 selectinsert主键/唯一索引冲突 直接 insert 主键/唯一索引冲突 状态机幂等 抽取防重表 token 令牌 悲观锁 乐观锁 分布式锁 | 读写分离优先考虑读从库注意主从延迟问题
我们的数据库都是集群部署的有主库也有从库当前一般都是读写分离的。 比如你写入数据肯定是写入主库但是对于读取实时性要求不高的数据则优先考虑读从库因为可以分担主库的压力。 如果读取从库的话需要考虑主从延迟的问题。 | 接口注意返回的数据量如果数据量大需要分页
一个接口返回报文不应该包含过多的数据量。过多的数据量不仅处理复杂并且数据量传输的压力也非常大。 因此数量实在是比较大可以分页返回如果是功能不相关的报文那应该考虑接口拆分。 | 好的接口实现离不开 SQL 优化
我们做后端的写好一个接口离不开 SQL 优化。 SQL 优化从这几个维度思考 explain 分析 SQL 查询计划重点关注 type、extra、filtered 字段 show profile 分析了解 SQL 执行的线程的状态以及消耗的时间 索引优化 覆盖索引、最左前缀原则、隐式转换、order by 以及 group by 的优化、join 优化 大分页问题优化延迟关联、记录上一页最大 ID 数据量太大分库分表、同步到 es用 es 查询 | 代码锁的粒度控制好
什么是加锁粒度呢其实就是就是你要锁住的范围是多大。比如你在家上卫生间你只要锁住卫生间就可以了吧不需要将整个家都锁起来不让家人进门吧卫生间就是你的加锁粒度。 我们写代码时如果不涉及到共享资源就没有必要锁住的。这就好像你上卫生间不用把整个家都锁住锁住卫生间门就可以了。 比如在业务代码中有一个 ArrayList 因为涉及到多线程操作所以需要加锁操作假设刚好又有一段比较耗时的操作代码中的 slowNotShare 方法不涉及线程安全问题你会如何加锁呢 反例
//不涉及共享资源的慢方法
private void slowNotShare() {try {TimeUnit.MILLISECONDS.sleep(100);} catch (InterruptedException e) {}
}//错误的加锁方法
public int wrong() {long beginTime System.currentTimeMillis();IntStream.rangeClosed(1, 10000).parallel().forEach(i - {//加锁粒度太粗了slowNotShare其实不涉及共享资源synchronized (this) {slowNotShare();data.add(i);}});log.info(cosume time:{}, System.currentTimeMillis() - beginTime);return data.size();
}正例
public int right() {long beginTime System.currentTimeMillis();IntStream.rangeClosed(1, 10000).parallel().forEach(i - {slowNotShare();//可以不加锁//只对List这部分加锁synchronized (data) {data.add(i);}});log.info(cosume time:{}, System.currentTimeMillis() - beginTime);return data.size();
}
| 接口状态和错误需要统一明确
提供必要的接口调用状态信息。比如你的一个转账接口调用是成功、失败、处理中还是受理成功等需要明确告诉客户端。如果接口失败那么具体失败的原因是什么。 这些必要的信息都必须要告诉给客户端因此需要定义明确的错误码和对应的描述。同时尽量对报错信息封装一下不要把后端的异常信息完全抛出到客户端。 | 接口要考虑异常处理
实现一个好的接口离不开优雅的异常处理。 对于异常处理提十个小建议吧 尽量不要使用 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());if(usernull){reutrn new Response();}return do(session.getUserId());
}public Response do(String UserId){//多查了一次数据库UserInfo user UserDao.queryByUserId(session.getUserId());......return new Response();
}正例
public Response test(Session session){UserInfo user UserDao.queryByUserId(session.getUserId());if(usernull){reutrn new Response();}return do(session.getUserId());
}//直接传UserInfo对象过来即可不用再多查一次数据库
public Response do(UserInfo user){......return new Response();
}当然这只是一些很小的一个例子还有很多类似的例子需要大家开发过程中多点思考的哈。 | 接口实现过程中注意大文件、大事务、大对象
如下 读取大文件时不要 Files.readAllBytes 直接读取到内存这样会 OOM 的建议使用 BufferedReader 一行一行来。 大事务可能导致死锁、回滚时间长、主从延迟等问题开发中尽量避免大事务。 注意一些大对象的使用因为大对象是直接进入老年代的可能会触发 fullGC。 | 你的接口需要考虑限流
如果你的系统每秒扛住的请求是 1000如果一秒钟来了十万请求呢换个角度就是说高并发的时候流量洪峰来了超过系统的承载能力怎么办呢 如果不采取措施所有的请求打过来系统 CPU、内存、Load 负载飚的很高最后请求处理不过来所有的请求无法正常响应。 针对这种场景我们可以采用限流方案。就是为了保护系统多余的请求直接丢弃。 限流定义在计算机网络中限流就是控制网络接口发送或接收请求的速率它可防止 DoS 攻击和限制 Web 爬虫。 限流也称流量控制。是指系统在面临高并发或者大流量请求的情况下限制新的请求对系统的访问从而保证系统的稳定性。 可以使用 Guava 的 RateLimiter 单机版限流也可以使用 Redis 分布式限流还可以使用阿里开源组件 sentinel 限流。 | 代码实现时注意运行时异常比如空指针、下标越界等
日常开发中我们需要采取措施规避数组边界溢出被零整除空指针等运行时错误。 类似代码比较常见
String name list.get(1).getName(); //list可能越界因为不一定有2个元素哈应该采取措施预防一下数组边界溢出。正例如下
if(CollectionsUtil.isNotEmpty(list) list.size()1){String name list.get(1).getName();
}| 保证接口安全性
如果你的 API 接口是对外提供的需要保证接口的安全性。保证接口的安全性有 token 机制和接口签名。 token 机制身份验证方案还比较简单的就是 客户端发起请求申请获取 token。 服务端生成全局唯一的 token保存到 redis 中一般会设置一个过期时间然后返回给客户端。 客户端带着 token发起请求。 服务端去 redis 确认 token 是否存在一般用 redis.del(token) 的方式如果存在会删除成功即处理业务逻辑如果删除失败不处理业务逻辑直接返回结果。 接口签名的方式就是把接口请求相关信息请求报文包括请求时间戳、版本号、appid 等客户端私钥加签然后服务端用公钥验签验证通过才认为是合法的、没有被篡改过的请求。 除了加签验签和 token 机制接口报文一般是要加密的。当然用 https 协议是会对报文加密的。如果是我们服务层的话如何加解密呢 可以参考 HTTPS 的原理就是服务端把公钥给客户端然后客户端生成对称密钥接着客户端用服务端的公钥加密对称密钥再发到服务端服务端用自己的私钥解密得到客户端的对称密钥。 这时候就可以愉快传输报文啦客户端用对称密钥加密请求报文服务端用对应的对称密钥解密报文。 有时候接口的安全性还包括手机号、身份证等信息的脱敏。就是说用户的隐私数据不能随便暴露。 | 分布式事务如何保证
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 简单来说分布式事务指的就是分布式系统中的事务它的存在就是为了保证不同数据库节点的数据一致性。 分布式事务的几种解决方案 2PC二阶段提交方案、3PC TCCTry、Confirm、Cancel 本地消息表 最大努力通知 seata | 事务失效的一些经典场景
我们的接口开发过程中经常需要使用到事务。 所以需要避开事务失效的一些经典场景 方法的访问权限必须是 public其他 private 等权限事务失效 方法被定义成了 final 的这样会导致事务失效。 在同一个类中的方法直接内部调用会导致事务失效。 一个方法如果没交给 spring 管理就不会生成 spring 事务。 多线程调用两个方法不在同一个线程中获取到的数据库连接不一样的。 表的存储引擎不支持事务 如果自己 try...catch 误吞了异常事务失效。 错误的传播特性 | 掌握常用的设计模式
把代码写好还是需要熟练常用的设计模式比如策略模式、工厂模式、模板方法模式、观察者模式等等。 设计模式是代码设计经验的总结。使用设计模式可以可重用代码、让代码更容易被他人理解、保证代码可靠性。 | 写代码时考虑线性安全问题
在高并发情况下HashMap 可能会出现死循环。因为它是非线性安全的可以考虑使用 ConcurrentHashMap。 所以这个也尽量养成习惯不要上来反手就是一个 new HashMap(); Hashmap、Arraylist、LinkedList、TreeMap等都是线性不安全的 Vector、Hashtable、ConcurrentHashMap等都是线性安全的 | 接口定义清晰易懂命名规范
我们写代码不仅仅是为了实现当前的功能也要有利于后面的维护。说到维护代码不仅仅是写给自己看的也是给别人看的。所以接口定义要清晰易懂命名规范。 | 接口的版本控制
接口要做好版本控制。就是说请求基础报文应该包含 version 接口版本号字段方便未来做接口兼容。其实这个点也算接口扩展性的一个体现点吧。 比如客户端 APP 某个功能优化了新老版本会共存这时候我们的 version 版本号就派上用场了对 version 做升级做好版本控制。 | 注意代码规范问题
注意一些常见的代码坏味道 大量重复代码抽共用方法设计模式 方法参数过多可封装成一个 DTO 对象 方法过长抽小函数 判断条件太多优化 if...else 不处理没用的代码 不注重代码格式 避免过度设计 | 保证接口正确性其实就是保证更少的 bug
保证接口的正确性换个角度讲就是保证更少的 bug甚至是没有 bug。所以接口开发完后一般需要开发自测一下。 然后的话接口的正确还体现在多线程并发的时候保证数据的正确性,等等。比如你做一笔转账交易扣减余额的时候可以通过 CAS 乐观锁的方式保证余额扣减正确吧。 如果你是实现秒杀接口得防止超卖问题吧。你可以使用 Redis 分布式锁防止超卖问题。 | 学会沟通跟前端沟通跟产品沟通
我把这一点放到最后学会沟通是非常非常重要的。比如你开发定义接口时一定不能上来就自己埋头把接口定义完了需要跟客户端先对齐接口。 遇到一些难点时跟技术 leader 对齐方案。实现需求的过程中有什么问题及时跟产品沟通。总之就是开发接口过程中一定要沟通好~
