昨天我们讨论了服务间要不要提供批量接口。很多同学留言讨论，很好。让我们共同探讨，共同进步。其中评论最多的意见是可以提供，但是必须限制条目数，比如每次最多传输1000条数据。老实说，我们的很多项目都是这样做的。但我还是坚持我的观点，最好不要提供批量接口。因为随着数据量的不断增加，必然导致存储架构的升级。我们以商品查询为例。如果数据量变大，就必须连接Redis。以前批量接口可能直接一个数据库进去解决，现在先用缓存还是先不用？如果你想去，你需要更改代码。性能肯定不高。数据量不断增加，分库分表。批量接口如何处理？批量接口如何处理？这里，我们以批量查询为例。如果换成批处理呢？每一次存储架构的升级都可能需要更改这块的代码，这他妈的又是一个问题。比如你规定服务间调用的超时时间最多为1秒，1秒后会有熔断逻辑。那么，要不要给这个批处理接口单独配置timeout呢？所以，批处理接口极易形成瓶颈，维护这段代码需要付出巨大的代价，还是不提供为好。当然，如果你的数据量在可预见的未来不会增长到这么大，提供批量接口也不是不可以，你可以根据情况自行决定。（数据量不大，先别急着跑掉😂）好了，昨天的题就说这么多吧。今天我们再来看一个问题：后端如何快速响应前端提供的批处理接口？是如果没有通用解决方案怎么办？首先，让我们分析一下场景。这里说的批量接口肯定不是查询，而是批量操作接口，比如批量导入，批量发货，批量删除，批量转移，批量修改某个状态等等，还有很多，但是对于2C系统来说可能比较少见。一般2B系统这批接口比较多。往往他们在系统中也是顽固不化，需要付出很大的努力才能不断打磨优化。好了，场景我们都知道了，那么这种问题怎么解决呢？一般我们提供一个批处理接口，前端发送一堆id或者data，后端慢慢处理，处理完返回给前端。因为是2B系统，所以用户愿意等待。然而，这里其实存在很多问题。最典型的就是超时问题。超时问题既简单又复杂。以我们的系统为例，我们在华为云上部署的时候，可能会出现几个超时的问题。地方：1、华为云防火墙超时；2、华为云ELB超时；3、前端nginx超时；4、前端代码超时；5、后台网关超时；6、后端服务超时Timeout；7、远程调用有超时时间；所以，你看，一个超时问题可以把你折磨死，而且这种问题很难排查。当然，在这个坑里躺过一次之后，以后可能会好很多。（所以，为什么我知道这么多地方可能有问题😂）超时只是一个典型的问题，不是全部，我说另外一种情况，以批量发货为例，晚上很多商家喜欢批量发货，比如一次1000个req??uest，商家的request那么多，一不小心，很多会发到同一台机器上，然后大家都在做batches，还得去申请很多内存。等等，然后OOM，这是一个典型的请求倾斜问题，那么，你的负载均衡策略怎么设置呢？目前还没有很好的解决办法。基于以上可能出现的问题，我一直在想，能否提供一个通用的解决方案呢？其实是有的，只是原型要改。例如，对于批量发货，原始状态只有未交付、已发货和失败。你能加“运费”吗？别小看这货的威力，真的很厉害。当后台收到批量投递请求时，首先检查数据的正确性，然后将数据库中这些单据的状态修改为投递，然后将数据一个一个的扔进消息队列，然后返回。前端查询显示的时候会显示正在发货中，旁边会放一个刷新按钮。这个时候用户完全在做其他的事情，比如构建一个产品，稍后再回来查看是否交付完成或者失败。最后还有一群消费者，不断从消息队列中消费数据，调用物流服务送货等等。这么一折腾，本来要在前端挂几分钟的请求几秒就返回了。用户体验得到提升，不再需要处理超时、请求倾斜等问题。这释放了生产力，让我们可以花更多的时间。而且，这是一个可以无限水平扩展的架构。随着用户数量的不断增加，理论上只需要堆机器就可以了。好了，前端批处理接口的处理就到这里了。最后想问一下，你们系统中前端的批处理接口是怎么处理的？本文转载自微信公众号“童哥阅读源码”，可通过以下二维码关注。转载本文请联系童哥阅读源码公众号。
