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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
听风吟丶5 小时前
微服务分布式事务实战:从数据一致性到故障恢复全方案
分布式·微服务·架构
rolt6 小时前
[漫画]《软件方法》微服务的遮羞布
微服务·ddd·领域驱动设计
蜂蜜黄油呀土豆7 小时前
分布式基础知识:分布式事务完整解析(背景、模式、协议、优缺点)
数据库·微服务·分布式事务·架构设计·分布式系统·2pc/3pc·tcc/saga
云计算小黄同学1 天前
Java 服务从虚拟机迁移到 Kubernetes(K8s)集群
java·微服务·云原生·kubernetes
踏浪无痕1 天前
彻底搞懂微服务 TraceId 传递:ThreadLocal、TTL 与全链路日志追踪实战
后端·微服务·面试
玩具猴_wjh1 天前
GoZero微服务架构
微服务·云原生·架构
杀死那个蝈坦1 天前
微服务-远程调用
微服务·云原生·架构
一个帅气昵称啊1 天前
.Net微服务网关注册和管理(基于Consul + Nginx实现)
微服务·.net·consul
小坏讲微服务1 天前
Spring Cloud Alibaba 微服务整合自定义日志注解完整教程
java·spring cloud·微服务·云原生·架构
拾忆,想起1 天前
Dubbo服务注册与发现深度解析:微服务架构的“通讯录”与“导航系统”
微服务·云原生·性能优化·架构·dubbo·safari