使用 ASP.Net Core WebApi 两个微服务之间的通信

Question

我有两个微服务。第一项服务为客户，第二项服务为发票服务。

在 Invoice MicroService 中，我将仅保存 CustomerId。使用此 CustomerId，我想检索客户微服务的所有相关数据。但我不知道异步通信。

请给我一些想法。

Answer 1

您所提议的（特别是一个服务直接向另一个服务进行 HTTP 调用）被称为服务之间的紧密耦合，并且是微服务中的反模式。它本质上将您的应用程序变成了分布式整体- 应该避免这种情况。

关于如何正确地异步执行此操作并具有良好、干净的松耦合边界的一个示例（有很多选项）如下：

• 您的系统利用消息总线（我喜欢 AMQP，但还有其他选择）
• 创建客户后，您Customers Service会生成一个customer_created事件
• 您Invoicing Service订阅这些事件，并在收到后进行必要的内部customer_id更新（这保持其本地数据存储更新 -最终一致性）
• 当您Invoicing Service创建需要来自 的信息的发票时Customers Service，它会生成一个cust_invoice_pending事件
• 您Customers Service订阅了此事件，当它看到一个事件时，它会生成一条新消息，就像invoice_customer_detail_push在总线上一样（注意，我会invoice_id在此消息的有效负载中使用 an 将它们绑定在一起）
• 您Invoicing Service订阅并查看所需的数据，从而可以填充发票的其余部分

这似乎需要大量额外的工作和复杂性，事实确实如此。这是成功的微服务架构的“难”部分。这需要更多的纪律和预先规划，但在这个简单的例子中，最终的解决方案与您提出的分布式整体解决方案相比具有以下优势：

• 您可以用完全不同的东西替换您的Invoicing Service或Customers Service，而无需触及其他服务中的代码
• 您已经抽象了与这两种服务的 authz 相关的问题 - 它们共享消息传递总线，只要它们都可以往返于该总线，则双方都不知道对方
• 您可以允许未来的服务监视此业务流程并与之交互（创建和详细说明发票），而无需更改这两个服务中的代码
• 如果两个服务之一发生故障，另一个服务将继续完全响应，并且任何等待发生故障的服务重新联机的工作都会自动排队 - 它会持续存在于调用/接收服务之外

因此，如果在您的情况下，这些好处值得您进行权衡，那就去吧。但是，每当您看到两个“微服务”直接通信时，您可能已经忽略了一些耦合，并且需要重新检查信息如何在系统中流动。