具有 CQRS 处理依赖关系的 .NET 微服务

Question

您好，我希望您向那些已经在比 TODO 示例更大的规模上使用微服务的人寻求建议。

让我解释一下关于建筑的基本想法。我想用 CQRS 在微服务架构中创建系统。我想微服务 A 将处理一堆命令和事件，但其他微服务也可以监听该事件。因此，总的来说，我必须以某种方式将这两个微服务之间的事件合同分开。要获得更好的概览，请参见简单的图表：

Diagram

我将把所有总线的东西、处理程序和逻辑都留在这里，我希望这很明显。我只想专注于合同

我在开始时的想法是将微服务 A 的代码与该域的所有事件放在一个解决方案中，但事件将被放置在单独的库中，该库将作为 nuget 公开。然后这个 nuget 将被微服务 B 使用，微服务 B 将根据合同实现自己的处理程序。

微服务A解决方案：

• 微服务代码（具有业务逻辑等的命令和处理程序）
• DomainContract（可以在多个服务之间共享的事件，但 已连接到当前解决方案域）

MicroserviceCode 对拥有 DomainContract 和其他 DomainContract nugets 具有项目依赖性

但后来我意识到，微服务何时会发展壮大等等 依赖会来，它可以启动 nuget 地狱并由于错误的 nuget 包等导致依赖问题。

我还考虑过将合约共享为 Json 格式的 Rest API 并消除 nuget 版本控制。

我想讨论一下如何避免微服务之间的地狱依赖。

或者，也许您使用了我描述的方法，并没有我想象的那么糟糕？:)

Answer 1

我建议您通过项目参考共享数据合约和事件合约，并将您的所有项目整合到一个解决方案中，这样编译器会立即告诉您需要修复的地方如果您更改合同。 当然，这样做的缺点是您每次都需要部署所有服务，因为如果您在签入时很难知道哪个服务使用特定的合同。

我喜欢拥有 nuget 包和存储库/服务的想法，但是如果您决定更改合同，则必须提前知道哪些服务使用该合同，查看代码并更新 nuget 包并签入代码，您需要对所有使用更改后的 Contract 的微服务重复此操作。

我在生产环境中看到了这两种解决方案，但我认为第一个解决方案更可靠，因为您无需考虑在任何环境中运行的任何服务是否具有旧的数据协定。

注意 您应该在合同中的服务之间共享的唯一内容。