服务器租用网站自动划分空间,若比邻跨境电商网站,自己建网站做外贸,哈尔滨网站建设与管理在近期举行的PHPDublin见面会上#xff0c;来自DynamicRes的架构师Barry Sullivan被问到“什么是事件溯源”#xff0c;作为对这个问题的回答#xff0c;他在博客上写下了这篇文章#xff0c;详细解释了什么是事件溯源以及事件溯源有哪些好处。以下内容翻译自Barry的博客来自DynamicRes的架构师Barry Sullivan被问到“什么是事件溯源”作为对这个问题的回答他在博客上写下了这篇文章详细解释了什么是事件溯源以及事件溯源有哪些好处。以下内容翻译自Barry的博客已获得作者授权。
Web开发的现状
在详细解释事件溯源之前先让我们来看看Web开发的现状。
当前的Web开发是以数据库作为驱动的在设计Web应用的时候我们会自然而然地将系统设计与数据库存储机制联系在一起。如果使用的是MySQL我们就会把数据结构设计成表如果使用的是MongoDB就会把数据结构设计成文档。这样会强制我们只关注事物的当前状态我们会想“怎样保存这些数据以便将来可以再把它们拿出来或者修改它们” 这种方式存在三个问题。
1. 有悖于我们的思维
人类的思考和交流并不是以状态为中心。如果我们在咖啡店相遇我会问你“最近可好”如果你只是告诉我一堆状态却指望我从中猜出发生了什么事情这是非常不合情理的。
“我有一幢房子、一辆汽车、一个冰箱、三个社交媒体账号、一只猫咪我的右脚有点痛我不擅长聊天我还有另一只猫咪……”
看到没有这样我会疯掉的。你应该告诉我从上次见面之后都发生了哪些事情这样我才能知道你现在的状况是什么样子的。简单地说你应该告诉我一个故事这个故事是由一连串事件组成的。
2. 单一的数据模型
在上图中读写操作使用了相同的模型。我们从写数据的角度来设计表然后基于这样的结构查询数据。这对于小型的应用来说是没有问题的但用在大型的应用里就会有问题。随着系统的增长查询会变得越来越复杂总有一天一个查询可能会包含10个连接操作代码有100行那么多。系统很快就会变得脆弱无比难以维护和变更。
3. 关键业务信息的丢失
这是一个大问题。在以表作为驱动的系统里你只保存了系统的当前状态你根本就无法知道系统是如何达到当前状态的。如果我问你“这个用户修改了几次邮件地址”你有办法回答吗或者我再问“有多少人把一件商品添加到购物车里然后又移除掉直到一个月之后才买了那件商品”你就更没法回答了。你存储数据的方式丢掉了很多有用的业务信息
事件溯源
事件溯源与上述的情况恰好相反它并不关心当前状态而是关注持续不断的变化事件。
举个例子假设我们有一个“购物车”我们可以创建购物车往里面添加商品或移除商品然后结账。
购物车的生命周期可以包含如下一系列事件
创建购物车往购物车里添加商品再次往购物车里添加商品从购物车里移除商品结账
这些就是一个购物车的生命周期包含了一系列事件。这就是事件溯源非常简单吧 几乎所有的流程都可以被看成一系列事件。在与领域专家交谈时他们不会提及“表”和“连接”他们会将流程描述成一系列事件以及可以应用在这些事件上的规则。
如何实施业务规则
大部分的业务操作都有硬性约束。对于购物车来说它的约束就是“一件商品必须先被放进购物车后才能被移除”。如果一件商品没有被添加到购物车里又怎么能够移除它这种事件顺序是不可能发生的。在没有状态的情况下你怎样才能知道“购物车里是否有这件商品”
很简单你只要检查之前是否发生过“商品被添加到购物车里”这个事件这样你就可以知道购物车里是否存在这件商品然后移除它。
这样不会浪费时间吗
一点也不。一般来说要执行约束只需要获得事件的一个很小子集。通过简单的数据库查询就可以获得有用的历史事件在加载完这些事件后重放它们把它们“投射”出来以此构建你的数据集。这样的操作其实是很快的因为你使用的是本地的处理器而不是执行一系列SQL查询跨域网络的调用要比本地操作慢得多至少会相差两个数量等级。
如何展示数据
如果说每一个状态都是通过重放事件来获得的那么该如何抓取数据并把它们展示给用户看每次都需要抓取所有的数据然后再构建这些数据集吗
答案是你没必要这样做这样做其实是很荒唐的。
你可以在后台构建数据集然后把中间结果保存在数据库里。这样用户就可以在很短的时间内查询到这些数据。 有了事件溯源你就不再局限于当前的表结构。需要做其他的查询只要设计一个新的结构就可以了。你可以自由地实现各种读取模型在不需要它们的时候再把它们抛弃掉。
事件溯源的好处
1. 临时的数据结构
因为所有的状态都可以通过重放事件获得所以就没有必要把当前“状态”与应用程序绑在一起。如果需要以新的方式查看数据直接创建新的数据视图即可。不再需要繁杂的数据迁移脚本要做的只是创建新视图抛弃旧视图。我现在几乎离不开事件溯源了。
2. 与领域专家的沟通变得更简单
正如之前所述领域专家通常将业务流程描述成一系列事件而不是状态。基于事件溯源的系统与领域专家的描述不谋而合所以就没有必要把他们的描述转换成技术概念这样也避免了信息丢失。与领域专家的沟通因此变得更加顺畅因为我们正在使用他们能够理解的语言与他们沟通这也让软件开发变得很不一样。
3. 极具表现力的模型
在事件溯源模型里事件是一等对象事件模型更加接近于实际的业务流程。这让很多东西都变得清晰明了你就不会陷入存储技术的泥潭。
4. 生成报告更轻松
在事件溯源系统里生成复杂的报告是一件轻而易举的事情。你拥有完整的历史事件它们按照时间排序你可以尽情地使用这些历史数据。
以之前的例子为例假设你想知道有多少个用户从他们的购物车里移除了商品却在一周后购买了这些商品。按照一般的开发方式通常需要几周的时间才能开发出这个功能而在发布之后需要等上一段时间等计算完所有数据之后才能生成报告。而在事件溯源系统里你可以马上得到报告。你还可以得到之前任何一个时间点的报告仿佛拥有了一台时光机。
5. 服务集成唾手可得
在标准的Web开发流程里集成两个系统通常会导致他们之间的耦合而事件溯源系统通过事件来解耦被集成的系统。当一个系统发生某系事件需要触发另一个系统的某个流程时只需要写一个事件监听器即可。这种机制可以让你在不修改已有领域代码的情况下增加新的集成逻辑或特性。
例如你想要在用户注册的时候发送一封欢迎邮件给他们你只需要创建一个事件监听器监听“用户注册”事件而不需要去修改注册逻辑代码。
6. 在一般的数据库上也能健步如飞
你不需要使用多么奇特的数据库来存储事件一般的MySQL数据库就足以。数据库都针对追加操作进行过优化所以存储数据的速度是很快的。这也就是为什么事件溯源在当前的技术条件下能够良好运作保存事件都是追加操作。
7. 可以随意更换数据库
基于事件溯源的数据结构都是临时性的所以你可以使用你喜欢的数据库来存储状态也就是说你完全可以选择最好的工具来完成你的工作。如果你发现了更好的工具可以在任何时候把旧工具替换掉。我们目前正在从MySQL迁移到OrientDB可以说是轻而易举。
事件溯源的不足
天下没有完美的东西事件溯源给我们带来了诸多好处但也存在一些不足。
1. 最终一致性
事件溯源只能保证最终一致性。也就是说在一个事件发生了之后其他系统不会立即感知到它在它们收到事件之前会有一定的延迟比如100毫秒所以你所投射的数据可能不是最新的。这看起来似乎是一个大问题但其实不是的。例如基于ReactJS构建的Web应用会基于用户的操作事件构建状态查询端出现几毫秒的延迟并不会有什么问题。
老实讲这可以说是塞翁失马焉知非福。最终一致性的系统具有容错能力可以解决服务中断问题。如果使用微服务架构或无服务器架构来构建分布式系统就需要通过最终一致性来保证稳定性。
2. 事件结构发生变化
事件结构会发生变化如果事先没有考虑到这个问题后续处理起来会有些麻烦。如果事件结构发生变化需要写一个更新器来转换新旧事件。转换过程可以在将数据从数据存储中读取出来之后进行。这个没有它看起来那么难只需要准备好应对策略就可以了。
3. 开发人员需要改变思维
目前的Web开发主要还是以状态作为驱动所以开发者习惯了从表的角度看待问题而不是事件。我发现要让开发者改变思维需要一些时间因为他们需要时间来改变习惯。最好的解决办法是让有经验的事件溯源开发者与传统的开发者结对。
总结
我很喜欢事件溯源在构建大规模分布式系统时它帮助我们解决了很多问题。我们可以使用领域专家能够了解的语言与他们进行沟通我们可以自由地改变和适配系统。尽管事件溯源有一定的学习曲线但一旦你进入到这个领域就不会想要回头。
原文地址http://www.infoq.com/cn/news/2017/09/How-understand-event-traceabilit .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
