如何设计事件流，第 2 部分
扫描二维码
随时随地手机看文章
模式和数据契约
模式对于定义事件至关重要。模式提供了有关事件中应该出现什么和不应该出现什么的所有信息，包括名称、类型、可选性和内联文档，仅举几个功能。流行的模式技术包括Avro、Protobuf和JSON Schema。
如果您尝试在没有模式的情况下流式传输数据，那么您就做错了。但如果您只想要简短的形式，这里是：
1. 使用模式：模式可以防止生产者在写入数据时犯错误，因为您可以直接从模式本身生成生产者代码。同样，消费者不再需要解释数据 - 只需按照模式上的方式读取数据，并相应地使用它。模式还提供演化功能，您可以根据不断变化的业务需求安全地(在某种程度上)修改模式。
1. 构建数据契约：它们将事件的内容和流本身形式化。它类似于服务 API，不仅指定如何使用事件流，还指定如何访问它、安全要求和所有权。
但现在我们已经确定我们正在使用一个模式……让我们看看事件设计的第一个主要因素。
因素 1：状态(事实)与增量(变化)
状态事件(也称为事实事件)详细说明了特定时间点实体状态的整个范围。它包含履行公共数据合同所需的所有字段和值。您可以将状态事件视为关系数据库中的一行，其中所需字段由表的架构定义表示。
相反，增量事件记录两个状态之间的变化。它包括有关哪些字段已更改及其新值的数据，但不包括有关未更改字段的信息。
我们来看一下购物车的例子：
状态(事实)事件与item_added_to_cart增量事件
在左侧，我们有代表购物车在某个时间点的状态的状态事件，尽管它本身并不能准确指示发生了什么变化。为此，您需要访问之前的购物车信息。
右侧的增量描述了完全相同的业务发生，特别是添加到购物车的 item:521 的 1 个实例。但是，它不会显示购物车的当前状态 - 为此，您需要访问之前的所有增量事件。
事实和增量各有其权衡：所以让我们直接讨论何时使用哪个。
事实事件对于沟通状态来说是优越的
事实为其消费者提供了预先计算的状态，使他们无需计算任何状态。他们只是简单地消费事实并根据其业务逻辑处理状态。
如果您尝试与增量通信状态，则必须从主题的最开始重新创建状态。您还必须确保使用正确的业务逻辑来处理每个状态更改。大多数域比简单地在购物车中添加/删除商品更复杂，并且尝试在源系统外部重新计算状态是非常危险的。相反，只依赖事实事件。
考虑计算的复杂性：
· 客户公司银行账户的账户余额
· 电子商务零售商的当前库存
· 欠政府的税款
虽然其中每一个都可以由关心它的每个消费者来计算，但设置和维护起来却极其复杂。除了稍微减少网络数据使用量之外，它没有任何实际好处。简而言之，最好使用事实事件来传达状态。
事实让您推断出三角洲
一对事实事件可让您推断自己的更改：您可以看到从第一个事件到第二个事件发生的所有更改。
推断更改的一个选项：将最后一个事实保留在您的服务或作业的状态存储中。
您在服务或作业的状态存储中保留最后使用状态的副本。请注意，您只需保留您关心的状态，其余的都可以扔掉。您也可以选择保留多个先前的状态(例如，最近 3 个或最后 10 个状态更新)，以便您可以随着时间的推移推断更复杂的更改。
作为权衡，您需要提供状态存储。您还需要编写代码来推断状态之间的任何变化，其复杂性将根据您的要求而有所不同。在某些情况下，逻辑只需要检测边缘过渡，如下图所示，其中 adiscount_code应用于购物车。在其他情况下，状态计算可能更复杂，需要来自多个事件或流的数据与内部状态交叉引用。
推断更改的第二个选项：使用事件中的before和after字段。
您可以在单个事件中提供两种状态。正如您可能已经猜到的，before 字段保存更改之前的状态，而 after 字段保存更改后的状态。它通常用作变更数据捕获 (CDC) 服务的一部分，使您能够查看两个状态之间的整个更新，并自行推断单个事件中发生了什么变化。请注意，这会使活动规模增加一倍，并可能导致额外费用。
带有前后小节的购物车事实
事实事件本质上比增量事件更大。如果数据非常大或者更新非常频繁，那么维护成本可能会很高。
下载文档
