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

Question

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

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

有什么选择？

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

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

流量：

• 启动init模式
• 创建消息队列订阅，如果它们不存在，但还没有处理传入的消息，让它们累积以供以后处理
• 从 http 端点获取数据，转换，持久化（也许只有在 date 之后有变化的条目X）
• 保留标志StateIsReconciled或DateOfReconciliation为每个上游依赖项
• 以正常模式启动，处理队列中的所有事件

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

标签： .netasp.net-coremicroservicesmessage-queue

Answer 1

从某种意义上说，是的，我认为你把事情复杂化了。但是，这可能仅仅是因为您一开始就没有正确处理数据和状态。

首先，新服务不应该需要任何形式的消息回放。那时它并不存在，因此之前发生的任何事情都应该与它无关。这里的问题可能是你需要改变你的真相来源。使用消息队列和事件溯源时，消息记录是您的真实来源。这就是每个对象在其生命周期中每个点的整个状态所在的位置。其他任何事情都只不过是它的快照。因此，您可以从字面上使用您的消息存储作为您的阅读模型。诚然，重播消息以获取对象的当前状态可能会有点耗时且处理密集型，但这就是快照的用武之地。您只需要从上次快照开始重播。

其次，您的新服务不应该真正关心。如果您实际上遵循微服务架构，那么它应该在自己的子域（有界上下文）中。如果你有任何形式的交叉，那么你实际上只是在构建一个“分布式单体”，即你没有在做微服务。

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

总而言之，如果您实际上遵循微服务架构，那么引入新服务不需要任何东西。只有在紧耦合时才会出现问题，因此如果在引入新服务时遇到问题，那么您需要真正查看您的架构并在那里修复您的错误。