我正在为项目开发微服务，我们正在尝试使用AWS SNS + SQS进行pub-sub通信。我们不确定如何向服务发出信号，无论其他服务是否成功完成任务 例如，如果服务A发出SNS事件并且服务D，E和F都在监听订阅的SQS队列，那么服务A如何知道服务A，服务D，E和F内的服务A启动的活动是成功？
我将举一个更具体的例子：
新用户注册网站。此网络呼叫首先到达后端的user service。如果用户成功，则会发送一个表示已创建新用户的事件。这会触发email service发送电子邮件给用户以确认其注册。如果它无法发送电子邮件会怎么样？
有user service：
1）已经回应了前端说它成功了
2）还是在等待确认？什么是确认的好的pub-sub模式？
我知道我们可以做一个同步调用，但为了简洁起见，这个例子已经简化了。
答案 0 :(得分：2)
正如@dbugger在评论中所说，您可以让订阅者向发布者发送回复或其他内容。
但是，出版商有责任确保订阅者收到活动吗？
发布活动的重点是发布者不需要（并且不应该）了解订阅该活动的消费者的状态，订阅者是否忽略了该消息，或者即使没有订阅者。
如果发布者确实需要知道，那么发布者应该以请求 - 响应模式而不是事件直接向消费者发送命令，而不是事件。
这是因为命令消息假定接收者的知识，而事件消息假定不知道。
在事件到达时从自上而下的角度了解：嗯，您应该使用可以保证事件传递的持久消息传输，但即使具有持久性，您仍然可以丢弃消息。
唯一真正的做法是实施某种仪器，让您跟踪对话＆＃34;在从一个地方到另一个地方发布的事件中编码。有可用的工具（我只使用了一个，用于称为ServicePulse的NServicebus。）