当年阿里新零售业务中为何在商品发布阶段引入了削峰策略？

hello 慕课网的各位同学们，大家好，我是姚半仙，慕课网《Java架构师成长直通车》课程架构师讲师团成员之一。这一节课,快来搬个小板凳坐好，听老师讲故事,这个故事就是当年阿里新零售业务中为何在商品发布阶段引入了削峰策略，故事的开头是这样的：

这是什么意思呢？有一天，运营总监找到我，开口就说:“爸爸，我有个事求你啊”(不好意思，前面是我歪歪的)。运营总监找到我说：“本座唤你来做个新需求，一键发布所有商品到新店”。我就弱弱的问，所有商品是多少个啊？运营总监发话了，其实吧，也没有那么多，大概小几十万吧。话音刚落，这个总监就使出了一击必杀的大招，这个大招的名字就叫一键开店。

它有什么功能啊？就是瞬间打出五万以上的QPS，秒杀所有商品的服务。这个一键开店的技能是一个需要持续施法的技能。它一旦开始吟唱 ，大概会在十秒钟不到的时间打出小几十万的商品，那对应到商品服务的集群来说，大概就是每秒五万家的QPS。以当时我们的服务集群机器数量是远远承载不够的，那运营总监这一招厉害啊，估计还没有吟唱完，这个所有商品服务全部都团灭了。

咱不光说商品服务要团灭啊，一个商品发布，它调用的远远不止商品服务这一个服务，它还会调用后续的订单服务，库存服务，总之，很多下游微服都会受到这个影响。眼看服务血崩就要发生了，那么接下来我们怎么办呢？那就是必须要引入消息组件来做流量削峰。

所谓兵来将挡，水来土淹，一物降一物。那这个东西就是完克运营总监技能的法宝啊。我们看看消息组件的技能说明都有哪些啊？第一个是平滑输出。我们采用客户端主动拉取的方式，它并不是主动的往里嘴里硬塞东西，而是客户端根据自己的处理能力主动去拉取，有多大本事就干多大的事。第二个特点是不怕Timeout,咱如果在短时间内像刚才的商品发布一样，十秒钟内发布五十万个商品，如果你接口响应超时了，那你还要设置很多的容错策略来补偿，保证最终一致性，那你这个业务场景就被API超时给限制住了，而消息组件需要担心这个问题吗？完全不用担心啊， 你的所有请求都被存放在消息组建这里了，什么时候有资源，那什么时候就会有客户端来主动拉取去做，完全没有基于API调用的超时烦恼。那最重要的当然还是依靠消息组建的高吞吐量特性，你五十万个请求，如果全部落在我们的业务服务器上，这个造成的伤害很大，但是如果你落在中间件消息组建的集群上你这个真的就是毛毛雨了，要不怎么说能担当中间件的大任呢。咱但凡提到中间件，一般来说，吞吐量都是相当优秀的。那我们有了消息组件这件神装的加持，看看如何来抵挡运营总监的淫威啊？

总监这时又开始吟唱起了一键开店的技能，那抵达了商品中心，接下来我们就寄出了消息，组建这件神装啊。商品中心把一键开店所对应的所有商品，一股脑的发送给了消息中间件，那商品发布消息抵达到消息中间件以后呢，我们每一个下游应用都会去监听这个消息队列。比如我们的商品服务监听到这个消息开始发布淘系商品，那销售单服务发布一些销售计划等等， 库存服务呢，就是去初始化库存，发布每日库存所有的下游服务全部井然有序的运作着。运营总监这一个大招砸下来啊，就被咱的消息组件完美化解了，对我们的服务没有造成任何一点伤害，此刻我心中不由燃起了对从事技术工作的这种优越感，对运营总监、产品经理这些技术小白啊，只有他们想不到的问题， 没有技术人员解决不了的问题，程序员的超能力他们不懂。

言归正传，本小节到此结束，在课程中的下一小节里，我将带大家探秘Stream Binder作用机制，那同学们，我们下一小节再见。