软件交付流程

以下是从规划到生产的 11 个步骤：

  1. 产品负责人在 Jira 等工具中创建用户故事，启动整个流程
  2. 开发团队执行 Sprint 规划活动并将用户故事添加到 sprint
  3. 开发者在分配的故事上工作。故事完成后，他们将代码提交到 Git 并推送到 GitHub
  4. Jenkins构建代码并通过 JUnit、Jacoco 和 SonarQube 等测试和质量检查工具运行
  5. 如果构建成功，它存储在 artifactory（如 JFrog）中。Jenkins 还通过 Docker 将构建部署到开发环境
  6. 接下来，功能部署到 QA 环境。由于多个团队可能在相同代码库上工作，将创建多个 QA 环境
  7. QA 团队使用特定 QA 环境并运行多种测试类型，如 QA、回归和性能
  8. 一旦 QA 验证完成，功能部署到 UAT（用户验收测试）环境
  9. UAT 测试验证功能是否满足用户需求
  10. 一旦 UAT 测试成功，构建成为发布候选。它们根据特定时间表部署到生产环境
  11. SRE 团队使用 ELK 和 Prometheus 等工具监控生产环境并在出现问题时处理警报

事件溯源 vs. 传统 CRUD

下图显示了正常 CRUD 系统设计和事件溯源系统设计的比较。我们使用订单服务作为示例。

传统 CRUD

  • 步骤 1 和 2：Bob 想购买产品。订单创建并插入数据库
  • 步骤 3 和 4：Bob 想将数量从 5 改为 6。订单修改为新状态

事件溯源

  • 步骤 1 和 2：Bob 想购买产品。创建 NewOrderEvent，排序并存储在事件存储中，eventID=321
  • 步骤 3 和 4：Bob 想将数量从 5 改为 6。创建 ModifyOrderEvent，排序并持久化在事件存储中，eventID=322
  • 步骤 5：订单视图从订单事件重建，显示订单最新状态

事件溯源范式

事件溯源范式用于设计具有确定性的系统。这改变了正常系统设计的哲学。

如何工作？

不是将订单状态记录在数据库中，事件溯源设计持久化导致状态变化的事件到事件存储。事件存储是仅追加日志。事件必须用递增数字排序以保证它们的顺序。订单状态可以从事件重建并维护在 OrderView 中。如果 OrderView 宕机，我们总是可以依赖事件存储（这是真相源）来恢复订单状态。

适用场景

  • 需要完整审计日志
  • 需要时间旅行查询
  • 需要状态重建能力
  • 复杂业务领域

本文为学习目的的个人翻译，译文仅供参考。

原文链接：EP166: What is Event Sourcing?。

版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。