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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
EatFan14 小时前
gRPC 为什么比 HTTP+JSON 快?详细讲解gRPC
后端·微服务·grpc
辛迪聊物业数字化1 天前
智慧物业管理平台架构实践:从SaaS物业云到商管系统的全模块落地
大数据·微服务·php
叶总没有会2 天前
Nacos—注册中心
spring cloud·微服务
天天喝旺仔2 天前
分布式服务容错实战:用 Sentinel 实现限流、熔断与降级
分布式·微服务·云原生·sentinel
周先生FullStack3 天前
Mac + 容器本地 MySQL/Redis 环境搭建与网络原理实战
java·spring boot·微服务·容器·架构·个人开发
叶总没有会3 天前
微服务--分布式基础
java·spring·spring cloud·微服务
weixin_435247063 天前
微服务开发规范模版
微服务·云原生
智慧物业老杨3 天前
物业数字化落地思考:真正的转型,是底层数据秩序的重构
java·大数据·人工智能·微服务·系统架构
VortMall3 天前
VortMall微服务商城系统 v1.3.20 正式发布:分销客户管理与后台安全双升级
微服务·商城系统·开源商城系统
骇客野人4 天前
Java 前后端可部署落地架构方案
服务器·前端·微服务