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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
熊出没18 小时前
高并发下的图片上传问题处理
微服务·架构
serendipity_hky1 天前
【SpringCloud | 第4篇】Gateway网关统一入口
spring·spring cloud·微服务·gateway
Coder_Boy_1 天前
业务导向型技术日志首日记录(业务中使用的技术栈)
java·驱动开发·微服务
测试人社区-小明1 天前
智能测试误报问题的深度解析与应对策略
人工智能·opencv·线性代数·微服务·矩阵·架构·数据挖掘
Tadas-Gao1 天前
GraphQL:下一代API架构的设计哲学与实践创新
java·分布式·后端·微服务·架构·graphql
小安同学iter2 天前
天机学堂-优惠券功能-day09(七)
java·spring cloud·微服务·jenkins·优惠券·天机学堂
眠りたいです2 天前
基于脚手架微服务的视频点播系统-服务端开发部分(补充)文件子服务问题修正
c++·微服务·云原生·架构
是垚不是土2 天前
基于Blackbox Exporter的网络服务黑盒监控体系实践
网络·数据库·安全·http·微服务·prometheus
Haooog2 天前
微服务篇面试题(不定时更新)
微服务·面试·架构
2501_924064112 天前
2025年微服务全链路性能瓶颈分析平台对比与最佳实践
微服务·云原生·性能优化·架构