解耦

项目中为什么需要解耦？

讲一个真实的项目案例，项目是一个根据国际黄金行情进行实时交易的系统，分了两个微服务，一个是纸黄金实时交易系统，一个是实物黄金交易系统，两个系统都需要接收实时黄金行情数据，得到用户的交易价格，并且都有一个需求，能人工控制开市和闭市，也就是什么时候可以交易，什么不可以交易，那么这个时候就需要在后台管理系统进行控制，如果没有解耦，那么后台管理系统就需要直接通过dubbo调用纸黄金交易系统和实物黄金交易系统接口，告诉两个系统要开市还是要闭市，这样做的问题在于，如果因为公司业务的拓展，如果又增加一个其他的系统（例如实物白银交易系统），那我们怎么办，我们只能修改后台管理系统的代码，再调用实物白银交易系统的接口，告诉它开闭市，那么要是再多一个呢，中间又因为某一些原因，减少了一个系统呢，维护后台管理系统的同学可能要崩溃了，需要不停的修改代码，这就是没有解耦的极端的情况,无论是增加微服务还是减少都比较麻烦，系统越多越不好控制，越难维护，那我们怎么办？就是通过mq来进行解耦，下面是没有使用mq时的场景

如何解耦

那么如何解耦？在后台管理系统和其他系统之间增加一层mq,无论是开市指令还是闭市指令，都直接发送到队列中，然后其他系统需要开闭市操作的就要订阅监听这个队列，这样无论是增加其他的业务系统还是减少业务系统，都不需要修改后台管理系统，负责后台管理系统的同学就轻松多了，其他的系统只要接收到指令进行相应的操作就可以了

异步

为什么需要异步

消息队列的主要特点是异步处理，主要目的是减少请求响应时间，实现非核心流程异步化，提高系统响应性能。

所以典型的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作，作为消息放入消息队列。

如何异步

就像上面讲的为什么需要异步一样，我理解的异步主要是一些非核心的流程可以进行异步话，比如一个系统的注册方法，注册的时候，发短信通知，发邮件通知，也可能会发一些优惠券，那么就可以异步的处理这些操作，尤其是发短信，发邮件，如果是同步的，可能会因为短信服务，邮件服务出现问题导致注册失败，这些本来是锦上添花的操作却影响了主流程，如果使用异步处理，不仅缩短了相应时间，即使他们短暂的出现问题，也不会影响主流程，所以很多情况下，使用mq进行异步的处理还是非常有必要的
下面是一般的做法，不仅发邮件和短信有可能影响主流程，也增加了主流程的相应时间

改造过之后的，接口的相应时间也会缩短

这里需要注意的是，需要考虑消息丢失造成的影响，也就是说不管什么原因，造成邮件服务和短信服务没有接收到消息，一般的做法是通过其他的分布式定时任务来定时的扫描，超过一定时间没有进行异步处理操作，如果在一定时间里没有处理发邮件和发短信，那么通过定时任务及时弥补，做到万无一失

削峰

为什么要削峰

流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

如何削峰

在这里我们增加一个消息队列，这样的话不管你请求来多少，我先存入消息队列，然后我再让系统慢慢的处理你的请求（如右图），这样很好的减缓了数据库的访问压力。
这里需要注意的是这里是一个队列上对应多个消费者，每个消费者每次只消费一条消息，是一个工作队列模式，这样才能有效控制一下子所有的请求都跑到数据库中，下一篇文章，可以更加深入的在研究讨论一下如果做削峰