【发布时间】：2017-05-23 19:12:30
【问题描述】：
例如，我想要一个微服务来发送通知（电子邮件、短信、推送通知）。对于少数用户来说一切都很好。一段时间后，我们的应用程序有很多用户，所以，这个微服务不管理，并在 1 小时后发送电子邮件。
那么，如何处理这种情况呢？部署另一个微服务实例，但是如何处理只有一个微服务处理一封邮件而用户收不到多封邮件？
【问题讨论】：
标签： cron scalability microservices
【发布时间】：2017-05-23 19:12:30
【问题描述】：
需要为此设置消息传递。
通常使用持久队列，例如 RabbitMQ。然后负责发送电子邮件的微服务使用队列中的消息并适当地处理它们。
如果您遇到单个电子邮件微服务实例不够用的问题，您可以简单地分叉另一个实例并立即部署它。这是因为当消息队列中的消息被消费时，除非您告诉它返回（重新排队），否则它就消失了。 IE。任何成功发送的电子邮件都会消耗该消息，因此发送电子邮件的请求不再在系统内。
【讨论】：
-
但是谁将消息放入队列？例如，如果存在确定要发送电子邮件的后台任务，则将“发送电子邮件消息”放入队列。但是如果这个服务有多个实例，那么同一个消息会被多次放入队列，因此同一个邮件会被多次发送。
1) 您可以创建协调服务，该服务将使用数据库表等持久存储为发送者安排任务。该服务会将发送作业记录添加到表中，发送者服务将在循环中扫描表获取作业，并将其标记为正在处理，这样其他实例就不会得到相同的作业。
2) 您可以使用 Azure ServiceBus 等队列从协调服务发送作业。
此外，如果您使用的是微服务，我建议您通过传输分隔发送服务，以便您可以单独扩展它们。
我可以看到下一个结构：
NotificationSenderService - 发送协调器通常只需要一个实例。该服务的职责是接收发送通知请求并使用队列或数据库创建作业
EmailNotificationService、SMSNotificationService、PuthNotificationService - 实际发件人。您可以根据需要运行每个实例的多个实例。他们需要访问 NotificationSenderService 的数据库或队列。
【讨论】：
-
它并没有真正解决 OP 提出的问题。万一发件人服务规模扩大，会导致将数据复制到通知服务。更糟糕的是，通知也可以复制以提供大量数据。