在上一篇文章中,聊到了如何理解微服务架构中的cors,命令查询责任分离模式。正如这本篇文章提到的,cors模式被用在复杂系统的读写操作。正在这篇文章中,这种思想将被扩展到更复杂的事件溯源模式中。


问题描述

cors模式的局限性在于只能保存最近时间的领域实体。对于大部分应用程序而言,已经绰绰有余。但对于其他对灵活性要求很高的系统,又显得有些捉襟见肘,这时事件溯源就派上了用场。


事件溯源概念

事件溯源用以下的一组概念来描述更为妥帖。

  1. 事件溯源通常与CQRS结合使用。
  2. 实体中的更新操作均以命令呈现,通常这些命令与领域相关,对业务有一定的意义。
  3. 每个命令都仅添加到事件日志中,因此命令都是不可变的,带来了开箱即用的审计功能。

事件溯源案例

让我们回顾一个例子。

#yyds干货盘点#——如何理解微服务架构中的事件溯源_数据存储

它与之前的图表几乎相同。CQRS模式也用在这里。

  • 用户在Movie Actions服务上启动评分命令。
  • 在活动的下面,给电影《指环王》8个评分。
  • Movie Actions把这个事件保存到事件日志中,例如kafka。
  • Movie Summary服务处理事件日志,并更新评分。
  • ​所有用户都可以看到更新的电影分级(所有的电影票房除以电影票总数)。

乍一看,什么都没有改变。但是,它为系统带来了更大的灵活性。

电影评级的问题在于人们有不同的品味。一般评分值仅显示根据多人的意见计算得出的平均分数。作为一家提供电影流媒体功能的公司,我们有兴趣向我们的用户提供好的推荐。我们如何才能做到这一点?为了简化逻辑,我们可以用一条语句来完成。推荐那些类型与该用户评价高的电影相似的电影。

因此,我们引入新的服务——电影推荐服务。

#yyds干货盘点#——如何理解微服务架构中的事件溯源_应用程序_02

现在扩展已有的系统,因此电影推荐服务应处理所有先前分配的评级。使用事件溯源这是可以实现的,因为我们将这些信息保存在Kafka 中(将评分8添加到电影《指环王》中)。在第一个例子中,这是不可能的,我们只保存了最后一个电影评分值。

事件溯源的优点
  • 关注点分离。
  • 每个服务的缩放都是独立的。
  • 可以为每个服务选择合适的数据存储及其模式。
  • 在所有服务中进行简单高效的查询。
  • 可以轻松地将新服务添加到现有应用程序中。


事件溯源的缺点
  • 较为复杂
  • 结果的一致性。
  • 新服务可能需要大量时间来处理现有事件。


总结

在这篇文章中,回顾了事件溯源模式。它通常与CQRS一起使用。值得一提的是,这种模式的必要性可能发生在复杂的系统中。因此,应该谨慎选择它,以免给您的系统带来不必要的复杂性。