事件源（事件溯源）并不是一个新词，如果你在技术领域工作，你一定接触过事件源。事件源是一个强大的工具，被许多大型组织作为他们的数据库架构设计。它有能力扩大规模并服务于现代数据行业的需求。
在这篇文章中，我们将了解更多关于事件源的信息，以及为什么它越来越受欢迎。我们还将讨论问得最多的问题。事件源是否会超越数据库？
什么是事件溯源？
事件源是一种架构模式，将数据存储为一连串的事件。一个事件只不过是业务操作的一个背景。例如，一个客户要求退款，但你不知道为什么？事件源给出了退款的背景。
让我们了解一些与事件源相关的关键术语。
事件
事件代表了数据状态的变化。这些是不可改变的事实，为业务提供背景。让我们举一个电子商务商店的例子。所有的数据变化将被存储为事件，如ProductAdded, ProductOrdered, ProductShipped, PaymentReceived等。
事件是以过去时态记录的，并为当前的业务状态提供真相来源。除了上下文，事件还存储元数据以提供更多信息。
事件源数据库
事件源数据库也被称为事件溯源数据库，它在一个仅有附录的数据库中记录所有的事件。在事件源数据库中，变化的历史是按时间顺序维护的。
事件源数据库也可以被称为事件日志，它们不能被改变，因为事件是不可变的。还有一个反驳说，事件源数据库可以通过添加另一个事件来改变事件源数据库的状态或其结果是变化的。
电子商务商店的事件源数据库将记录每个事件以及相关的元数据。假设在产品的事件源db中有两个事件，第三个产品被添加到事件源db中。这个添加的产品不是新的，而是由客户返回的，所以事件的背景是返回的产品和事件的数量被更新。事件源数据库按时间顺序保存所有这些事件。
事件的背景和时间顺序为深入分析提供了有用的信息。
流
事件流提供了一个与特定事件相关的完整的修改历史。事件驻留在事件源数据库中，事件流代表事件发生的顺序。事件流可以是短期的，也可以是基于特定场景的长期的。事件流中的事件由一个唯一的数字值来标识，并随着事件的更新而递增。你可以通过这些标识符检索到事件的原始状态。在电子商务商店的例子中，支付是一个独立的实体/域对象。支付对象有自己的唯一标识符，它的事件流将是。确认付款 -> 收到付款 -> 要求退款 -> 扣除退款金额。
查询视图
在事件源中，查询模型代表了源写模型到读模型的逻辑转换。它们也被称为投影或视图模型。在查询视图中，有两种类型的概念：读模型和写模型。让我们回顾一下电子商务商店的例子，被添加到查询视图中的写模型事件有：下订单、收到付款、订单发送、产品扣除，然后我们使用查询视图来生成所有订单的摘要和读取模型中收到的付款。
为什么我们需要事件源？
在各种应用中，事件源是一个很好的选择。让我们讨论一下事件源是一个可接受的解决方案的几个场景。
- 事件源在审计系统中是非常有用的，它可以按照时间顺序存储日志，并且有按需备份的选项。
- 传统的方法是在特定位置收集数据，只在需要时使用。通过快速响应新的可用信息，事件驱动的方法可以更加有效。通过订阅数据流，一个组织可以收到关于新发生事件的更新，并立即作出反应。这使得建模和创建复杂的商业程序变得更加简单。
- 有可能慢慢地将遗留系统迁移到当代的分布式架构中，最终用事件来源的服务取代特定功能。当写操作被引向服务时，遗留系统当前的读取途径可以继续使用。
- 如果有一个服务宕机，当原发服务恢复运行时，依赖性服务可以 "赶上"。当每个服务恢复时，可以完成同步，因为事件是以特定顺序存储在流中的。
- 在事件源系统中，数据在一个方向上通过单独的模型来读取或更新数据。由于数据流的每个部分都有单一的责任，它使数据的推理和问题的排除更加容易。
事件源数据库（db）与传统数据库有何不同？
数据被存储在数据库中，使用CRUD操作，即创建、读取、更新和删除。每当有变化发生时，数据库中的记录就会被更新，并保留了系统的当前状态。在所有关系型和非关系型数据库中，记录可以被删除，而系统的状态将被丢失。
在事件源数据库中，事件是不可改变的；它们不能被删除或改变。事件源数据库按时间顺序保留了日志的历史。通过跟踪变化，避免了审计数据和交易数据之间的差异。就像在CRUD系统设计中，事件源将事件存储在表中，但以时间顺序存储。由于数据是按顺序排列的，最新的数据在最上面，与传统数据库相比，过滤事件源更容易。
事件源是否会超越了数据库？
在现实世界的应用中，多个并发用户正在更新数据存储中的记录，而数据往往不会在所有地方更新。这就导致了数据存储的不一致性。没有机制来存储可用于深入分析的历史变化的元数据。
事件源还为数据库中发生的变化提供背景，这有助于回答业务问题。事件源与微服务配合得更好，并且可以在其他服务之间可靠地共享数据。
以下是一些优势，使事件源成为比传统数据库更好的选择。
- 事件可以通过仅有的附加操作来保存，并且是不可改变的。处理事件的任务可以在后台运行，而启动它们的用户界面、工作流或流程可以继续。这一点，加上事务处理过程中没有冲突，可以极大地提高应用程序的性能和可扩展性，特别是在表现层面或用户界面。
- 事件是直截了当的对象，它解释了一个已经发生的行动，以及任何需要全面描述该事件所代表的行动的额外信息。数据存储不直接被事件更新。它们只是被记录下来，以便在必要时进行处理。这可以使管理和实施更加简单。
- 对于领域专家来说，事件往往有意义。然而，对象-关系阻抗不匹配可能会使理解复杂的数据库表成为挑战。表是由描述系统当前状况的对象组成的，而不是实际的事件。
- 因为事件源不需要直接更新数据存储对象，它可以协助防止并发修改引起的冲突。不过，领域模型仍然必须建立起来，以承受可能导致不一致状态的查询。
- 任务通过执行由事件源数据库引发的行动来响应事件。
- 工作和事件是分开的，这提供了灵活性和可扩展性。任务知道发生的事件的类型和它的数据，但不知道引起它的操作。
- 此外，每个事件可以由许多任务来处理。这使得整合额外的服务和系统成为可能，这些服务和系统只限于监测由事件源db引发的新事件，很容易。然而，事件源事件经常有一个非常低的水平，因此必须在其位置上创建特定的集成事件。
事件源的挑战
尽管有很多优势，但事件溯源也有很多挑战。让我们来讨论一下与事件溯源的一些挑战：
- 事件源数据库是不可改变的，作为一个永久的数据存储库，事件数据不应该被修改。在事件源数据库中添加一个新的事件是更新一个实体的唯一选择，以扭转修改。如果持久化事件的格式（而不是内容）需要改变，可能是在迁移过程中，将存储中的当前事件与新的版本混合起来，这可能是一个挑战。可能需要引入利用新格式的新事件，或者对所有现有事件进行循环调整，使其符合新格式。为了保持新旧事件的形式，可以考虑在事件模式的每一次迭代中使用一个版本标记。
- 由于没有标准的sql机制，查询数据或从事件源数据存储中读取数据可能很困难。为了读取数据事件流是针对事件标识符进行提取的。
- 事件源数据库可能包含由多线程程序和应用程序的多个实例存储的事件。事件源数据库中的事件的一致性和对特定实体有影响的事件的时间都是至关重要的（实体发生变化的顺序会影响其当前状态）。每个事件都应该有一个时间戳以帮助避免问题。另一个典型的技术是给每个由请求产生的事件分配一个递增的标识。如果有两个操作试图在同一时间为同一实体添加事件，事件源数据库可能会拒绝一个与现有实体标识符和事件标识符相匹配的事件。
- 事件源减少了冲突的数据变化的可能性，应用程序仍然必须能够处理最终的一致性和没有交易带来的不一致问题。例如，如果在数据存储中发生了表明库存减少的事件，而此时正在为该物品下订单，则可能需要通知客户或创建一个备用订单。
- 一旦事件源系统已经捕捉了一段时间的事件，另一个困难就会出现。找到一种处理历史事件的技术变得至关重要，因为尽管记录系统处理过的所有事件是一回事，但如果不能理解历史，事件日志就会变得完全无用。整个事件日志可能需要被重新处理，以便在系统故障恢复事件中或在迁移派生状态存储时使系统的数据宇宙达到最新。对于处理大量事件的系统来说，定期的系统状态快照也是必要的，在这种情况下，再次处理整个事件日志会超出任何恢复时间目标，所以恢复可以从最近的已知良好状态开始。企业必须考虑到事件是如何形成的，该结构如何随着字段集合的变化而变化，以及鉴于业务运行方式随时间的变化，如何使用当前的业务逻辑来处理具有早期结构的事件。通过使用定义好的、可扩展的事件模式，可能会使事件记录面向未来，但也有必要为最新的业务逻辑添加额外的处理规则，以确保早期的事件结构仍然可以被理解。定期的快照也可以用来区分事件结构的重大变化，在这种情况下，维护先前事件的费用最终会超过其内在价值。
结论
我们已经详细研究了事件源的概念及其优点和缺点。作为最后的结论，事件源是一个伟大的存储数据的架构设计模式。然而，只有在正确使用的情况下，它才能带来价值。在一些情况下，传统的数据库技术是一个更好的选择，应该被使用。事件源将在未来几年内被大量采用，但它不能取代传统数据库。基于CRUD的数据库将继续存在，它们也为大量的现实世界的应用服务。