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

能批量就不要并发。

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

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

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

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

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

有三种方法:

  • 改变方法名,比如getDataListWithLimitLength(List<Integer> idList)
  • 在接口说明文档中增加必要的注释说明。
  • 接口明确抛出超长异常,直白告知主调。
相关推荐
云司科技codebuddy2 小时前
技术支持过硬Trae核心代理
大数据·运维·python·微服务
递归尽头是星辰3 小时前
微服务事务分级治理:从 Seata 全模式到 TDSQL 实战
微服务·云原生·架构·分布式事务·事务分级治理
没有bug.的程序员3 小时前
订单系统重构史诗:从单体巨兽到微服务矩阵的演进、数据一致性内核与分布式事务
java·微服务·矩阵·重构·分布式事务·数据一致性·订单系统
江西理工大学小杨3 小时前
高性能 C++ 社交平台4:基于 Boost.Beast 的 WebSocket 网关实现
c++·websocket·微服务
麦聪聊数据4 小时前
数据流通的最后一公里:SQL2API 在企业数据市场中的履约架构实践
数据库·sql·低代码·微服务·架构
知识即是力量ol20 小时前
微服务架构:从入门到进阶完全指南
java·spring cloud·微服务·nacos·架构·gateway·feign
江西理工大学小杨1 天前
高性能 C++ 社交平台1:微服务架构设计
开发语言·c++·微服务
J_liaty1 天前
Spring Cloud 微服务面试高频题
spring cloud·微服务·面试
笨蛋不要掉眼泪1 天前
Spring Cloud Gateway 核心篇:深入解析过滤器(Filter)机制与实战
java·服务器·网络·后端·微服务·gateway
笨蛋不要掉眼泪1 天前
Spring Cloud Gateway 扩展:全局跨域配置
java·分布式·微服务·架构·gateway