微服务设计原则——高性能:批量

能批量就不要并发。

如果调用方需要调用我们接口多次才能进行一个完整的操作,那么这个接口设计就可能有问题。

比如获取数据的接口,如果仅仅提供getData(int id)接口,那么使用方如果要一次性获取 20 个数据,它就需要循环遍历调用我们接口 20 次,不仅使用方性能很差,也无端增加了我们服务的压力,这时提供一个批量拉取的接口getDataBatch(List<Integer> idList)显然是必要的。

对于批量接口,我们也要注意接口的吞吐能力,避免长时间执行。

还是以获取数据的接口为例:getDataList(List<Integer> idList),假设一个用户一次传 1w 个id进来,那么接口可能需要很长的时间才能处理完,这往往会导致超时,用户怎么调用结果都是超时异常,那怎么办?限制长度,比如限制长度为 100,即每次最多只能传 100 个 id,这样就能避免长时间执行,如果用户传的 id 列表长度超过 100 就报异常。

加了这样限制后,必须要让使用方清晰地知道这个方法有此限制,尽可能地避免用户误用。

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
没有bug.的程序员1 天前
Spring Cloud Gateway 架构与执行流程:从原理到性能优化的深度探索
微服务·云原生·eureka·性能优化·架构·sentinel·服务发现
曼诺尔雷迪亚兹1 天前
微服务启动失败:Nacos 403(unknown user)与配置拉取失败故障双排查
java·运维·微服务
杜子不疼.1 天前
Spring Cloud 微服务实战:Nacos+Sentinel+Gateway 核心组件详解
spring cloud·微服务·sentinel
Roye_ack2 天前
【微服务 Day2】SpringCloud实战开发(微服务拆分步骤 + Nacos注册中心 + OpenFeign + 微服务拆分作业)
java·spring cloud·微服务·nacos·openfeign
杀死那个蝈坦2 天前
短链接生成-基于布隆过滤器和唯一索引
java·数据库·微服务·oracle·rocketmq
叫我阿柒啊2 天前
从Java全栈到前端框架:一场真实的技术面试对话
java·vue.js·spring boot·微服务·typescript·前端开发·后端开发
好奇的菜鸟2 天前
Docker 一键启动:打造高效的 Java 微服务开发环境
java·docker·微服务
鹏北海3 天前
Single-SPA 学习总结
前端·javascript·微服务
没有bug.的程序员3 天前
微服务网关:从“必选项”到“思考题”的深度剖析
java·开发语言·网络·jvm·微服务·云原生·架构