我發(fā)現(xiàn)人們可能會混淆什么是事件代理，什么是消息代理。事件代理可以用來代替消息代理，但消息代理不能完全實現(xiàn)事件代理的功能。下面深入比較一下它們。

消息代理擁有悠久的歷史并已被許多組織用于大型的面向消息中間件架構(gòu)。消息代理使得系統(tǒng)可以通過發(fā)布/訂閱消息隊列進行網(wǎng)絡(luò)通信。生產(chǎn)者將消息寫入隊列，而消費者會消費這些消息并進行相應(yīng)的處理。然后，消息在消費時得到應(yīng)答，并立即或在之后不久被刪除。消息代理被設(shè)計為處理與事件代理不同類型的問題。

事件代理是圍繞提供有序的事實日志而設(shè)計的。事件代理滿足消息代理無法滿足的兩個非常具體的需求。首先，消息代理只提供消息的隊列，消息的消費是基于每個隊列進行處理的。共同消費一個隊列的應(yīng)用程序只能接收到記錄的一個子集。這就無法通過事件來正確地傳遞狀態(tài)，因為每個消費者都無法獲得所有事件的完整副本。與消息代理不同，事件代理維護著一個單獨的記錄總賬，并通過索引管理每個單獨的訪問，因此每個單獨的消費者能夠訪問所有必需的事件。此外，消息代理會在應(yīng)答之后刪除事件，而事件代理會根據(jù)組織的需要保留它們。消費后刪除事件使得消息代理不足以向所有應(yīng)用程序提供無限期存儲、全局可訪問、可重放和單一的事實來源。

事件代理支持一個不可變的追加日志，以保留事件順序的狀態(tài)。消費者可以在任何時候從日志中的任何位置提取數(shù)據(jù)并進行重新處理。此模式對于啟用事件驅(qū)動型微服務(wù)是必不可少的，但消息代理無法提供。

請記住，消息代理中使用的隊列在事件驅(qū)動型微服務(wù)中仍然扮演著一定的角色。隊列提供了有用的訪問模式，但在使用嚴格分區(qū)的事件流時可能難以實現(xiàn)。對于事件驅(qū)動型微服務(wù)架構(gòu)來說，消息代理系統(tǒng)引入的這些模式當然有效，但它們不足以實現(xiàn)此架構(gòu)所需的全部職責。本書剩余部分不會聚焦于消息代理架構(gòu)或應(yīng)用程序設(shè)計，而會聚焦于事件驅(qū)動型微服務(wù)架構(gòu)中事件代理的使用。

從不可變?nèi)罩局邢M

雖然不是一個明確的標準，但通常可用的事件代理使用一種只追加的不可變?nèi)罩?。事件被追加到日志尾部并分配一個自增的索引 ID。數(shù)據(jù)消費者使用索引 ID 的引用來訪問數(shù)據(jù)。然后，可以依據(jù)業(yè)務(wù)需要和事件代理能夠提供的功能，以事件流或隊列的形式消費事件。

01. 以事件流形式消費

每個消費者負責更新自己的指針，該指針指向事件流中之前讀取數(shù)據(jù)的索引。這個索引稱為偏移量，是從事件流開始處到當前事件的度量。偏移量允許多個消費者相互獨立地消費并跟蹤它們的進度，如圖 2-6 所示。

消費者組允許將多個消費者視為同一個邏輯實體，并可用于消息消費的橫向擴展。新的消費者加入消費者組中會導(dǎo)致事件流分區(qū)指派的重新分配。新的消費者僅從分配給它的分區(qū)中消費事件，就像組中之前的舊消費者實例僅從分配給它們的分區(qū)中消費事件一樣。通過這種方式，在同一個消費者組內(nèi)可以平衡事件的消費，同時確保給定分區(qū)的所有事件是由單一的消費者實例獨占消費的。在消費者組內(nèi)激活的消費者實例數(shù)量受限于事件流中的分區(qū)數(shù)量。

02. 以隊列形式消費

在基于隊列的消費中，每個事件僅被一個微服務(wù)實例所消費。一旦被消費，該事件就被事件代理標記為“已消費”并不再提供給任何其他消費者。當以隊列形式消費時，消費者數(shù)量與分區(qū)數(shù)量就變得沒有耦合性，因為任意數(shù)量的消費者實例都能用于消費。

當以隊列形式進行處理時，事件順序是無法保證的。并行的消費者無序地消費和處理事件，同時單個消費者可能在處理一個事件時失敗，進而將其放回隊列以待后面再處理，然后就繼續(xù)消費接下來的事件了。

不是所有的事件代理都支持隊列。例如 Apache Pulsar 目前支持隊列，Apache Kafka 則不支持。圖 2-7 展示了使用單獨的偏移量應(yīng)答的隊列的實現(xiàn)。

提供單一事實來源

持久和不可變的日志為單一事實來源提供了存儲機制，事件代理成了服務(wù)消費和生產(chǎn)數(shù)據(jù)的唯一位置。這樣，每個消費者都能獲得一份完全相同的數(shù)據(jù)副本

采用事件代理作為單一事實來源需要組織進行一次文化轉(zhuǎn)變。之前團隊可能只需編寫直接的 SQL 查詢語句來訪問單體數(shù)據(jù)庫中的數(shù)據(jù)，而現(xiàn)在團隊還必須把單體數(shù)據(jù)發(fā)布到事件代理上。管理單體數(shù)據(jù)庫的開發(fā)者必須確保生成的數(shù)據(jù)是完全正確的，因為事件流和單體數(shù)據(jù)庫之間的任何不一致都會被認為是生產(chǎn)團隊的事故。數(shù)據(jù)消費者不再直接耦合于單體數(shù)據(jù)庫，而是從事件流中進行消費。

采用事件驅(qū)動型微服務(wù)可以創(chuàng)建只使用事件代理進行存儲和訪問數(shù)據(jù)的微服務(wù)。雖然微服務(wù)的業(yè)務(wù)邏輯肯定會使用事件的本地副本，但事件代理仍然是所有數(shù)據(jù)的唯一事實來源。

好了，這篇文章的內(nèi)容發(fā)貨聯(lián)盟就和大家分享到這里，如果大家網(wǎng)絡(luò)推廣引流創(chuàng)業(yè)感興趣，可以添加微信：80709525  備注：發(fā)貨聯(lián)盟引流學(xué)習(xí)； 我拉你進直播課程學(xué)習(xí)群，每周135晚上都是有實戰(zhàn)干貨的推廣引流技術(shù)課程免費分享！