消息中间件RabbitMQ、微服务，以及数据一致性问题
万里山川2020-11-17 12:00
大家好，我是技术人小Top
今天咱们来介绍RabbitMQ在微服务下的使用 ^-^
RabbitMQ官网：www.rabbitmq.com为什么要说说RabbitMQ与微服务呢？
上一次说到RabbitMQ作为一款消息中间件解决了特定场景下的问题，这些都是RabbitMQ的特性。
但消息中间件的出现，其实还有一个真实的背景，那就是原先单一应用就能独立完成的业务（或需求）现在不得不需要多个应用共同协作才能完成。
还记得上次的图吗？
原先单一应用能满足的，为什么后来就不能了呢？
1、外部环境变化越来越快，业务需要不断适应外部变化
2、当业务需求变得越来越复杂，单一应用就变得越来越庞大
3、当单一应用变得庞大后，相继开发和运维越来越难以维计
4、随着业务复杂度和访问量增加，单一应用无法满足高并发、高可用、高扩展性
由此，单一应用就必须拆分为多个应用，采用多应用共同分担的办法来解决上述问题。
01微服务的由来
说到这里，小伙伴们一定猜到了拆分应用就是今天要说到的微服务。
微服务并不是一个全新的概念，早期对单一应用的拆分和现在我们说到的微服务拆分，其实在本质上没有差别。整个的拆分理念都是将大的应用拆分为粒度更小的单元。整体目标都是力求让每个拆分单元的复杂度保持在合理范围，以保证高并发、高可用、高扩展性。
随着时间的推移和技术的发展，以及互联网时代的到来，用户量越来越大，早期对应用的拆分已满足不了快速变化的需求。
这时要求拆分单元的粒度更小，因此现在的拆分粒度与早期拆分的粒度出现了不同。
拆分越来越趋于服务化：
1、从业务视角来看，拆分粒度越来越趋于完成某个单一业务场景
2、而这个业务场景从外部用户视角来看，它不能独立完成一个完整的业务流程，它已经不能称之为一个独立的应用了
3、最终拆分结果是，一个完整的业务流程需要跨多个最终的拆分单元，即多个拆分单元共同协作才能实现业务流程闭环
相信小伙伴们经常会网上购物，我们就以线上购物为例
它可能要跨越购物服务、订单服务、库存服务、支付服务、积分服务、会员服务等等。每一个拆分单元就像是在一个流水线上提供服务的服务者，每个服务者对外提供自己的服务。
多服务间消息传递看了上面的这张图相信小伙伴们对微服务有了一定的认识和了解了
微服务势在必行，但接下来面临的一个问题也就随之出现了
当一个业务流程跨越了多个微服务，服务间的数据如何保证一致性呢？
02数据一致性与RabbitMQ
我们还是以线上购物为例：
很熟悉的网购下单页面 ^-^
1、订单服务，需要创建订单
2、库存服务，需要扣减库存
3、支付服务，需要完成支付
4、积分服务，需要生成积分
... ...
针对这笔订单，对于用户来说只有上述服务中的所有功能全部执行成功，下单才算是真正完成了。
而现实中这么多微服务间的数据传递，如果没有一个完善的保障机制，很难确保万无一失。
这个保障机制其实不难想到：
1、消息不能丢失
这是所有保障的基础。只要消息还在，其他问题都会有办法解决
RabbitMQ提供了消息持久化功能来支持
2、每一步都要确认
这是及时发现问题的关键。及早发现问题，影响范围控制在最小
RabbitMQ提供了发布确认、消息回发、接收确认功能来支持
3、执行结果要进行检查
这是最后的把关。只要有这个最后屏障，所有问题都会被发现
这需要业务服务间自己完成对账，RabbitMQ不参与业务逻辑，爱莫能助哦 ^-^
4、消息丢失要补救
这是数据一致的最后一步，完成数据最终一致
发送方需要利用RabbitMQ完成补偿发送
橙色部分是RabbitMQ支持的，红色部分是需要服务间定制化开发的
好在有像RabbitMQ这样的消息中间件来辅助业务实现 ^_^
03小结
今天主要介绍了两个知识点
1、微服务的由来
2、数据一致性与RabbitMQ
小伙伴们都了解了吗？
下次小Top将介绍RabbitMQ开发
对于今天的内容有任何疑问或问题，欢迎留言或讨论 ^-^
举报/反馈
0
0
收藏
分享
