背景
昨天跟同事聊天，他提了一个问题，我觉得挺有意思，分享给大家。
原话是这样的：我提供了一个批量锁库存的接口，结果那谁传了十万条数据过来，把我弄死了，麻蛋，我就不应该给他提供这个批量的接口，我现在怎么办？（头大）
所以，我们应不应该提供批量的接口呢？
我认为不应该提供。
动机
首先，我们分析一下需要批量的动机。
客户端（调用者）想把数据组装成一个大List批量调用你的接口，肯定是考虑到如果一条一条调用你，中间的网络开销非常大，浪费很多时间，所以，他认为批量调用你的接口，可以把这一部分耗时给节约了，提高他接口的响应速度。
危害
然后，我们再分析一下如果你提供了批量接口，会出现哪些危害呢。
第一点，客户端相当于把他的压力转移到你这里了，整个系统出现问题，谁背锅，无需多言了。
第二点，本来客户端一个请求一个请求来调用你的，你可以部署10台机器来抗并发，结果现在一个请求过来10万数据，全部打到你的一台机器的一个线程中，你怎么处理？多线程？多线程你也是在一台机器里面搞。加消息队列再分发？这无疑大幅度增加了你的设计复杂度。
第三点，现在是10万数据，以后呢？会不会出现100万、1000万来调你？不可控，只要你提供了，别人就可能来搞你。
所以，无论怎么看，你都不应该提供批量接口，只要你提供了，无疑是在作死，而且死的心安理得，因为确实是你的问题，你跟客户端撕逼可能都撕不过。
因此，千万不要提供批量接口。
客户端调用的正确姿势
那么，问题来了，如果不提供批量接口，客户端怎么加快他的处理速度呢？
客户端应该改变思维，不是一个请求一个请求的同步调用你的接口，而应该多个请求异步并发调用你的接口，这样，你这边完全不用修改，只要简单的加机器就可以轻松实现无限扩容。
但是，客户端的代码并没有那么好写，在java中，就是使用Future啦，或者直接使用Completable Future，有兴趣的可以去看看Dubbo的源码，新版本已经全部改成使用CompletableFuture来实现远程调用了，当然，dubbo本身就是支持异步调用的，用起来很简单，但是如果你是feign可能需要自己包一层了。
好了，今天我们这里说的客户端实际上是后端服务之间的调用，不包含前端那种批量导入的场景，就先分享到这里了。
结语
最后，我想问，你们的系统服务之间有没有批量的接口呢？又是怎么处理这种大请求的呢？
欢迎留言讨论。