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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
万里侯25 分钟前
Ansible自动化运维实战:从入门到生产级应用
微服务·容器·k8s
MY_TEUCK1 小时前
【Java 后端 | 微服务远程调用实战】Nacos + OpenFeign 从入门到公共模块抽取
java·开发语言·微服务
woniu_buhui_fei1 小时前
单体服务拆分微服务
微服务·架构
海市公约2 小时前
微服务Token认证从登录到鉴权的完整执行链路
微服务·中间件·权限控制·token认证·分布式安全
万里侯2 小时前
Kubernetes网络性能优化:提升集群网络效率
微服务·容器·k8s
万里侯3 小时前
技术人的人际关系:建立良好的职业网络
微服务·容器·k8s
步步为营DotNet3 小时前
解锁.NET 11 新境:ASP.NET Core 10 在微服务安全通信的深化与实践
微服务·asp.net·.net
Sam_Deep_Thinking17 小时前
连锁门店的外卖订单平台对接
java·微服务·架构·系统架构
@PHARAOH1 天前
HOW - 构建一个轻量前后端一体服务
前端·微服务·服务端
白露与泡影1 天前
轻量级微服务发布系统:Traefik + Nomad + Consul
微服务·架构·consul