處理事件

當使用多個解耦的服務時（例如，在微服務體系結構中 ），很有可能需要一種將某種域事件從一個服務發布到一個或多個其他服務的方法。

許多廣泛采用的解決方案依賴于單獨的基礎結構來解決此問題（例如事件總線或消息隊列）。

活動提要

解決此問題的另一種方法是使用提要 。 RSS或ATOM之類的提要通常用于訂閱網頁。 每當將新文章發布到訂閱的網頁時，提要閱讀器應用程序（例如，瀏覽器加載項或移動應用程序）都可以將新文章通知用戶。 提要閱讀器通常會定期輪詢提供的提要端點，以查看是否有新文章。

可以使用提要將事件發布到其他服務，而不是將新文章發布到RSS閱讀器。 除了用于存儲事件（您可能已經擁有）的標準數據庫之外，這不需要任何其他基礎結構。

RSS和ATOM都是XML格式，因此如果我們要提供JSON API，則不合適。 還有JSON Feed ，類似于RSS和ATOM，但使用JSON。 像RSS和ATOM一樣，JSON Feed專注于網站內容，因此，許多（可選）提要和提要項屬性對于發布域事件（例如favicon ， content_html ， image ， banner和附件 ）不是很有用。 但是，JSON Feed具有簡單的擴展機制，可讓我們在Feed中定義自定義字段。 這些字段必須以下劃線開頭。 如果JSON Feed不符合您的需求，您還可以提出自己的feed格式，這應該不難。

具有兩個已發布域事件的示例JSON Feed可能如下所示：

{ "version" : " https://jsonfeed.org/version/1 " , "title" : "user service events" , "feed_url" : " http://userservice.myapi.com/events " , "next_url" : " http://userservice.myapi.com/events?offset=2 " , "items" : [ { "id" : "42" , "url" : " http://userservice.myapi.com/user/123 " , "date_published" : "2020-05-01T14:00:00-07:00" , "_type" : "NameChanged" , "_data" : { "oldName" : "John Foo" , "newName" : "John Bar" } }, { "id" : "43" , "url" : " http://userservice.myapi.com/user/789 " , "date_published" : "2020-05-02T17:00:00-03:00" , "_type" : "UserDeleted" , "_data" : { "name" : "Anna Smith" , "email" : "anna@smith.com" } } ] }

第一個事件（ID為42 ）指示用戶資源/ user / 123的名稱已更改。 在_data塊中，我們提供了一些可能對訂戶有用的附加事件信息。 第二個事件表示資源/ user / 789已被刪除， _data塊包含已刪除的用戶數據。 _type和_data未以JSON Feed格式定義，因此以下劃線（JSON Feed擴展格式）開頭。

提要屬性next_url可用于提供某種分頁。 它告訴客戶端在當前提要中的所有事件都已處理后，在哪里可以查找更多事件。 我們的提要僅包含兩個事件，因此我們告訴客戶端使用偏移量參數2調用提要端點以獲取下一個事件。

一般注意事項

如果您使用JSON Feed或使用自己的Feed格式，則在構建用于發布事件的Feed時應考慮以下一些常規事項：

提要項是不可變的

提要項表示域事件，它們是不可變的。 必要時，客戶可以使用唯一的Feed項目ID來檢查他們是否已經處理過Feed項目。

Feed項目訂單未修改

提要中項目的順序不變。 較新的項目會附加到Feed的末尾。

客戶應該只能請求到目前為止尚未處理的提要項。

為了避免客戶需要一遍又一遍地處理所有提要項以查看是否有新項（例如，通過檢查date_published項屬性），提要應提供一種僅返回新項的方法。 使用JSON Feed時，可以通過next_url屬性完成。

下圖試圖顯示可能的next_url行為：

在第一個Feed請求中，只有兩個事件可用。 兩者均由服務器以及包含偏移量參數2的next_url一起返回。客戶端處理完兩個提要項目之后，客戶端將使用偏移量2請求下一個項目。沒有新項目可用，因此沒有內容的空提要服務器返回一個新的next_url 。 客戶端會記住先前的next_url，并在稍后再重試該請求。 這次返回的是新項目，其更新的next_url包含偏移量 3。

當然，您可以想出不同的方法來達到相同的結果。

和性能？

顯然，從性能的角度來看，提要不能與任何高吞吐量的消息傳遞解決方案競爭。 但是，我認為對于許多用例來說就足夠了。 如果它降低了系統的復雜性，那可能是一個值得權衡的問題。

要考慮的事情是：

• 服務器創建的事件數
• 訂閱者人數
• 與事件關聯的數據量
• 事件發布和處理之間的可接受延遲。 這定義了訂戶的輪詢間隔

由于域事件具有不變性，因此可以在服務器上選擇事件緩存來減少數據庫查找。 長輪詢和條件GET請求是減少網絡負載的可能選項。

結論

提要提供了一種使用REST API將事件發布到其他系統的替代方法，除了用于存儲事件的數據庫之外，無需其他基礎結構。 您可以使用JSON Feed等現有的Feed格式，也可以使用自己的自定義Feed格式。

由于提要的輪詢性質，如果您有大量事件和很多消費者，則此解決方案可能不是最佳選擇。

翻譯自: https://www.javacodegeeks.com/2020/05/rest-using-feeds-to-publish-events.html

總結

以上是生活随笔為你收集整理的REST /使用提要发布事件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。