随着分布式,微服务越来越普遍,对开发的要求也在不断的增加,对架构的要求也提出了越来越多的要求,在那些分布式项目中,经常面临的一个问题就是,高效,解耦,举例来说,当一个小型电商网站越来越大的时候,单体架构必然满足不了日益增长的业务需求,就说当众多的流量一起涌入,你的下单接口怎么能够抗住成千上万的QPS呢?
很显然,需要从架构上不断优化我们的项目结构,使用消息中间件对业务进行合理的拆分,使之模块化,不同的模块通过微服务的方式互相调用,可以说可以在很大程度上解决并发的问题,这里先不展开来讲,限于本人的经验有限,从简单的说起,下面先看一张简单的业务架构图,
这个场景的描述大致是这样,用户浏览某电商网站的某个商品详情页面,这个页面上的信息都是由商品服务这个微服务工程维护的,现在后台管理员需要调整该商品价格,请求修改商品价格的接口,修改完毕,商品服务如何能感知到并且刷新这个商品的最新信息到页面上去呢?
传统的做法可以是,在修改完毕商品价格后,回调一下商品服务的某个接口,通知商品服务去调整价格并获取最新的商品信息。但随着业务的增长这样做就显得有些无能为力了,因为你不能总要求商品管理服务去回调接口那告知你价格发生变化了吧?换句话说,如果修改商品的价格后同时需要通知的服务模块特别多,那就需要回调更多的接口,我们知道,http回调是阻塞的,在一个事务中,如果某个回调不成功将会导致后面的操作都会被阻塞,那么,使用消息队列进行解耦是个不错的选择,
使用消息队列,当价格发生了改