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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
折哥的程序人生 · 物流技术专研8 小时前
Java面试通关⑭:分布式理论与架构全集
分布式·微服务·校招·分布式事务·cap·java面试·最终一致性
想你依然心痛1 天前
AtomCode在后端开发中的实战体验:Go微服务从零搭建
开发语言·微服务·golang
nbsaas-boot1 天前
微服务架构下的分布式事务解决方案深度对比与实战选型
分布式·微服务·架构
小二·2 天前
Docker+K8s生产级部署实战:从0到1打造高可用微服务集群
docker·微服务·kubernetes
fanly116 天前
Surging AI Agent 完整产品介绍
微服务·microservice
蝎子莱莱爱打怪12 天前
XZLL-IM干货系列 04|Netty 长连接实战:Pipeline 怎么排、心跳怎么跳、连接怎么管
后端·微服务·面试
SamDeepThinking13 天前
Java微服务练习方式
java·后端·微服务
米丘16 天前
微前端之 Web Components 完全指南
微服务·html
霸道流氓气质19 天前
领域驱动设计(DDD)在 Spring Boot 微服务中的实践指南
运维·spring boot·微服务
霸道流氓气质19 天前
Spring Boot 微服务性能优化完全指南
spring boot·微服务·性能优化