2016-03-15 75 views
1

我們剛搬到我們的一些工作負載的天青對此我目前管理的,我讀了一些關於服務總線,並想知道如果我可以用它來排隊的郵件在託管使用蔚藍servicebus排隊郵件

應用雖然自定義庫的使用將把他們的電子郵件發送到服務總線隊列,其中一個或多個工作進程將從隊列中選擇消息並通過郵件中繼服務發送。

這將釋放從郵件中繼服務,我使用在任何時候的細節我的開發人員和我也可以發送不含開發商改變他們的代碼之前執行的消息的進一步處理。

我的問題是,這是可能的,如果是,是可取的,有什麼我需要提防實現這樣的解決方案時。任何指導如何做到這一點也不勝感激

+0

是的,這是可能的,你到現在爲止嘗試過什麼?它只是一個處理工作量的排隊系統。 – Peter

+0

我還沒有嘗試過,只是習慣了天藍色的基礎設施,我只想知道它是值得付出的努力還是它的死衚衕。我也想知道它是不是一個好主意 – araoko

回答

1

是的,將消息添加到Azure服務總線隊列是一個合理的解決方案,稍後由應用程序根據排隊消息中的詳細信息檢索併發送電子郵件。這是一種使用微服務方法分離各種應用程序以提供電子郵件發送服務的好方法,可以在單個應用程序的不同部分中使用電子郵件發送服務,甚至可以在組織內的許多應用程序中使用該服務。

有一點要注意的是,在Azure的服務總線隊列中的郵件大小確實有一個最大大小限制。根據電子郵件中發送的內容的長度,您需要將郵件的詳細信息存儲在某處,可能是數據庫或Azure表存儲。然後隊列中的消息將包含一個標識符,例如GUID,可用於稍後在接收應用程序處理它發送電子郵件時查找消息詳細信息。無論隊列中的按摩大小,電子郵件可能會變得很長,所以使用這種方法可能是您的最佳選擇,因此您稍後將不會遇到問題。

+0

你知道序列化MailMessage對象的有效方法嗎?我想要一個情況,這個庫的用戶將像通常那樣創建郵件消息,但是通過庫發送,到目前爲止我看到的所有實現都涉及使用.net類的內部方法,可以隨時更改首先將對象序列化到磁盤,然後讀取它可能會影響性能。 – araoko

+0

@araoko序列化MailMessage不是我曾經嘗試過的。我不會推薦這個。電子郵件消息可能相當長,並且比服務總線隊列消息的可用消息大小更容易使用。我建議您創建類似於MailMessage的類,然後使用隊列消息中的指針將其存儲在Table Storage中。 –

+0

我想按照您的建議將MailMessage序列化爲blob存儲,並在隊列上傳遞指向它的指針。如果我創建自己的班級,這意味着所有現有的代碼將改爲使用我的班級,我寧願作爲最後的手段。 – araoko

0

這是可能的,這是不錯的選擇。大多數電子郵件服務在其系統中使用隊列。

您可以使用隊列priority property。交易郵件>通知郵件>營銷郵件,您可以從高到低排列。因爲隊列工作FIFO和事務郵件不應該等待營銷郵件。

您可以使用Labels區分的消息,implemantation之前。

如果您在某些嘗試之後無法發送電子郵件(Azure的默認值爲10)。你應該把它移動到死隊列天藍色的服務總線爲你做這個。但是,您應該使用deadqueue來處理此電子郵件。

0

不知道你的系統要求,需要在消息隊列VS什麼,我會說以下。

  • 如果您的應用程序需要消息傳遞,那麼請繼續並使用Azure服務總線來排隊電子郵件。
  • 如果答案爲「否」,請使用單獨排隊的東西:Azure存儲隊列。