2013-08-23 32 views
10

我目前正在開發允許控制和監視某些物理設備的REST服務。使用ServiceStack實現WebHook

相應的REST API主要基於以下文章中的原理和想法:「Controlling and Monitoring Devices with REST」。

監控和控制的設備可以生成一些客戶必須能夠訂閱的事件。我的想法是使用RESTful WebHooks來實現該部分。

因此,無論什麼時候發生事件,我的服務都會爲每個訂戶創建一個REST API回調以通知它。

我的問題,現在:

什麼是實現使用ServiceStack(版71年3月9日)這種情況下正確的方法是什麼?

我的服務必須能夠將訂閱排隊並向訂閱者分派事件。它還必須處理客戶關閉或無法訪問的情況,並且可能會重試發送通知。

我是否必須從頭開始實施一切(例如,使用ServiceStack託管的RedisMqServer),還是已經有一些東西在我的方向上進一步發展了?我搜索一下沒有太大的成功。

回答

5

我相信你從錯誤的一端接近解決方案。你絕對可以使用ServiceStack來進行Web Hook調用 - 最好使用JSON。

你真正應該尋找到的消息隊列,因爲他們表現出所有的特徵,你將需要實現網絡掛接電話(持久性,消息清除策略,短信過濾,提供策略,路由策略,排隊條件)

Read more about the properties of message queues on Wikipedia

工作流事件會跟進的地步,一個Web掛鉤被稱爲:

  1. 的事件在系統中發生;爲確保Web Hook將被調用,您必須持久排隊處理事件(通過服務總線,如RabbitMq,MassTransit,NServiceBus等)。讓我們把目標隊列EventsQueue
  2. 該應用程序將隨後連接到EventsQueue和處理消息:
    1. 找出誰訂閱了這個特定的事件
    2. 對於用戶排隊一個新消息包含事件數據和訂戶詳細信息(例如回調URL)的複製到WebHookQueue並具有初始生存時間(消息有效期限)
  3. 然後,應用程序將連接到WebHookQueue並通過回調來處理消息。

所以現在你有一個基本的通知系統,應該確保一個消息至少被傳遞一次。

Here's a great article detailing how to use TTL (Time To Live) to retry messages at intervals

我會採取一些不同的辦法:

  • 創建不同的重試級隊列(如WebHookRetryQueue = WebHookQueue的死信隊列,WebHookRetryLvl1Queue = TTL 5分鐘,WebHookRetryLvl2Queue = TTL 15分鐘)。關鍵是要設置這些重試級隊列死信隊列到WebHookQueue排隊到期假消息(意思是一次一個消息在重試級隊列到期,它的排隊回WebHookQueue)。
  • 你會那麼需要在郵件跟蹤當前重試水平WebHookRetryQueue然後排隊上適當的重試級隊列中的消息 - 此後TTL過期,被插回WebHookQueue

實施例的工作流:WebHookQueue與最大重試次數:2,TTL:每日1

實施例消息:{ 'EVENT_TYPE': 'Email_Reply', 'callback_url':」 ... ','reply_level':0,'queued_at':'2013-09-25T22:00:00Z',data:'json encoded'}

Message - > WebHookQueue(fail) - > WebHookQueue(fail) - > WebHookRetryQueue(incr。reply_level = 1 + enqueue) - > WebHookRetryLvl1Queue(5分鐘過期) - > WebHookQueue(失敗) - > WebHookQueue(失敗) - > WebHookRetryQueue(incr。 reply_level = 2 +排隊) - > WebHookRetryLvl2Queue(15分鐘-到期) - > WebHookQueue(失敗) - > WebHookQueue(失敗) - > WebHookRetryQueue(降消息)


編輯

Click here to look at simple example using a WebHookQueue and a WebHookRetryQueue using message level TTL's of RabbitMQ.由於到消息級TTL的;沒有必要創建不同的重試級別隊列 - 這對於功能較少的消息隊列可能是必需的。


如果你不得不實施與到期的個人信息(不通過清除策略)的選項提前或調度消息重新安排的能力,這樣的隊列/到期 - 你最有可能不得不選擇用於基於數據庫的排隊。

Here's a great article on CodeProject on building such a high performance queue for MSSQL Server(移植到其他數據庫如MySQL/PostgreSQL的/的MongoDB/Couchbase等與努力)

希望您發現此信息非常有用。

1

ServiceStack.Webhooks是一個新的框架,可以輕鬆將webhook添加到您的服務中,而不管您要使用哪種架構模式。 你可以建立自己的插件。