同步or异步

当前订单服务和商品服务,两个服务之间的通信机制呢,是同步的,订单会调用商品服务的接口,

微服务中除了同步,其实有时候会继承在异步的场景下,通过队列和订阅主题,实现消息的发布和订阅,

一个微服务可以是消息的发布者,把消息通过异步的方式,发送到队列和订阅主题下,作为消费者的微服务,

可以从队列或者主题中,获取消息,通过消息中间件,把服务之间的消息直接解耦,比如类似我们这个业务中

用户服务在用户登录的时候,可能要给用户发短信,那么你需要调用短信服务,可能后面会给用户发积分,

要调用积分服务,那可能还会调用其他的服务了,如果都采用积分的机制,服务间耦合过大,用户需要向多个

服务响应后,响应成功,就会造成不好的用户体验,这个时候我们可以通过消息队列,就能很好的解决问题

再比如我们之前实现了订单服务和商品服务,订单服务在库存前呢,会调用商品服务的查询,

商品信息的接口,之后再调用减库存的接口,来减库存,如果我们对其改造,商品服务在更改库存的

时候,发布消息,发送一个库存变化的消息,订单服务来订阅这个消息,可以获取到商品的部分信息,

比如可购买的商品个数,商品ID,这里并不是全量的商品数据,那在下单的时候,订单服务就不需要再同步的

去查询商品服务,商品的库存信息,而是直接查询服务中的数据,然后在扣库存的时候,订单服务需要发送一个扣

库存的消息,商品服务要订阅这个消息,拿到消息后,减少商品的库存量,支付成功或者失败也会对库存造成影响吧,

这个就要看你业务怎么设计了,比如你支付30分钟之后,由支付服务发布消息,商品同时订阅消息,就能够保证数据的

最终一致性,这样的好处是显而易见的,大家可以想一下,比如用户购买了商品后,业务上还要给这个用户加积分,发短信,

我订单服务是不是不需要修改了,短信服务和积分服务,只要你订阅了消息的话,就可以搞定这种功能的增加,可以说通过

消息机制,服务间的交互变得更加灵活,当然真实在微服务改造中,某个调用你可能一开始,并不觉得是异步消息的场景,

也许当时同步调用更合适,这个并没有关系,当你意识到他适合改成异步的时候,我们积极动手就好了,我就以商品服务和

订单服务为例,来如何将同步调用改成异步消息

现在市面上比较常见的消息队列,我感觉是这几种,RabbitMQ,Kafka,ActiveMQ,统一配置中心也会用到MQ