2017-01-20 57 views
1

問題:發送電子郵件與Azure的功能

因此,我們正在爲我們的應用程序一個通訊系統,該系統必須發送20K-40K的電子郵件多達每天數次能力。

偏好的工具:

  1. 亞馬遜SES - 定價和可擴展性
  2. Azure的功能 - 無服務器計算髮送電子郵件

亞馬遜SES的侷限性:

  1. 亞馬遜SES節流具有最大發送速率 - 亞馬遜SES節流通過施加最大發送速率通過其服務發送。現在,出於沙箱SES環境,我們的容量是每秒14封電子郵件,每天有50K封電子郵件。但是這個限制可以通過支持票證來增加。

限制Azure的功能:

  1. 在一個消費計劃,有沒有辦法來限制其規模爲您的Azure的功能的多少實例執行。目前,縮放由Azure內部處理,因此該功能可以在幾個到幾百個實例之間執行。

  2. 從閱讀關於Azure函數的其他文章,Azure函數似乎有一個「熱身期」,這意味着函數可能無法在通過記錄的觸發器之一觸發時立即執行。 Azure的功能

限制與SES:

  1. 明顯的問題是亞馬遜SES節流發送從Azure的功能,電子郵件,因爲Azure的功能的比例執行發送一封電子郵件會遠高於SES允許的發送速率。

  2. 由於Azure函數消息的「預熱」期可能最終會堆積在一個隊列中,然後Azure函數實際開始按比例處理它們併發出電子郵件,因此很有可能點擊發送/速率限制。

問:

  1. 我們如何來利用通過Azure的功能發送電子郵件,同時在X電子郵件/ SES的第二個限制仍然?有沒有辦法限制Azure功能每次可以執行多少次?那麼就讓我們說我們不希望每秒鐘運行超過30個Azure函數實例?

其他的想法:

  1. 亞馬遜SES可能不喜歡爲客戶SES的持續限制,如果客戶實現不斷衝擊了該節流限制。亞馬遜SES人,請你評論?

  2. Azure函數 - 根據文檔,消費計劃中的Azure函數的擴展在內部處理。但是沒有辦法在縮放上加上手動「上限」嗎?從客戶的角度來看,這似乎是一個常見的要求。 問題不在於Azure函數無法處理負載,問題是系統中與Azure函數接口的其他組件無法在Azure函數可以處理的大規模負載中處理負載。

謝謝你的幫助。

+0

這是真的會成爲一個定製系統,並與我們的CMS緊密集成。所以我們不想依賴外部組件。 「數十億的電子郵件」聽起來非常吸引人......再次,亞馬遜SES會扼殺你。我們也是一個.NET/Azure商店,寧願只通過.NET API與其他雲提供商合作。謝謝你的建議。 – CloudDev

回答

1

如果我正確理解您的問題,最簡單的方法是自定義隊列限制解決方案。基本上你的AF只是檢索所有郵件請求的調用,然後將它們排隊到一個隊列系統中(比如說ServiceBus/EventHub/IoTHub),然後你可以擁有另一個Azure函數,它運行x分鐘的時間間隔,最多y個消息並將其推送到SES。您的控制點成爲該時鐘函數,並且由於隊列系統將幫助您確保知道您的消息傳遞狀態(已發送至SES),並且一旦完成就可以彈出隊列,這將允許您確保最終作業處理。

+0

這是一個很好的建議。我們已經想到這樣做。實際上有一種方法可以將消息排入隊列,並讓它們在特定時間出現在隊列中。所以我們可能會這樣做。仍然不是一個完美的解決方案,因爲會不時地發生限制性異常..但是對於隊列,我們​​可以通過不將該消息標記爲已處理並重新回來來重試。我投了你的建議..感謝你的時間:)希望亞馬遜和Azure的人可以評論..我很驚訝沒有人評論。 – CloudDev

0

您應該能夠在函數的host.json文件中將maxConcurrentCalls設置爲1;這將確保只有1函數執行在任何給定的時間內發生,並應該調節你的處理速度而言,從什麼角度AWS比較認同的每秒發送:

host.json

{ 
    // The unique ID for this job host. Can be a lower case GUID 
    // with dashes removed. When running in Azure Functions, the id can be omitted, and one gets generated automatically. 
    "id": "9f4ea53c5136457d883d685e57164f08", 
    // Configuration settings for 'serviceBus' triggers. (Optional) 
    "serviceBus": { 
     // The maximum number of concurrent calls to the callback the message 
     // pump should initiate. The default is 16. 
     "maxConcurrentCalls": 1, 
     ... 
相關問題