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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)。
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
wangjialelele21 小时前
一文梳理 Spring Cloud 核心组件:Eureka、Nacos、OpenFeign、LoadBalancer 与 Gateway
java·spring boot·spring·spring cloud·微服务·nacos
草莓熊Lotso1 天前
【C++ 基于微服务的即时通讯系统】Elasticsearch 从安装到 C++ 客户端二次封装全落地
linux·网络·数据库·c++·elasticsearch·微服务
银河技术1 天前
从脚本到 Operator:用 Go 构建可靠的微服务自动扩缩容控制器
开发语言·微服务·golang
草莓熊Lotso1 天前
【C++ 基于微服务的即时通讯系统】etcd + brpc 从安装到服务注册发现全链路实战
网络·数据库·c++·redis·微服务·etcd
我不会起名字3222 天前
微服务链路超时怎么设:逐层收敛的 4 条规则与 1 个反例
微服务·go·超时·熔断
Wang's Blog2 天前
Java 项目实战: 交友项目 - 章节复盘:微服务骨架与手机号验证码登录
java·微服务·交友
我不会起名字3222 天前
负载均衡选错:轮询在长连接下的偏斜问题
微服务·负载均衡·grpc·长连接
code_slave(码畜)3 天前
微服务架构落地:OpenFeign 服务远程调用 + 线程池隔离架构实战 —— 超时控制、重试机制、线程池隔离,防雪崩
spring boot·spring cloud·微服务·云原生·架构·openfeign
涵美女程序猿3 天前
ChatCut online 剪微服务熔断测试录屏:仪表盘告警、降级日志与恢复时刻怎样对应
程序人生·微服务·云原生·架构·电脑
hhb_6183 天前
智联AI办公微服务技术全解析
人工智能·微服务·架构