你的SOA已经使用了EDA和CQRS吗?

                   
banq 13-06-08

来自2013年4月底的 IDDD Tour 演讲:你的SOA已经使用了EDA和CQRS吗?(What SOA do you have (with extended EDA and CQRS material)),谈论了DDD + CQRS +EventSourcing等面向领域的新思想和新技术如何对传统架构发展。

下面我简要对这篇长达274页的PPT进行大概翻译并阐述自己观点如下:

现在SOA这么多年实践下来,面临的问题:
1.碎片化
2.开发和维护成本很高
3.服务无法被重用。
4.当你认为SOA是整合利器时,它自身成了问题根源。
5.没有人再愿意开发和维护服务
6.系统性能相当差。

老体系的SOA风格如下:
当一个客户希望买到一件裙子时,产生订单的服务将涉及设计部门 客户部门 财务部门和生产部门等,比如检查生产部门是否有类似原料等,然后才能创建一个订单。如下图,注意图中箭头方向,订单服务是主动地去和多个部门的服务交互,如果其中一个子服务没有准备好,将导致业务堵塞等待。



12
banq
2013-06-08 11:03

上图中传统的SOA还带来可伸缩性Scalable的问题,难以水平扩展,如果是京东 苏宁这种电商,面对尖峰时刻的巨量订单创建,传统SOA几乎没有解决方案。

而使用EDA事件驱动架构和本地缓存策略,如下图,各个模块子服务只要将自己的状态主动提供给订单服务,而不是订单服务主动去调用这些子服务,顺序倒过来,只能靠事件驱动了,就这么简单。


banq
2013-06-08 11:14

这一切只是刚刚开始。

让我们回顾过去40年计算机界做了些什么,我们花了很多努力将手工流程搬到了用软件实现,因为信息化过程是逐步的,导致这些系统之间是隔离独立的,很难整合在一起。

这时我们有在数据库层面的整合方案,有在应用层面的整合EAI,使用WebService,使用ESB。但是这些方案都不便宜,不简单。

现在我们有更简单的解决方案。

重温一下SOA四原则:
1.边界是显式的
2.服务分享的是Schema和合约Contract,不是类
3.服务基于策略兼容
4.服务是自治的。

对于一个业务领域,我们难道真的只需要一个领域模型就可以全部代表他们吗?

下图是零售领域的模块图:


banq
2013-06-08 11:21

对于上图中零售领域,我们不能再用传统领域建模方式或者ER建模方式,结果会得出一个蜘蛛网式的大领域模型,虽然有很多类在里面,但是因为类之间都存在关联,实际还是一个大的领域模型。

对于零售领域,我们可以从不同利益相关者角度看待它,能够得出不同人群眼中的模型。

下图一表达不同人看待零售领域有自己的观点,比如数据库认为数据的生命周期很重要,图二表达使用DDD提供解决方案,每个模块其实是DDD中的有界上下文,模块整合是上下文之间共享实体标识罢了。





banq
2013-06-08 11:27

由于服务分散在不同系统中,这种自治分离状态为整合带来问题,如果一个大服务需要调用分散在其他服务器上的几个子服务,如何保证整个大服务的事务性?

采取分布式事务吗?XA或两段事务?

分布式事务的问题是性能慢,锁的时间无法预计。锁本身无法伸缩扩展。

那么使用同步通讯(如RMI)等方式?如下图:


5Go 1 2 3 4 ... 5 下一页