消息队列在企业中的应用

消息服务，是企业级服务体系中比较重要的一个组件，它必须具有低延时、高可靠、可扩展等特性，为业务提供基础建设。
应用消息服务的目的在于：异步、削峰填谷、解耦应用。
最常用的MQ类型有：kafka、rocketmq、activemq、rabbitmq、zeromq。

异步

在企业服务架构中，自顶向下，调用一个产品或者接口，需要经过多层服务调用，有些服务的耗时长会使得整个应用都被拖慢，因此，我们可以把耗时操作异步化。

比如短信系统，统计发送列表并创建发送任务，在统计的这个功能上耗时会比较长，所以我们可以设计一个任务机集群，消费消息队列提供的统计参数，然后将任务记录到数据库中，再由另一个流程查询结果。

短信系统.png

再比如，申请签署文件这个业务，前端发起签署后生成签署文件并展示给客户签署，在文档生成这一块就比较耗时，所以我们采用了向签署系统发送关键参数到消息队列，并且流程异步化的操作，在页面上降低客户对实时的预期，流程上采用异步业务的方式。

签署系统.png

还有，对于数据收集的应用，我们也采用了消息队列对关键数据收集的功能，将业务产生的关键参数发送到消息队列中，然后由收集线程统一收集入库，这样对业务来说既不占用业务的延时也能进行故障隔离，倘若消息队列出来问题，我们的业务也不至于收到中断的影响，因为采用了线程池解耦了业务流程。

数据收集.png

削峰填谷

另一个应用场景，就是对大量的写操作进行cache的一种思想。互联网项目中很多都是读请求，但秒杀这种场景就会有很多写请求。秒杀场景下，比如100件商品是理论上只会update100次，但是如果商品热度很高，就会有瞬间执行update大大超过100次的情况，所以我们的方案是不能从页面上直接透到数据库的。
采用消息队列缓存秒杀请求，也是一种方案。

削峰填谷.png

这样消费服务以恒定的速率处理到数据库中，就不会因为瞬时大流量而导致数据库挂了，在这个时候消息队列的可靠性就凸显了，不能因为几十万的消息崩溃，也不能丢失太多的消息。

服务解耦

服务解耦的作用，和异步有点类似，只不过异步是对于流程上的视角而言，服务解耦则是服务视角上的。
比如短信系统，原本一体化的应用是短信和统计在一起的，进行微服务拆分之后，就会使用消息队列作为交互，把一些rpc调用的场景直接设计为服务间通过消息消费的方式，就可以不在服务中大量写入调用代码。
我们在一个身份校验系统中采用过，一个身份校验系统有一个流程id，每次这个流程id完成身份校验之后，就会在消息队列中一个virtual topic中广播一条消息。需要订阅的系统，只需要消费这个virtual topic就好了，不需要再对接系统的结果查询之类的接口，这样就可以做到服务的解耦了。