为什么要用Event Sourcing?
为什么要用事件采购Why Event Sourcing? - Blog - CQRS and Cloud Computing
这是来自研究CQRS和云计算博客的一篇文章,大意如下:
Event Sourcing(事件采购 事件源驱动)已经越来越被大家熟悉,Event Sourcing本质上是一种持久数据的方式,这种方式能够保留信息详细到bit字节,它将事件的顺序作为对象,这些事件一直在发生并导致当前状态的变化(banq注:传统持久化数据是持久化状态,状态是事实的结果,而不是事实本身,我们在保存结果的同时,实际失去导致这些结果的可能原因,我把这个结果数据比喻成拉屎,我们要经常根据拉的屎推导今天吃了什么,很显然逻辑上不严密)。
打个比喻:持久化数据持久的是当前状态,比如我的零用钱是100EUR,后来变化到新值67EUR,很显然丢弃到前面的状态,将67EUR保存到数据库。
好像简单优雅,但是如果我们在执行大量逻辑,那么很显然会丢失信息,如果我们保留所有改变将是如下:
从ATM机取: 100 EUR
买了地铁票: -12 EUR
吃了一次午餐: -8 EUR
找到一个硬币: 1 EUR
出租车花费: -14 EUR
如果我们有这样一个事件顺序,我们能够得到当前零花钱结果:
Balance: 100 - 12 - 8 + 1 - 14 = 67 EUR
最后状态是是先前状态的左侧left-fold 功能,类似于 .NET的IEnumerable.Aggregate。C++的std::accumulate和JS的array.reduce。
你现在可能会问自己一个问题,如何保存这些中间过程呢?一种方式就是event sourcing 。
如何将这些事件作为数据保存呢?只要定义成对象即可,然后序列化成其他格式,如JSON XML等,如下:
GotMoneyFromAtm! (amount, transaction, time)
BoughtMetroTickets! (count, amount, machine, time)
GrabbedALunch! (amount, cost, time, menu, place)
FoundACoin! (amount, gps, time)
TookTaxi! (amount, rideDuration, taxiCompany, route, time)
通过给出的事件顺序,我们可以预测他们到任何需要的结构示意图。这是一个非常重要的功能。例如,我们可以写一个总结项目:总结我们的所有费用和生产的最新平衡。
我们还可以做更多的:
输出那些最经常可以发现硬币的城市的清单
获取的是最便宜的或最快的出租车公司,。
前5日个最喜爱的星期一午餐地方。
更有趣的,为了做到这一点,我们并不需要任何真正复杂的查询,。如果你只有当前零用钱状态单一的字段,即使你有一个变化清单(信用卡/借记),尝试这样做编写事件的预测(至少在C#)是枯燥的。
只要你有一个事件流,你可以以任何形式保存它,即使是传统的SQL数据库。举例来说,我最喜欢的方法是将事件流以JSON文本方式存储到云存储中。详情这里
事件代表一种可序列化的数据结构,能够进入追加式流中,如:
发布事件给多个订阅者。
实现冗余和可靠性
支持增量同步
基于事件的架构可以得到几乎无限的可扩展性,非常高的吞吐量和无死锁读取,这是因为如下事实:
事件可以在发生时尽快发布,
从事件模型中获取一些模型非常简单。
事件可以发布给多个用户,每个订阅者拥有自己一份可读取的模型。
因为这些我们几乎可以达到LMAX速度:
1.将读取模型(可预先计算的查询结果)直接存储在MemCached内存中,如果某个服务器当机,我们可以直接从事件历史重新导出到缓存中。
2.多个并行读取进程。
3.实时严格要求的系统将得到好处。
其他好处还有:
1.简化部署和维护 很少的SQL
2.减少了对硬件和软件(不需要有非常强大的和冗余的服务器或商业数据库)的费用。
3.系统之间的整合更简单(这里直接适用于所有的企业集成模式)。
4.由于没有数据丢失,我们获得了全面的审计(特别能力是在任何时间点)和优秀的调试功能。
5.事件采购是一个为软件开发人员想捕捉的业务领域的精髓(尤其是最复杂的),同时保持平台的复杂性或硬性能问题脱钩的天作之合。
6.ES的方法,帮助提供市场和技术给我们带来一些新的挑战的明确的答案:云计算,数据处理,移动和偶尔连接的系统,实时的商业智能。
当然,Event Sourcing事件采购不是银弹,只是一种不同的数据思考方式罢了,如果你是C程序员,感觉回到了汇编时代...
下面是一些困难:
1.定义事件是一件艺术,需要熟悉的领域建模,DDD领域驱动设计是关键。
2.需要软件和硬件支持事件采购,在以后几年,你会看到这个领域的很多解决方案。(banq注:jdonFramework是一个支持DDD DCI 事件采购 的开源框架)
3.这方面是新生事物,可指导的经验太少。
4.限制与真正成熟的DDD/ES技能。
其他带来的问题还有:
1.需要超级大的存储消耗。云存储解决。
2.比较慢也不是问题,因为我们优化优化IO来实现快照和持久。并利用基于事件的天然“推”性质,我们可以得到立即失效缓存。简而言之,能够过后有多个插入,需要这种多个的技术解决方案。
3.脆弱(丢失失过去的一个事件将导致整个流腐败)不是一个问题,因为你可以决定自己的SLA水平去(通过复制和冗余)。使用Git的方法,可以可靠地检测在任何一个副本的腐败事件包括SHA1签名针对它的内容和以前的事件签名计算。
Domain Events – 救世主
使用CQRS重新考虑架构
[该贴被admin于2011-10-30 11:06修改过]