我正在做一个研究项目，正在研究处理事件驱动的微服务体系结构中的更改的选项。

因此，假设我们有一个应用程序，其中有四个不同的服务。这些服务中的每一个都有自己的数据库来存储本地数据。

在此设置中，这四个服务使用事件总线相互通信。因此，当服务中发生某些事情时，它会发布一个事件。所有对该事件感兴趣的其他服务都将以自己的方式对其进行处理。

在那种情况下，架构中的不同服务需要就这些事件（属性等）的内容订立“合同”。因此，服务对这些事件具有“松散耦合的依赖性”

我的问题是： 我们如何应对这些事件的变化？

因此，假设服务A在应用程序中注册了新用户。因此，它发送一个“ UserRegistered”事件，服务B拾取该事件并对其进行处理，但是服务C小组的一些开发人员决定他们也需要注册用户的性别，因此该事件被更改，属性性别被添加到“ UserRegistered”事件。

我们如何确保服务B仍可以在不重新部署的情况下使用该额外属性来拾取同一事件？

还有其他方法可以解决此问题，然后对这些事件进行版本控制吗？

事件与变化无关。他们是关于什么时候改变。

我可以创建一个与更改内容完全脱钩的事件系统。这样，我从事件中学到的就是对象已更新。如果我什至不关心对象已更新，那么我将告诉任何知道如何与该对象对话的对象，询问它发生了什么变化。

那不能解决传达这些变化的问题。它只是阻止它成为事件系统的一部分。

解决数据不同版本问题的一种方法的一个示例是让观察者创建并向观察对象传递一个集合。被观察的对象将使用其最新数据填充集合，并且当控件返回时，您（观察者）将获得所需的东西。如果还有其他您不关心的东西（因为您从未听说过），则只需忽略它。

有很多其他方法可以给猫咪贴皮，但这正是我在这种情况下所做的工作。

诸如NServiceBus之类的框架通过将事件版本控制与多态消息分发一起使用来处理此问题。

例如，服务A的版本1可能将事件发布为IUserRegistered_v1。当Service A 1.1版需要包含其他字段时，它可能会声明接口IUserRegistered_v1_1，该接口将从IUserRegistered_v1继承并声明一些其他字段。

当服务A发布IUserRegistered_v1_1事件时，NServiceBus会将消息分派到处理IUserRegistered_v1或IUserRegistered_v1_1的所有终结点。

增量改进

对模型的简单更改是，当侦听器注册为观察者时，它们将包含他们希望了解的数据元素的列表或其他结构。如果从服务返回的数据很简单，则可以使用此方法，但是如果您有大量的分层数据，则实现起来会非常复杂。

坚如磐石

如果您真的想要一种健壮的方法来进行此服务设计，则该服务应保留对其存储的数据所做的更改的历史记录。本质上，您永远不会更新数据库中的记录，而是在每个记录代表更改的地方添加新记录。这些新记录中的每一个都与标识该操作的事件ID相关联。均匀记录与有关更改的所有相关信息（谁，什么，什么时候等）一起存储。这还具有一些其他好处，这些好处不在此答案的范围内，但本文将讨论CAP定理。

进行更改后，您将创建事件记录并将所有新数据添加到数据库中。然后，您将一个事件发布给包含（最少）事件ID的侦听器。然后，侦听器可以请求与该ID关联的数据，并获取与该ID关联的数据的版本。这样，每个侦听器都可以获取所需的任何内容，而无需将其他不同的侦听器的需求耦合在一起。我建议您将最常用数据字段的子集添加到事件消息中，以便侦听器可以过滤掉他们不感兴趣的事件。这可以减少过程的闲聊，并且某些侦听器可能永远不需要调用回来。这也可以保护您免受时间问题。如果您只是回拨服务并根据密钥获取数据，在获取事件和为其获取数据之间可能还会发生其他更改。这可能对所有侦听器都无关紧要，但是如果您需要了解所有更改，则可能会造成重大问题。如果您确实希望将其更改为11，则上述增量设计改进与该方法兼容。

对于您需要做的事情，这可能有些过头了，但是根据我的经验，如果您没有一种精确的方法来查看记录随着时间​​的变化，您或使用数据的人最终会想要它。

@CandiedOrange在评论他自己有关可扩展数据格式（如xml）的答案时提出了一个正确的观点。

只要添加数据就没有关系。但是，请为较旧的事件/非必填字段提供合理的默认值。

您只需要更新关心的服务-在这种情况下就是-性别。xml / json解析器应该能够忽略其他服务的额外数据。当然，这取决于您对解析器和事件数据格式的选择。

我不同意没有相关数据的事件。对于事件源，事件应定义发生了什么变化。接收到事件后，其他服务就不必从事件源中检索数据。