昨天我们讨论了服务间是否应该提供批量接口的问题，很多同学留言讨论，非常好，一起讨论一起进步。
其中，留言最多的一种观点是说可以提供，但是要限制条数，比如每次最多传1000条数据过来。
说句实话，我们的项目很多也是这么做的。
因为随着数据量的不断增大，势必导致存储架构升级。
我们以商品查询为例，数据量变大，肯定是要上Redis的吧，以前批量接口可能直接一个数据库in就解决了，现在你是先走缓存还是不走呢？走的话要改代码，不走的话性能肯定不高。数据量再继续增大，分库分表了，批量接口怎么处理？上Elasticsearch了，怎么处理？
这里，我们举例是说的批量查询，如果换成批量操作呢？每次存储架构升级可能都要改这块的代码，而且还有另外一个操蛋的问题，比如你们规定服务间调用超时最大是1秒钟，超过1秒就有熔断逻辑，那么，你要不要单独为这个批量接口配置超时？
所以，批量接口极其容易形成瓶颈，需要花费巨大的代价去维护这个代码，还是不提供比较好。
当然，如果你们的数据量在可以预见的未来都不会增长到那么大，提供一个批量接口也不是不可以，视情况自行决定哈。（数据量都没有，还不赶紧跑路