我们应该在消息栈中使用pub/sub吗？
基本上这个问题是多种多样的，“我能检查一下我们不会做什么蠢事吗？”
我们正在建立一个新的系统来保证电子邮件的发送。
我们有一个处理金融事务的现有系统，我们希望将它与发送收据(它目前正在处理的收据)分离开来，因此我们正在设置第二个服务来卸载发送收据。电子邮件服务是完全独立的，它有自己的数据库，只是接收来自金融系统的事件来告诉它发送什么电子邮件。
最初，我们想使用一个酒吧/潜艇(可能是谷歌的)来进行系统之间的通信。
但是，当我们设计围绕它的系统时，我们意识到电子邮件系统中的工作流程只是简单地将信息从pub/sub中删除，并将它们放到Postgres表中，然后通过发送电子邮件来完成另一个过程。
我们在发布端也有消息的缓冲，因为尽管google /sub非常可靠，但它可能不是100%。
因此，我们想知道为什么我们甚至需要酒吧/潜艇，为什么不只是有一个webhooks系统，而让金融系统的消息工作人员在电子邮件系统上的网页钩子呢？
考虑到pub/sub是解决这类问题的一种常见的设计模式，我担心在我们的思维中遗漏了一些东西？
业绩似乎是显而易见的原因，但鉴于金融系统必须做到以下几点：
- 将事务放在它的数据库中
- 与支付网关联系
- 将交易标记为已支付
- 在DB中发送消息的队列
(然后一个工作人员打开消息队列并点击web钩子)
而电子邮件服务中的webhooks进程只需
- 将消息事件放到数据库中(让工作进程负责处理该事件)
在我看来，金融系统永远不可能以足够快的速度在电子邮件服务上超载网络钩子。处理事务应该始终是一个更大的瓶颈。
回答 1
Software Engineering用户
发布于 2017-11-09 06:47:47
大约一个月前，我编写了一个类似的系统，就像您一样，我发现最好通过一个可靠的队列技术重新驱动来解决这个问题。
虽然有些人可能认为使用SQL作为队列并不是最可靠的方法，但在许多情况下，它确实有效。
使用pub-sub系统的原因是当您需要从一个事件中发生多个不同的事情时。如果您从一次交易中发送了两封不同的电子邮件，那么您可能有一个系统
|====| |====| => [UserEmail Sub]
|Tran| => |=Pub|
|====| |====| => [ReceiptEmail Sub]但即使如此，这些小Sub组件也只会将不同的数据排队到队列机制上，最终会有多个故障转移的工作进程从数据集中提取数据并发送实际的电子邮件。
https://softwareengineering.stackexchange.com/questions/360488
复制相似问题
腾讯云开发者
