c# - 通常要求呼叫者通过队列进行通信？

Question

最初，该团队正在考虑为母公司开发 C# 服务。该服务将接收请求，然后该服务将 ping 第三方并返回结果。

我们决定为请求和结果创建一个 AWS SQS 和 SNS 队列，而不是同步的。我们公司将向我们的 AWS 提供凭证，以便父级写入并从请求队列中通知。

那么这个服务就不是一个服务，而是一个处理器。然后它将从队列中读取并将请求发送并将结果写回另一个 SQS，SNS 将通知母公司端的 API。

问题：这是一个好的设计吗？我们绕过了服务的使用，以防止必须有重试逻辑和开发客户端，而我们只是通过队列进行通信。

标签： c#amazon-web-servicesdesign-patternsarchitecturemessage-queue

Answer 1

这种方法有很多优点。

• 您允许您的客户和“处理者”专注于他们的职责并通过消息总线进行交互
• 您允许客户端和处理器相互独立和解耦，特别是在使用的技术和编程语言方面。
• 两者都可以在需要时独立缩放。
• 如果其中一个“关闭”，则消息仍然可以在消息总线上累积并且不会丢失（假设您有合适的 TTL 来涵盖这一点）
• 如果提供的服务增长，您可以引入新的队列来处理它们，而不会影响当前的客户端和处理器
• 它们是异步的
• 您可以有多个生产者和/或消费者
• ETC

当然也有缺点

• 延迟增加。在某些情况下，这是一个问题
• 您依赖于第 3 方产品
• 如果使用 AWS、Azure 等，您依赖于第 3 方公司
• 3pp 派对和产品的额外费用
• 调试可能更困难
• 追踪可能更困难
• 安全可能更加困难
• 如果客户端或接收器出现故障，它可能不会立即显现出来。导致消息的积累，每个消息的生存时间都可能有限！（如果这发生在周末会怎样？）
• 确认收到请求很困难
• 确保在进程失败时消息不会丢失更加困难
• ETC

你当然可以在互联网上找到更多关于这些的信息。

因此，作为一种方法，这没有任何问题。唯一的问题是

“这是适合我们用例的架构吗？”

只有您可以通过权衡利弊来确定这一点，也许与您的客户一起。