開源反向Ajax庫：事件驅動的Web開發

本 系列 文章向您展示如何使用反向 Ajax HTTP://www.aliyun.com/zixun/aggregation/7332.html">技術開發事件驅動的 Web 程式。 第 1 部分 介紹了反向 Ajax、輪詢、流、Comet 和長輪詢。 第 2 部分 介紹了如何使用 WebSocket，還討論了使用 Comet 和 WebSocket 的 Web 服務器的限制。 第 3 部分 探討了當您需要支援多個伺服器或提供一個使用者可以自己的伺服器上部署的獨立 Web 應用程式時，您實現自己的 Comet 或 WebSocket 通信系統的過程中會遇到的一些困難。 第 3 部分還討論了 Socket.IO。 第 4 部分 介紹了 Atmosphere 和 CometD，它們是用於 JAVA 伺服器的最有名的開放源碼反向 Ajax 庫。

此前，您已經瞭解了如何通過事件創建元件。 在本系列最後一部分中，會應用到事件驅動開發原則，並構建一個事件驅動的 Web 應用程式示例。

先決條件

在理想的情況下，如果想最大限度地利用本文，您應該瞭解 JavaScript 和 JAVA。 要運行本文中的示例，則需要使用最新版的 Maven 和 JDK。

術語

您可能熟悉事件驅動架構 (EDA)、EventBus 系統、消息傳遞系統、複雜事件處理 (CEP) 以及通道。 這些術語和概念已存在多年。 隨著技術越來越成熟，您可能會更多地聽到它們。 本節將簡要解釋這些概念。

事件 系統中發生的事情。 事件通常擁有一些屬性，比如發生日期（時間戳記）、源或位置（我們按一下的元件）以及一些事件描述資料。 根據不同的系統，事件還可以擁有其他屬性。


事件處理架構 (EDA) 也稱為基於事件程式設計，這是一種架構設計模式，在這種模式中，應用程式包含一些元件，元件通過收發事件進行通信和執行操作。 JAVA Swing 圖形化使用者介面 (GUI) 就是一個 EDA 示例。 每個 Swing 元件都可以執行監聽事件、做出反應、發送其他事件等操作。 EDA 包括幾個組成部分：事件生成者、事件消費者、事件以及處理軟體。 事件生成者：該元件用於發出事件。 在本文的示例中，一個表單提交按鈕就是一個事件生成者。 事件消費者：該元件用於監聽特定事件。 例如，在表單提交示例中，瀏覽器將監聽表單提交按鈕上的按一下事件，以便向伺服器發送表單資料。 事件處理軟體：這是事件生成者發佈事件和事件消費者註冊自己以接收事件的系統內核。 根據不同的軟體，處理過程可能很簡單（只是將生成的事件轉發到消費者），也可能很複雜（比如 CEP）。 在使用 CEP 時，該軟體支援各種處理方式，比如事件匯總、過濾和轉換。

Esper 就是這樣一個軟體。 事件處理軟體不僅可以是獨立運行的應用程式，還可以是應用程式中集成的庫。

消息傳遞系統 一種事件驅動應用程式，其中，事件生成者將消息發佈到通道，事件消費者訂閱通道。 事件生成者和消費者之間沒有連結，完全獨立。 在這種事件驅動應用程式中，通常使用術語消息，而不是事件。


通道 消息傳遞系統中的事件的一種歸類方法。 通道表示事件生成者希望事件發送到的目標位置。 例如，在一個聊天室應用程式中，通道可能是 /chatapplication/chatrooms/asdrt678。 這個通道將標識一個聊天室，事件生成者可以在其中發送消息，圖形元件可以訂閱該聊天室，以顯示新到達的消息。

某些消息傳遞系統提供兩種通道：佇列和主題。

佇列：在將消息發送到佇列時，只有一個事件消費者能夠接收並處理它。 其他消費者看不到它。 佇列可以是持久性的，以保障消息交付。 最好的佇列示例可能是一個郵件請求。 在使用者進行註冊的時候，Web 應用程式會將一條消息發佈給佇列 /myapp/mail/user-registration。 可能有幾個郵件應用程式訂閱該佇列。 即使沒有，消息也不會丟失。 主題：在將消息傳送到主題時，每個訂閱者都會接收到相關消息。 主題通常不是持久性的。 針對監視軟體的主題的一個是 /event/system/cpu/usage，其中一個生成者會定期發送 CPU 的使用方式。 另一方面，可能有很多訂閱者，也可能完全沒有訂閱者，這主要取決於訂閱者的興趣。 發佈/訂閱 事件驅動解決方案實現了 「發佈/訂閱」 模式。 事件生成者在處理軟體中發佈事件，事件消費者通過訂閱來接收事件。 事件消費者的訂閱者式取決於軟體。 在消息傳遞應用程式中，事件消費者可以訂閱通道（例如，也可以在事件種類上應用過濾規則）。 在使用 CEP（比如 Esper）時，可以通過一個 SQL 類請求來實現訂閱，從而定義您感興趣的事件。

為何使用事件驅動解決方案？

在傳統通信方案中，如果系統 A 需要系統 B 中的資訊，它會向系統 B 發送一個請求。 系統 B 將處理請求，而系統 A 會等待回應。 處理完成後，會將回應發送回系統 A。 在同步 通訊模式下，資源使用效率比較低，這是因為等待回應時會浪費處理時間。

在非同步 模式下，系統 A 將訂閱它想從系統 B 中獲取的資訊。 然後，系統 A 可以向系統 B 發送一個通知，也可以立即返回資訊，與此同時，系統 A 可以處理其他事務。 這個步驟是可選的。 在事件驅動應用程式中，通常不必請求其他系統發送事件，因為您不知道這些事件是什麼。 在系統 B 發佈回應之後，系統 A 會立即收到該回應。

事件驅動架構的一個好處是它允許實現更好的可伸縮性。 可伸縮性 是系統在適應需求、量和強度方面的變化的情況下仍能實現目標的能力。 通過消除暫停時間，使得事件驅動架構擁有更好的性能和更高的處理比率。

另一個好處在於應用程式開發和維護。 在使用事件驅動解決方案時，每個應用程式元件都可以去除耦合，完全獨立。

由於通信延遲減少，事件驅動解決方案能夠在更短地時間內進行回應。