1.1 为什么要使用消息中间件
对于很多消息中间件的初学者,一个比较困惑的地方在于,为什么要使用消息中间件。本文通过介绍消息中间件的两大特性:异步结构、流量削峰,来对这个问题进行解答。
1 异步解耦
当今微服务架构盛行,从传统的巨石应用拆分为多个微服务。在进行服务化之后,网页或者手机客户端发起的业务请求需要将后端不同的服务进行组合调用来实现业务处理。在《企业IT架构转型》一书中提到,目前淘宝的订单创建流程需要调用超过200个服务,如下图所示:
如果所有业务逻辑均是在一个进程中顺序执行的方式,完成超过200次的远程服务调用,就算所有服务的调用时间都控制在20ms内返回,整个订单的创建时间也会超过4s,这个时间长度对于今天互联网时代的用户来说已经超过了忍耐极限。
显然我们可以想到将交易创建流程进行异步化,对于有严格先后调用的关系的服务保持顺序执行,对于所有能够异步执行的服务都进行异步化处理。进行异步化处理时,将需要发送的消息投递到消息中间件中,再有消息中间件的消费端进行处理。而消息发送方将消息发送到消息中间件中,即可返回,无序等待消费者消费完成。下图展示了淘宝交易流程异步化后的处理示意图:
通过异步化,可以极大的简化了整个交易流程创建的耗时,提升用户的体验。而异步化可能带来的数据不一致问题,则可以通过其他技术手段来保证最终一致,不在本文讲述范畴内。
2 流量削峰
互联网公司通常都会举办很多线上活动,活动开始时会有大量的用户涌入进行访问,例如大家熟悉的双十一秒杀,又或者春节火车票抢购,一趟列车出可以购票时,会有大量的用户同一时间去抢。对于这些场景,业务系统瞬时要承受的压力可能是平时的几十甚至上百倍,超过系统的最大处理能力,如果不能很好的处理这些流量,那么就很有可能会打挂下游数据库,导致业务系统瘫痪,不能正常提供服务。
此时可以利用消息中间件进行流量削峰,如下图所示:
对于流量洪峰,可以将用户的请求包装成一个消息,投递到消息中间件中,之后异步的进行处理,下游业务系统根据自己多大的处理能力,进行匀速的消费,从而达到削峰填谷到的作用。可以看到,在削峰之前,流量有明显的波峰和波谷,但是在削峰之后,流量可以允许的进行处理。因此流量削峰还有另外一个比较洋气的名字,称之为流量整形。