【问题标题】:using azure servicebus to queue emails使用 azure servicebus 对电子邮件进行排队
【发布时间】:2016-06-30 18:07:48
【问题描述】:

我们刚刚将一些工作负载转移到我目前正在管理的 azure 中,我阅读了一些关于服务总线的信息,想知道是否可以使用它来排队电子邮件

使用自定义库托管在 Azure 中的应用程序会将其电子邮件传送到服务总线队列,一个或多个工作进程将从队列中挑选消息,然后通过邮件中继服务发送。

这将使我的开发人员无需了解我随时使用的邮件中继服务的详细信息,而且我还可以在发送之前对消息进行进一步处理,而无需开发人员更改他们的代码。

我的问题是,这是否可行,如果可行,是否可取,在实施此类解决方案时我需要注意什么。任何有关如何做到这一点的指针也将不胜感激

【问题讨论】:

  • 是的,有可能,到目前为止您尝试过什么?它只是一个处理工作负载的排队系统。
  • 我没有尝试过,只是习惯了 azure 基础架构,我只是想知道它是否值得付出努力,还是死路一条。我也想知道这是不是个好主意

标签: email azure azureservicebus azure-servicebus-queues


【解决方案1】:

是的,将消息添加到 Azure 服务总线队列是一个合理的解决方案,这些消息稍后由应用程序检索,该应用程序会根据排队消息中的详细信息发送电子邮件。这是使用微服务方法解耦各种应用程序的好方法,以提供电子邮件发送服务,可用于单个应用程序的不同部分,甚至可以跨组织内的多个应用程序使用。

需要注意的一点是,Azure 服务总线队列中的消息大小确实有最大大小限制。根据电子邮件中发送的内容的长度,您需要将消息的详细信息存储在某个地方,可能是数据库或 Azure 表存储。然后,队列中的消息将包含一个标识符,例如 GUID,可用于稍后在接收应用程序处理消息以发送电子邮件时查找消息详细信息。无论队列中的消息有多大,电子邮件都会变得很长,因此使用这种方法可能是您的最佳选择,这样您以后在实施时就不会遇到问题。

【讨论】:

  • 您知道序列化 MailMessage 对象的有效方法吗?我希望这个库的用户会像往常一样创建邮件消息但通过库发送,到目前为止我看到的所有实现都涉及使用.net类的内部方法,并且可以随时更改先将对象序列化到磁盘,然后再读取它,这会影响性能。
  • @araoko 序列化 MailMessage 不是我尝试过的。我不会推荐这个。与服务总线队列消息的可用消息大小相比,电子邮件消息可能相当长并且很容易用完。我建议您创建自己的类似于 MailMessage 的类,然后使用队列消息中的指针将其存储在表存储中。
  • 我想按照您的建议将 MailMessage 序列化到 blob 存储,并在队列上传递一个指向它的指针。如果我创建自己的课程,这意味着所有现有代码都将更改为使用我的课程,我更愿意将其作为最后的手段。
【解决方案2】:

在不了解您的系统、要求、消息传递与排队的需要的情况下,我将在下面说。

  • 如果您的应用程序需要消息传递,那么请继续使用 Azure 服务总线来对电子邮件进行排队。
  • 如果答案是“否”,请使用仅用于排队的东西:Azure 存储队列。

【讨论】:

    【解决方案3】:

    这是可能的,也是不错的选择。大多数电子邮件服务在其系统中使用队列。

    您可以使用队列的priority property。 Transactional Mails>Notification Mails>Marketing Mails,您可以将优先级从高到低。因为队列工作先进先出,交易邮件不应该等待营销邮件。

    您可以在实现之前使用Labels 区分消息。

    如果您在某些尝试后无法发送电子邮件(Azure 的默认值为 10)。您应该将其移动到死队列 azure 服务总线会为您执行此操作。但是你应该使用deadqueue 来处理这些邮件。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2015-03-15
      • 2015-05-17
      • 1970-01-01
      • 1970-01-01
      • 2023-03-03
      • 2018-08-22
      • 1970-01-01
      相关资源
      最近更新 更多