Event Sourcing - ENode（二）
2015-10-23 05:02 DoPeter 阅读(1272) 评论(5) 编辑 收藏 举报
接上篇文章继续
http://www.cnblogs.com/dopeter/p/4899721.html
分布式系统
前篇谈到了我们为何要使用分布式系统，因为ENode本身就是一个分布式的框架。看了很多DDD、CQRS的框架，一般情况是一个上下文一个系统，可以多分系统实例进行分布式部署，但需要自己搭配分布式的基础设施。而ENode已经提供了较为完整的分布式DDD解决方案。
1. 分布式通讯基础设施
一般使用RPC、MOM、REST，不过最近REST已经逐渐弱化特别是在一个大系统的内部，或者是对性能要求较高的场景，作者自己实现并开源了MOM组件EQueue作为基础设施搭配ENode，有一些Kfaka的设计理念，但加入了自己的设想，可以到作者的博客上了解了解。
http://www.cnblogs.com/netfocus/category/496012.html
2. 分布式的粒度
这是ENode最大的亮点，从目前业内的发展的大方向来说，也是ENode能被投入生产环境试运行的原因之一。ENode是以Command、Event、Application Message、Exception为基础粒度采用的分布式设计。目前其他的CQRS框架大多都还是系统实例级的分布式，如果要实现这种粒度的分布式，需要自己动手设计，从长远来看，如果真的投入到生产环境，框架升级之后引发的不兼容等问题是很有可能的，当然ENode如果能成为我们目前OLTP系统的流行框架的话，还是得小心以后被作者绑架。
关系数据库
作者在框架中其实一直在使用关系数据库，因为有了前面粒度的铺垫，再加上ES本身的写屏障特性，实现了类似关系数据库的一致性，而只使用了关系数据库的持久化以及检查机制。当然作者在实现中仍然使用了事务，以及将关系数据库当分布式的锁来使用，有点类似ZooKeeper，这些都是基于的是粒度的缩小，所以性能上是有很大的提高。不过这些是作者的默认实现，我们可以自己实现另外一套。
其实应该从Sample开始讲的，不过如果有兴趣的朋友可以直接去下载作者的源码，作者的Sample写的很好，所以直接开剖。
全观
这是ENode的代码。
我们可以认为分为2层，开发者应用层（业务开发人员专用），基础设施层（架构开发人员专用） 。
Commanding，Domain，Eventing，Snapshoting属于应用层。是ES的专用术语。
Infrastructure和Configurations则是基础设施层。
Commanding
我们可以认为这是Commanding的装配图，顾名思义。
ICommand，一个命令
继承了IMessage，这就是前面提到的分布式消息。
其他的接口都是顾名思义。
ICommandHandler 命令处理者
ICommandHandlerProvider 隔离命令处理者的装配
ICommandHandlerProxy 命令处理者代理
Async则是代表异步的
就不一一介绍了。重点是看作者实现的默认的组件。
面向接口是代表作者抽象的高度与角度，真正代表其落地思想的则是其默认实现的类。
内容有点多，而且会很跳跃，这篇是讲不完的，我们还是慢慢来。主要是打字打的有点累了，手跟不上脑。先看看作者实现的DefaultProcessingCommandHandler类，
这是较为核心的，也可以认为是核心处理Command逻辑的类。
它实现了IProcessingMessageHandler接口，这个接口只有一个方法
void HandleAsync(X processingMessage);
于是我们就顺藤摸瓜看看作者的实现。
屏幕太小，截了2张图，第一张没什么特别的，第二张，这里使用了2个不同的Handler，一个是同步的，一个是异步的。它们的逻辑会有一些不同。
当然肯定是会执行Command的处理方法的。区别是什么呢？
在HandleCommand方法中，执行完后，有一些判断Command是否只是修改单个聚合根的逻辑，这里体现的是作者设计思想中的单个聚合根隔离性，也就是前篇所讲的关系数据库中事务隔离性粒度放至聚合根的粒度。在经过验证后，会直接提交Event，准备持久化Event，执行后续的，Event后续再讲。
在ProcessCommand方法中，用到了CommandStore，在作者默认实现的CommandStore中有2种实现方式，InMemory以及SQLSERVER，InMemory中是将Command存储在字典中，SQLSERVER则是以Command的ID作为主键，这里的逻辑是首先去CommandStore中检索是否存在相同ID的Command，如果有，则被证明是执行过了。如果没有，则继续执行Command，Command执行成功后，将Command保存至CommandStore中，保存成功后提交Event，准备持久化Event。这里实际上是在消除Command的幂等，第一个乐观锁机关出现了。
为什么第一个方法不使用乐观锁，而直接发布事件呢。
HandleCommand方法中的Command所对应的聚合根实际上还没有被更新，只是预提交一个Dirty的聚合根数据至EventHandler处，在EventHandler处会再次有乐观锁机关。
为什么ProcessCommand方法中要使用乐观锁呢，其实我没有完全的答案，猜测有以下几点
1. 见上图的If ，else if处，对一个Command来说，是可以有多个Handler的，无论是在系统实例内部或是其他并行的系统实例，再或者是其他上下文的系统实例，都有可能会有同步以及异步处理的Handler。
2. ProcessCommand方法是对应的异步CommandHandler，既然是异步的，作者使用了.NET的Task，虽然一个Command是单线程在跑，不过要是在异步中，例如我们和另外的系统通讯也使用了异步，那么这个线程就会返回，执行下一个Command，如果下一个Command相同，这个理论上是不大可能的。
3. MOM中消息的重复发送，这是有可能出现的。
关于上面猜测，作者的官方解释
所以不需要异步处理
而不操作聚合根时基本是调用其他外部IO接口，所以需要异步
另外，不操作聚合根的命令也一定会有一个关联的聚合根ID，这是框架的要求
比如转账前要求验证账号是否合法，可能是调用外部接口，但我们一定知道是要验证哪个聚合根的
虽然框架里目前没使用这个聚合根ID，但至少cmdstore会记录下来
方便我们跟踪命令和聚合根的可能对应关系
一个cmd归纳起来可以理解为有两种目的，1:操作某个聚合根，2:验证和某个聚合根相关的某种外部逻辑或规则
