處理事件

當(dāng)使用多個(gè)解耦的服務(wù)時(shí)（例如，在微服務(wù)體系結(jié)構(gòu)中 ），很有可能需要一種將某種域事件從一個(gè)服務(wù)發(fā)布到一個(gè)或多個(gè)其他服務(wù)的方法。

許多廣泛采用的解決方案依賴于單獨(dú)的基礎(chǔ)結(jié)構(gòu)來解決此問題（例如事件總線或消息隊(duì)列）。

活動(dòng)提要

解決此問題的另一種方法是使用提要 。 RSS或ATOM之類的提要通常用于訂閱網(wǎng)頁。 每當(dāng)將新文章發(fā)布到訂閱的網(wǎng)頁時(shí)，提要閱讀器應(yīng)用程序（例如，瀏覽器加載項(xiàng)或移動(dòng)應(yīng)用程序）都可以將新文章通知用戶。 提要閱讀器通常會(huì)定期輪詢提供的提要端點(diǎn)，以查看是否有新文章。

可以使用提要將事件發(fā)布到其他服務(wù)，而不是將新文章發(fā)布到RSS閱讀器。 除了用于存儲(chǔ)事件（您可能已經(jīng)擁有）的標(biāo)準(zhǔn)數(shù)據(jù)庫之外，這不需要任何其他基礎(chǔ)結(jié)構(gòu)。

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

具有兩個(gè)已發(fā)布域事件的示例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" } } ] }

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

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

一般注意事項(xiàng)

如果您使用JSON Feed或使用自己的Feed格式，則在構(gòu)建用于發(fā)布事件的Feed時(shí)應(yīng)考慮以下一些常規(guī)事項(xiàng)：

提要項(xiàng)是不可變的

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

Feed項(xiàng)目訂單未修改

提要中項(xiàng)目的順序不變。 較新的項(xiàng)目會(huì)附加到Feed的末尾。

客戶應(yīng)該只能請(qǐng)求到目前為止尚未處理的提要項(xiàng)。

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

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

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

當(dāng)然，您可以想出不同的方法來達(dá)到相同的結(jié)果。

和性能？

顯然，從性能的角度來看，提要不能與任何高吞吐量的消息傳遞解決方案競(jìng)爭(zhēng)。 但是，我認(rèn)為對(duì)于許多用例來說就足夠了。 如果它降低了系統(tǒng)的復(fù)雜性，那可能是一個(gè)值得權(quán)衡的問題。

要考慮的事情是：

• 服務(wù)器創(chuàng)建的事件數(shù)
• 訂閱者人數(shù)
• 與事件關(guān)聯(lián)的數(shù)據(jù)量
• 事件發(fā)布和處理之間的可接受延遲。 這定義了訂戶的輪詢間隔

由于域事件具有不變性，因此可以在服務(wù)器上選擇事件緩存來減少數(shù)據(jù)庫查找。 長輪詢和條件GET請(qǐng)求是減少網(wǎng)絡(luò)負(fù)載的可能選項(xiàng)。

結(jié)論

提要提供了一種使用REST API將事件發(fā)布到其他系統(tǒng)的替代方法，除了用于存儲(chǔ)事件的數(shù)據(jù)庫之外，無需其他基礎(chǔ)結(jié)構(gòu)。 您可以使用JSON Feed等現(xiàn)有的Feed格式，也可以使用自己的自定義Feed格式。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。