.net 在集成基于异步消息的情况下，向系统添加新服务的策略/框架是什么？

当我将新服务添加到一组已经运行的服务中时，我需要上游依赖项将过去的所有消息发送到新服务，以便它可以将其状态与整个系统的状态一致

如果我们假设每个上游微服务都使用自己的技术堆栈，那么在该级别上进行集成的成本就高得令人望而却步：文件、具有快照状态的不同数据库或内部事件流——从所有这些源获取数据只会违反隔离和封装原则

有哪些选择

每个微服务都可以公开端点以访问其当前状态，下游服务将在其初始化阶段使用该状态

每当部署多个服务实例时，只有一个实例应该执行初始化以避免并发问题

流程：

• 以

  init

  模式启动
• 创建消息队列订阅，如果它们不存在，但尚未处理传入消息，请让它们累积起来以供以后处理
• 从http端点获取数据、转换、持久化（可能只有在date

  X

  之后发生更改的条目）
• 为每个上游依赖项保留标志

  StateIsReconciled

  或

  dateofrecordination

• 以正常模式启动，处理队列中的所有事件

---

这个流程需要一个框架支持，但到目前为止我找不到任何东西。Asp.NET Core为此提供了什么？还是我把事情搞得太复杂了，还有其他要求不高的方法存在？

从某种意义上说，是的，我认为你把事情搞得太复杂了。然而，这可能仅仅是因为您没有正确地处理数据和状态

首先，新服务不需要任何形式的消息回放。它当时并不存在，所以之前发生的事情都不应该引起它的关注。这里的问题可能是你需要在你的真相源头上移动针头。当使用消息队列和事件源时，消息的记录就是真相的来源。这就是每个对象在其生命周期的每个点上的整个状态所在的位置。其他任何东西只不过是它的一个快照。因此，您可以直接使用消息存储作为您的阅读模型。诚然，重放消息以获取对象的当前状态可能有点耗时，而且需要大量的处理，但这正是快照的用武之地。您只需要重播自上次快照以来的内容

其次，你的新服务不应该真的在意。如果您实际上遵循的是微服务体系结构，那么它应该在自己的子域（有界上下文）中。如果你有任何形式的交叉，那么你实际上只是在构建一个“分布式整体”，也就是说，你不是在做微服务

当然，可以在微服务之间进行通信，因此也可以在有限的上下文之间进行通信，但这就是反腐败层的作用所在。消息队列本身实际上是其核心的反腐败层，因此您的工作需要在这里进行。从一个微服务到另一个微服务的读取是可以的（只要您完全理解并且您得到的不一定是准确的或最新的），但是任何类型的命令（创建、更新、删除等）都需要经过消息队列

---

长话短说，如果您实际上遵循微服务体系结构，那么引入新服务并不需要什么。只有在紧密耦合的情况下，才会出现问题，因此，如果在引入新服务时遇到问题，那么您需要实际查看您的体系结构并在那里修复错误。

>新服务不需要任何形式的消息回放。它当时并不存在，所以之前发生的事情都不应该引起它的关注。我们有UserData服务，它存储用户配置文件。此数据的一部分在其他服务中是必需的。我的新服务如何了解现有用户？最终的一致性意味着有多个真相来源，但是必须只有一个将在系统中传播的变化来源。不，仍然只有一个真相来源。其他“来源”是被认为“足够好”的快照。您使用的任何其他数据源都可能已经过时或不正确。如果您确实需要原始数据，那么您需要找到一个源：您的消息存储。如果新服务需要了解“已经存在的用户”，那么它只需通过为用户数据提供的读取模型查询即可。这通常是一个微服务本身，或者您可以直接查询消息存储。但是，当需要信息时会发生这种情况，而不是作为某种初始化。那么，如何获得新服务的快照呢？你没有？您已经有了一个用户服务。您的新服务可以从中获取用户信息。您不需要也不应该在新服务中管理用户。传统上，您只需将数据记录与

UserId

列关联，然后在需要时使用该id获取用户。如果您确实需要在这个有限的上下文中有一个“用户”的概念（只有当它在那个上下文中确实是一种不同类型的东西时，您才应该有这个概念），那么您实际上应该只跟踪那些不应用其他上下文中的所有用户的“用户”。这意味着您需要在这个服务上下文中创建它们。