microservices - 微服务中的事件溯源、CQRS 和数据库

标签 microservices cqrs event-sourcing

我在微服务架构的背景下很新,阅读这篇文章:http://microservices.io/patterns/data/event-sourcing.html熟悉微服务架构中的事件溯源和数据存储。
我已经阅读了许多关于系统 3 个重要方面的文档:

  • 使用事件溯源而不是简单的共享数据库和 ORM 和
    行更新
  • 事件是 JAVA 对象。
  • 在永久保存数据的情况下
    ,我们需要使用 DB(关系或 noSQL)

  • 这是我的问题:
  • 数据库如何与事件溯源一起出现?我读过 CQRS
    模式,但我不明白 CQRS 模式与
    事件存储和事件对象?
  • 任何机构都可以为我提供一个
    完整的画面和一组操作发生在所有玩家身上
    收集:CQRS 模式,事件溯源(包括事件存储
    模块)最后是不同的微服务?
  • 在一个系统中
    由许多微服务组成,我们应该有一个事件存储还是
    每个微服务都有自己的?或者两者都可能?
  • 相同的
    关于CQRS的问题。这种模式在所有实现
    微服务还是只有一个?
  • 最后,在使用的情况下
    微服务架构,必须只有一个 DB 或
    每个微服务都应该有自己的?

  • 如您所见,我已经理解了所有小游戏,但我无法将它们联系在一起以构成一个完整的图像。 CQRS 与事件溯源和在数据库中存储数据之间的特别相关性。
    我读了很多文章,例如:
  • https://ookami86.github.io/event-sourcing-in-practice/
  • https://msdn.microsoft.com/en-us/library/jj591577.aspx

  • 但在所有这些中,都讨论了小玩家。即使是手绘图像也会受到赞赏。

    最佳答案

    How database comes along with event sourcing? I have read CQRS pattern, but I can not understand how CQRS pattern is related to event store and event objects ?



    CQRS 的“查询”部分指导您如何创建事件的投影,这适用于某些“有界上下文”,其中数据库可以用作持久化该投影的一种手段。 “命令”部分允许您隔离数据转换逻辑并将其与应用程序的“查询”和“持久性”方面分离。简单地说 - 您只需以多种方式将事件流投影到数据库中(投影也可以是关系的),具体取决于任务。在这个模型中,“查询”和“命令”有自己的转换和存储事件数据的方式,针对应用程序特定部分的需求进行了优化。相同的数据将存储在事件和预测中,这将允许实现子域(有界上下文、微服务)之间的简单性和松散耦合。

    Can any body provide me a complete picture and set of operations happens with all players to gather: CQRS pattern , Event sourcing (including event storage module) and finally different microservices?



    你有没有看到 Greg Young 试图提供 simplest possible implementation ?如果您仍然感到困惑,请考虑针对他的示例提出更具体的问题。

    In a system composed of many microservices, should we have one event storage or each microservice has its own ? or both possible ?



    它通常是一种常见的事件存储,但肯定有一些异常(exception),在边缘情况下,您确实需要多个存储来存储不同的微服务。这一切都取决于业务案例。如果您不确定 - 很可能您现在只需要一个存储空间。

    same question about CQRS. This pattern is implemented in all microservices or only in one ?



    它可以在大多数对性能要求很高的微服务中实现。这完全取决于当您将 CQRS 引入其中时,您的实现变得多么复杂。如果它变得更简单 - 为什么不到处实现它呢?但是,如果您的团队中的人们对在命令和查询部分之间执行更明确的同步的需要变得越来越困惑 - 也许 cqrs 对您来说太多了。这完全取决于您的团队,您的领域......不幸的是,没有一个简单的答案。

    Finally, in case of using microservice architecture, it is mandatory to have only one DB or each Microservice should have its own ?



    如果相同的微服务共享相同的表——这通常被认为是一种反模式,因为它增加了耦合,系统变得更加脆弱。您仍然可以共享同一个数据库,但不应该有共享表。此外,一个微服务中的表最好不要对另一个微服务中的表有 FK。同样的原因 - 减少耦合。

    PS:考虑不要问粗粒度的问题,因为很难得到人们的回应。几个更小、更具体的问题将有更好的机会得到回答。

    关于microservices - 微服务中的事件溯源、CQRS 和数据库,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40947247/

    相关文章:

    event-sourcing - 在事件溯源中解决 CRUD "tables"

    java - 对于所提供的用例,微服务和单一方法有什么区别

    meteor - 从外部 meteor 应用程序调用前端方法

    java - 如何在vertx中使用apache kafka,无论是在服务器端还是客户端?

    domain-driven-design - CQRS - 如何处理新的报告表(或 : how to import ALL history from the event store)

    domain-driven-design - 如何使用事件溯源更新大量数据

    cqrs - Axon 框架的排序策略如何在状态方面发挥作用

    node.js - 在 Nodejs 中构建微服务的更好方法

    design-patterns - CQRS:命令返回值

    cqrs - 具有不一致事件行为的事件溯源