多研究些架构,少谈些框架(3)-- 微服务和事件驱动

号外: 最近整理了之前编写的一系列内容做成了PDF,关注我的公众号"程序猿DD"来领取吧!

上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。

事务一致性

事务一致性的问题在Monolithic下面不是大问题,在微服务下面却是很致命,我们回顾一下所谓的ACID原则

  • Atomicity - 原子性,改变数据状态要么是一起完成,要么一起失败
  • Consistency - 一致性,数据的状态是完整一致的
  • Isolation - 隔离线,即使有并发事务,互相之间也不影响
  • Durability - 持久性, 一旦事务提交,不可撤销

在单体服务和关系型数据库的时候,我们很容易通过数据库的特性去完成ACID。但是一旦你按照DDD拆分聚合根-微服务架构,他们的数据库就已经分离开了,你就要独立面对分布式事务,要在自己的代码里面满足ACID。
对于分布式事务,大家一般会想到以前的JTA标准,2PC两段式提交。我记得当年在Dubbo群里面,基本每周都会有人询问Dubbo啥时候支撑分布式事务。实际上根据分布式系统中CAP原则,当P(分区容忍)发生的时候,强行追求C(一致性),会导致(A)可用性、吞吐量下降,此时我们一般用最终一致性来保证我们系统的AP能力。当然不是说放弃C,而是在一般情况下CAP都能保证,在发生分区的情况下,我们可以通过最终一致性来保证数据一致。

例:
在电商业务的下订单冻结库存场景。需要根据库存情况确定订单是否成交。
假设你已经采用了分布式系统,这里订单模块和库存模块是两个服务,分别拥有自己的存储(关系型数据库),

diff

在一个数据库的时候,一个事务就能搞定两张表的修改,但是微服务中,就没法这么做了。
在DDD理念中,一次事务只能改变一个聚合内部的状态,如果多个聚合之间需要状态一致,那么就要通过最终一致性(也是这个原因,我们认为一个聚合是一个微服务)。订单和库存明显是分属于两个不同的限界上下文的聚合,这里需要实现最终一致性,就需要使用事件驱动的架构。

事件驱动实现最终一致性

事件驱动架构在领域对象之间通过异步的消息来同步状态,有些消息也可以同时发布给多个服务,在消息引起了一个服务的同步后可能会引起另外消息,事件会扩散开。严格意义上的事件驱动是没有同步调用的。

例子:
在订单服务新增订单后,订单的状态是“已开启”,然后发布一个Order Created事件到消息队列上

PlaceOrder

库存服务在接收到Order Created 事件后,将库存表格中的某sku减掉可销售库存,增加订单占用库存,然后再发送一个Inventory Locked事件给消息队列

InventoryLocked

订单服务接收到Inventory Locked事件,将订单的状态改为“已确认”

OrderChange

有人问,如果库存不足,锁定不成功怎么办? 简单,库存服务发送一个Lock Fail事件, 订单服务接收后,把订单置为“已取消”。

好消息,我们可以不用锁!事件驱动有个很大的优势就是取消了并发,所有请求都是排队进来,这对我们实施充血模型有很大帮助,我们可以不需要自己来管理内存中的锁了。取消锁,队列处理效率很高,事件驱动可以用在高并发场景下,比如抢购。

是的,用户体验有改变,用了这个事件驱动,用户的体验有可能会有改变,比如原来同步架构的时候没有库存,就马上告诉你条件不满足无法下单,不会生成订单;但是改了事件机制,订单是立即生成的,很可能过了一会系统通知你订单被取消掉。 就像抢购“小米手机”一样,几十万人在排队,排了很久告诉你没货了,明天再来吧。如果希望用户立即得到结果,可以在前端想办法,在BFF(Backend For Frontend)使用CountDownLatch这样的锁把后端的异步转成前端同步,当然这样BFF消耗比较大。

没办法,产品经理不接受,产品经理说用户的体验必须是没有库存就不会生成订单,这个方案会不断的生成取消的订单,他不能接受,怎么办?那就把订单服务和库存服务合在一起吧,一个服务两个聚合根。我并不是一个理想主义者,解决当前的问题是我首先要考虑的,我们设计微服务的目的是本想是解决业务并发量。而现在面临的却是用户体验的问题,所以架构设计也是需要妥协的:( 但是至少分析完了,我知道我妥协在什么地方,为什么妥协,未来还有可能改变。

多个领域多表Join查询

  • 我个人认为聚合根这样的模式对修改状态是特别合适,但是对搜索数据的确是不方便,比如筛选出一批符合条件的订单这样的需求,本身聚合根对象不能承担批量的查询任务,因为这不是他的职责。那就必须依