1 简介

基于事件溯源的事件驱动，事件溯源模式是一种通过将每个更改记录为事件序列来存储数据的方法，而不仅仅是保存最新状态。

此方法对于需要完整作历史记录、轻松数据恢复或复杂审计的应用程序特别有用。通过重放这些事件，系统可以重建当前状态或调查过去的状态，使事件溯源成为处理复杂工作流的理想选择。

这将为您的软件记录一份详细的日记。您不仅可以更新数据的当前状态，还可以将每个更改记录为单独的事件。这些事件构成了数据随时间变化的完整历史记录。因此，您可以通过重播这些事件来重新构建数据，以了解数据是如何到达现在的位置的。

这些事件按顺序存储，形成已发生作的日志或日志。
通过重播这些事件，可以随时恢复程序的状态。
它经常用于金融和电子商务等领域，在这些领域，精确的历史数据是必不可少的。

2 实现步骤：

• 捕获事件而不是状态：

每个系统修改都记录为一个事件（例如，“已创建订单”、“已添加项目”、“已完成订单”），而不仅仅是保留最终状态（例如，“订单已完成”）。

每个事件都表示一个不同的作或修改。按顺序存储事件：所有事件都按其发生的确切顺序按顺序存储（通常存储在数据库或事件存储中）。这一系列事件充当系统的 “事实来源”。

• 重放事件重建状态：

当您需要了解当前状态时，系统会“重放”或处理所有过去的事件，以从头开始构建状态。
Handle New Events：随着新更改的发生，将创建新事件并将其添加到序列中。

例如，如果更新了订单，则会将新事件（例如，“订单已更新”）添加到序列中，而不会更改或删除过去的事件。

• 重放事件以进行调试：

如果需要查看历史记录或调查问题，可以重放事件以查看状态如何随时间演变。通过此重放功能，可以轻松了解所执行的作顺序并跟踪任何错误或问题。

3 实现示例

转向事件源架构，该系统现在将每个重大更改记录为一个事件，从而可以更好地进行跟踪和历史分析。

系统不是直接更新数据库，而是处理用于创建和取消注册的命令，并为每个作生成事件。
每个状态更改都由一个事件表示，提供用户作的清晰审计跟踪。
通知通过事件订阅者处理，确保用户及时收到有关其注册状态更改的通知。

  type EventStore struct {
      mu     sync.Mutex
      events []string
  }

  var store = EventStore{}

  func main() {
      r := gin.Default()
      r.POST("/store", storeEvent)
      r.GET("/replay", replayEvents)

      r.Run(":8081")
  }

  func storeEvent(c *gin.Context) {
      event := c.PostForm("event")
      store.mu.Lock()
      store.events = append(store.events, event)
      store.mu.Unlock()

      c.JSON(http.StatusOK, gin.H{"message": "event stored"})
  }

  func replayEvents(c *gin.Context) {
      store.mu.Lock()
      defer store.mu.Unlock()

      for _, event := range store.events {
          log.Println("Replaying event:", event)
      }

      c.JSON(http.StatusOK, gin.H{"events": store.events})
  }

4 核心组件

系统设计中的事件溯源围绕几个核心概念和组件展开：

事件： 这些是系统状态更改的永久记录。除了表示特定的作或事件外，每个事件还包括在事件发生时重建系统状态所需的所有相关信息。
事件存储：系统生成的事件流由事件存储（一种强大的数据存储）维持。它通过按接收事件的顺序存储事件来保证事件序列的维护。

聚合：为了处理命令和生成事件，聚合是链接域对象的逻辑集合，这些对象作为一个单元进行处理。系统的状态更改和业务逻辑包含在聚合中。在事件存储中，每个聚合都链接到不同的事件流。

命令：客户端或其他系统组件可以发出命令，这些命令是执行特定任务的请求或指令。通过验证流程命令、应用业务逻辑以及生成相应的事件（如果命令获得批准）来聚合流程命令。

Projection：投影是从事件存储中保存的事件流创建的读取模型，用于显示系统的当前状态。投影用于提供对数据的有效访问，以便进行报告和查询。

事件总线：事件总线是一种消息传递基础设施，它使各种系统组件可以更轻松地就事件进行通信。它使组件能够异步响应特定事件类型并订阅它们。

5 优势和挑战

事件溯源在系统设计中提供了几个好处：

通过记录所有系统修改，Event Sourcing 会构建所有活动的不可更改记录。
使用事件溯源，您可以重放事件到某个时间点，以查询系统的当前状态。

事件溯源鼓励随着时间的推移进行适应性和系统开发。可以创建新的事件类型来满足业务需求的变化，而不会影响当前组件。
事件溯源非常适合分布式系统和水平扩展，因为事件可以由多个组件单独使用和处理，从而提高可扩展性和速度。
事件溯源模式的挑战。

虽然事件溯源提供了各种好处，但它也带来了一些挑战：

随着系统的发展，事件可能会采用不同的结构。管理事件版本控制和向后兼容性以保证无缝迁移和升级而不擦除以前的数据变得至关重要。

正确存储和检索大量事件可能很困难，尤其是在高吞吐量或事件历史记录较长的情况下。建立高效的查询和事件存储系统变得至关重要。

由于最终一致性，系统的各个组件可能会在不同时间看到状态变化，这通常是事件溯源的结果。在处理最终一致性时，处理过时的数据、解决冲突和数据同步都需要仔细考虑。

6 使用案例和应用

Event Sourcing 可在跟踪和分析历史数据至关重要的不同领域和使用案例中查找应用程序。
常用的场景：

金融系统：为了保持交易、账户活动和合规事件的不变记录，银行和金融机构使用事件溯源。
医疗保健记录：电子健康记录 （EHR） 系统使用事件溯源来记录患者接触、治疗史和医疗程序。
供应链管理：事件溯源用于供应链和物流管理，以跟踪库存变动、运输更新和供应链中断。
电子商务平台：事件溯源是电子商务应用程序记录客户互动、订单履行流程和库存变化的有用工具。这使得跟踪订单、提供定制建议和检查客户行为以提高销售额和客户满意度成为可能。
游戏和虚拟环境：事件溯源用于虚拟世界和多人在线游戏中，以记录玩家移动、游戏状态更改和游戏内购买。

不是最佳使用场景：

简单应用程序：如果应用程序只需要跟踪最新状态，而不需要完整的历史记录或审计跟踪，则事件溯源可能会带来不必要的复杂性。

高存储成本：事件溯源将每个更改存储为事件，这可能会导致高存储成本，尤其是在频繁更新或更改的情况下。
复杂的数据一致性需求：管理多个事件的一致性可能变得具有挑战性，尤其是在协调不同服务或系统之间的数据时。
性能敏感度：重放事件以重建状态可能会降低需要快速数据检索的应用程序的性能。

7 小结

事件溯源就像为您的软件记录详细的日记。通过将每个更改记录为单独的事件，它可以提供系统内执行的所有作的准确且不可变的记录。
此模式具有改进可审计性、可伸缩性和弹性等优势。它支持准确的历史分析、实时跟踪系统状态和高效的故障排除。