了解发布-订阅消息是否成功的模式答案

【问题标题】：Patterns for knowing if a pub-sub message was successful了解发布-订阅消息是否成功的模式
【发布时间】：2016-04-25 15:26:15
【问题描述】：

我正在为一个项目开发微服务，我们正在尝试使用 AWS SNS+SQS 进行发布-订阅通信。我们不确定如何向服务发出其他服务是否已成功完成任务的信号。
例如，如果服务 A 发出一个 SNS 事件，并且服务 D、E 和 F 都在监听订阅的 SQS 队列，那么服务 A 如何知道服务 A 在服务 D、E 和 F 内部启动的活动是成功的？

我将举一个更具体的例子：一个新用户注册了一个网站。这个网络调用首先到达后端的user service。如果用户成功，它会发送一个事件，说明创建了一个新用户。这会触发email service 向用户发送电子邮件以确认其注册。如果它无法发送电子邮件会怎样？有user service:

1) 已经回复前端说成功了

2) 还是在等待确认？什么是确认的好发布-订阅模式？

我知道我们可以只进行一次同步调用，但为了简洁起见，这个例子被简化了。

【问题讨论】：

如果您已经从事件开始，为什么不继续呢？让服务发布原始服务侦听的确认事件。
@dbugger 如果它正在等待队列等待一切成功，这是否意味着service A 只是在同一个线程上等待，而前端也在等待来自service A 的响应?
这取决于你，但我的倾向是不会让前端等待。响应前端收到请求。让服务 A 等待它的响应。当它收到确认时，它可以向前端发送确认。如果在超时时间内未能接收到它们，它可以 a) 重试，或 b) 告诉前端出现错误。
明白了。关于 b)，如果前端用户已经收到一条成功的消息（即使这不确定），并且用户移动到不同的屏幕，前端如何侦听电子邮件失败的可能消息发送？使用 SNS 或一些推送消息服务？

标签： design-patterns publish-subscribe amazon-sqs amazon-sns microservices

【解决方案1】：

正如@dbugger 在 cmets 中所说，您可以让订阅者向发布者发送 ack 或其他内容。

但是，确保订阅者收到事件是发布者的责任吗？

发布事件的一种意义在于，发布者不需要（也不应该）知道订阅事件的消费者的状态，订阅者是否忽略了消息，或者即使没有订阅者.

如果发布者确实需要知道，而不是事件，发布者应该以请求-响应模式直接向消费者发送命令，而不是事件。

这是因为命令消息假设接收者知道，而事件消息假设不知道。

从自上而下的角度了解事件何时到达：嗯，您应该使用可以保证事件传递的持久消息传输，但即使具有持久性，您仍然可以丢弃消息。

做到这一点的唯一真正方法是实现某种工具，使您可以跟踪编码在各地发布的事件中的“对话”。有可用的工具（我只使用了一个，用于 NServicebus，称为 ServicePulse）。

【讨论】：

其实是ServicePulse提供了监控看消息是否失败:)
@TomRedfern 你真的能够将确认发送回发布者还是只发送给 RabbitMQ 等消息代理软件？
我现在了解到，如果消息成功，您会从队列中删除消息，这是确保消息成功处理的方法，但我仍然很好奇是否可以向发布者确认消息成功。
@NateW - 这并不总是可能的 - 一些消息传递协议，例如 amqp 和 mtqp 支持双工通信模式。 IIRC rabbit 只是用 erlang 编写的 amqp 的实现。许多消息传递平台不支持这两种协议，而只是哑管道。对于这样的平台，需要在上面构建此功能。