解耦

项目中为什么需要解耦?

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

如何解耦

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

异步

为什么需要异步

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

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

如何异步

就像上面讲的为什么需要异步一样,我理解的异步主要是一些非核心的流程可以进行异步话,比如一个系统的注册方法,注册的时候,发短信通知,发邮件通知,也可能会发一些优惠券,那么就可以异步的处理这些操作,尤其是发短信,发邮件,如果是同步的,可能会因为短信服务,邮件服务出现问题导致注册失败,这些本来是锦上添花的操作却影响了主流程,如果使用异步处理,不仅缩短了相应时间,即使他们短暂的出现问题,也不会影响主流程,所以很多情况下,使用mq进行异步的处理还是非常有必要的
下面是一般的做法,不仅发邮件和短信有可能影响主流程,也增加了主流程的相应时间
传统的做法
改造过之后的,接口的相应时间也会缩短
改造后的流程图
这里需要注意的是,需要考虑消息丢失造成的影响,也就是说不管什么原因,造成邮件服务和短信服务没有接收到消息,一般的做法是通过其他的分布式定时任务来定时的扫描,超过一定时间没有进行异步处理操作,如果在一定时间里没有处理发邮件和发短信,那么通过定时任务及时弥补,做到万无一失

削峰

为什么要削峰

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

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

如何削峰

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

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐