在上一篇文章中，聊到了如何理解微服务架构中的cors，命令查询责任分离模式。正如这本篇文章提到的，cors模式被用在复杂系统的读写操作。正在这篇文章中，这种思想将被扩展到更复杂的事件溯源模式中。
问题描述
cors模式的局限性在于只能保存最近时间的领域实体。对于大部分应用程序而言，已经绰绰有余。但对于其他对灵活性要求很高的系统，又显得有些捉襟见肘，这时事件溯源就派上了用场。
事件溯源概念
事件溯源用以下的一组概念来描述更为妥帖。
- 事件溯源通常与CQRS结合使用。
- 实体中的更新操作均以命令呈现，通常这些命令与领域相关，对业务有一定的意义。
- 每个命令都仅添加到事件日志中，因此命令都是不可变的，带来了开箱即用的审计功能。
事件溯源案例
让我们回顾一个例子。
它与之前的图表几乎相同。CQRS模式也用在这里。
- 用户在Movie Actions服务上启动评分命令。
- 在活动的下面，给电影《指环王》8个评分。
- Movie Actions把这个事件保存到事件日志中，例如kafka。
- Movie Summary服务处理事件日志，并更新评分。
- 所有用户都可以看到更新的电影分级（所有的电影票房除以电影票总数）。
乍一看，什么都没有改变。但是，它为系统带来了更大的灵活性。
电影评级的问题在于人们有不同的品味。一般评分值仅显示根据多人的意见计算得出的平均分数。作为一家提供电影流媒体功能的公司，我们有兴趣向我们的用户提供好的推荐。我们如何才能做到这一点？为了简化逻辑，我们可以用一条语句来完成。推荐那些类型与该用户评价高的电影相似的电影。
因此，我们引入新的服务——电影推荐服务。
现在扩展已有的系统，因此电影推荐服务应处理所有先前分配的评级。使用事件溯源这是可以实现的，因为我们将这些信息保存在Kafka 中（将评分8添加到电影《指环王》中）。在第一个例子中，这是不可能的，我们只保存了最后一个电影评分值。
事件溯源的优点
- 关注点分离。
- 每个服务的缩放都是独立的。
- 可以为每个服务选择合适的数据存储及其模式。
- 在所有服务中进行简单高效的查询。
- 可以轻松地将新服务添加到现有应用程序中。
事件溯源的缺点
- 较为复杂
- 结果的一致性。
- 新服务可能需要大量时间来处理现有事件。
总结
在这篇文章中，回顾了事件溯源模式。它通常与CQRS一起使用。值得一提的是，这种模式的必要性可能发生在复杂的系统中。因此，应该谨慎选择它，以免给您的系统带来不必要的复杂性。
