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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
星期一研究室11 小时前
从“能看”到“爱看”:用色彩心理学打造人人爱看的的专业文档🧩
微服务·产品·设计
重庆小透明12 小时前
深入探寻微服务【第三篇微服务的组件】
运维·微服务·架构
过客随尘1 天前
网关扩容了,流量却还是打不过去?企业级 Spring Cloud Gateway 生产动态化部署实战
spring cloud·微服务·架构
cfm_29141 天前
基于OAuth2.0实现微服务SSO单点登录
后端·spring·微服务·架构
星期一研究室1 天前
飞书文档行文重点强调:五大招式,让你的信息“亮”起来!
微服务·产品·设计
星期一研究室2 天前
飞书文档层级标题的“潜规则”,让你的信息流精致呈现
微服务·产品·设计
重庆小透明3 天前
深入探寻微服务【第一篇微服务的坏】
微服务·云原生·架构
驾驭人生3 天前
IIS微服务5分钟自动预热守护服务
微服务·云原生·架构
VortMall3 天前
VortMall 微服务商城 v1.3.13 版本更新|『会员 + 分销』功能优化,提升私域裂变经营能力
微服务·云原生·架构
星期一研究室3 天前
高颜值飞书封面、审美网站推荐、配色网站安利
微服务·产品·设计