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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
安当加密15 小时前
AES-256直接加密就够了?微服务架构下的敏感数据加密:信封加密、格式保留加密和字段级加密全解析
微服务·云原生·架构
您^_^15 小时前
专家(一):Claude Code 微服务实战——6 个服务从拆分到 K8s 部署,$0.45 全套 YAML 照抄
人工智能·windows·微服务·架构·kubernetes·个人开发·claude code
xingfujie18 小时前
第2章:服务器规划与基础环境配置
linux·运维·微服务·云原生·容器·kubernetes·负载均衡
xingfujie19 小时前
前言:从零到一,系统掌握 K8s + DevOps + 微服务
linux·运维·微服务·云原生·容器·kubernetes·devops
珠海西格电力1 天前
零碳园区的能源供给成本主要包括哪些方面?
大数据·分布式·微服务·架构·能源
Sunnyingx2 天前
从微服务到多智能体:架构演进的连续性思考
微服务·系统架构·aigc
總鑽風2 天前
单点登录sso 微服务加网关gateway
java·微服务·gateway·jwt·单点登录
Ting-yu3 天前
SpringCloud快速入门(3)---- 创建微服务项目
java·spring cloud·微服务
covco3 天前
全域矩阵运营系统多租户权限体系架构设计与轻量化落地实践
微服务·矩阵·权限管控
2501_912784083 天前
告别“汗水出海”:基于微服务架构的跨境电商系统设计与实现——以Taocarts为例
微服务·云原生·架构·taocarts