基于 SOA 的大容量企業系統體系結構

研究支持基于面向服務的體系結構 (SOA) 的大容量企業系統的多層消息處理方法。本文說明了 WebSphere Application Server Version 6 如何用來優化 XML 的消息處理，以及如何使企業成為可持續的大容量操作環境。我們建立了一個獨特的體系結構視圖，它能夠引起那些關注于使用 SOA 和 Web 服務以實現高吞吐量的 J2EE 和 XML 技術讀者的共鳴。

引言

請您考慮一個問題："我的 SOA 環境的吞吐量給用戶帶來影響了么？如果答案是“是”，您并不是唯一碰到該問題的人。根據對全球 2000 強公司的幾項近期調查（包括 In-Stat/ Reed Elsevier Business Information Network and Summit Strategies, Inc 在 2005 年發布的報告），在金融服務、運輸、電信以及全球制造行業的調查對象中，百分之七十六的企業將吞吐量作為 2006 年開發和部署 SOA 驅動的企業軟件（尤其是使用 Web 服務）的工作中最關鍵的問題之一。

相同的調查對象說明了為什么吞吐量如此重要：業務需求要求以實時或非實時的方式來更新存儲，每秒鐘處理上千項服務請求 (SRS)，并在企業范圍以及全球擴展價值鏈中發送財務和訂單信息。除了大容量之外，基于 SOA 的解決方案常常需要允許以各種數據格式（如 ACORD、IFX 和 TINA）通過 HTTP 或 JMS 等多種協議進行消息轉換，處理高峰時期的瓶頸而不降低服務級別，并且提供全面的審核記錄。

服務請求者和服務提供者之間基于 XML 的信息交換是支持 SOA 技術（比如 Web 服務）的關鍵。XML 提供了重要的優點，但這些優點是以性能和吞吐量為代價的。

首先，使用 XML 編碼方式的消息比二進制編碼的消息平均要大六至八倍。并且它們還在不斷地增大，即信息交換中使用的是整個文檔（如附帶配送信息、信用報告、詳細地圖和產品目錄的購買訂單）。如今，大小超過 40K 字節的消息是很常見的。

其次，例如，與通過 RMI/IIOP 傳遞的數據和/或對象相比，將消息綁定到程序對象和數據操作時涉及到的 XML 編碼需要進行更多的計算。

通常最后的結果是，服務端點上的服務器可能無法處理 Web 服務網絡所要求的吞吐量。其代價就是服務請求丟失。

在大容量（SRS 超過 1000）的系統中，吞吐量問題尤為棘手，因為它需要多方面的解決方案，其中還將不斷出現許多組件。例如，業界正在開發一系列“快速 Web 服務”標準。這些標準嘗試通過定義消耗更少帶寬、更加快速且需要更少內存的基于二進制的消息來解決 XML 編碼的問題。

與此同時，目前在大容量和異構消息傳遞系統中確保高吞吐量的最常用的辦法是增加容量。

有幾種不同的增加容量的方法。第一種是由服務提供者（即服務端點端）增加可使用的物理資源。升級服務器（例如，使用功能更強大的支持更多 CPU 或者更快的芯片的硬件）或者添加額外的服務器（例如，水平擴展或者使用服務器集群）是最流行的做法，盡管所增加的重復軟件開銷和高昂的管理費用通常使得這些方法的開銷非常高。

另一種方法是使用垂直伸縮技術（比如 WebSphere® Application Server Network Deployment 引入的多單元模型）來擴展可用的應用程序服務器節點（映像）的數目。這種方法可能是有效的，但就其本身而言，它只是“提升”了 Web 服務消息處理容量（平均起來，吞吐量可能增加百分之二十五到三十五），而與現有的吞吐量級別相比，這并不是全方位的增加（許多倍以上）。這樣也許滿足了目前的工作負載需求，但長期的容量需求問題仍然存在。

那么，有沒有什么方法可以在水平和垂直伸縮的基礎上限制容量的增長呢？另外，目前有沒有可行的技術解決方案呢？幸運的是，這兩個問題的答案都是“有”。

高性能的面向消息的中間件 (MOM) 社區長期提倡合理地將消息處理任務分解為更小的相關聯的系統，以保證可伸縮性。這里的最終目標是創建一個優化的計算環境，它結合了傳統伸縮方法最佳的特點，即垂直或水平伸縮應用程序的能力以及在分布式方式中允許控制許多獨立進程的結構方法（如 XML 處理、訪問業務對象和訪問企業數據源），并部署為應用程序級消息處理程序的覆蓋網絡。

將精力集中于部分而非整體；或者說，進行分治處理。

目前大多數用于消息處理的 SOA 技術是在順序消息截獲模型的環境中開發的。Apache 的 Axis 或者類似的框架就是很好的例子，如圖 1 所示。

如圖 1 所示，Web 服務啟用程序是提供各種“通道”以訪問所需服務的抽象層。使用特定的通道對傳入的 XML 消息在其到達時進行評估，以確定目標服務?？赡苡卸鄠€“篩選器”，假如它們綁定于允許對請求消息和應答消息進行截獲和操作的目標服務，例如，將某種格式的消息轉換為其他新的格式。這些篩選器可能作為策略強制層，消息首先在這里經過安全和服務質量 (QoS) 檢查，然后排隊等待處理。

通道是連接到服務提供者的邏輯路徑。它也可以用作靜態“路由”開關。在 SOA 中，Web 服務啟用程序負責進行通道的選擇，并啟用服務基礎結構來更好地控制篩選器應用程序，比如 Axis 的 SOAP 處理程序鏈。

盡管因為可以為不同的協議（例如，從物理實現的角度來看，使用 HTTP 和 JMS）設計不同的通道，所以這種消息傳遞模型似乎創建了“分解的”消息，但從總體上看，所得到的體系結構本質上是整體的，因為它受到作為中心服務器或者類似配置的服務器集群的核心系統的完全支持。

為具有各種 XML 消息傳遞的大型目標信息受眾而設計的系統面臨著功能的高度非線性使用：在不同的時刻，有些功能（如轉換消息格式），和所有其他的功能相比只被少部分的工作負載所使用。大體說來，將所有的消息處理功能整合為一個核心平臺會帶來不必要地“過度使用”，這將會造成不合理的工作負載預期并增加了該平臺可伸縮性的挑戰。

XML 消息處理層的開發需要了解每個基礎服務組件，因此這種結構方法是不合適的。而應該采用分治處理的辦法，通過各個組件來解決相似的客戶需求，如安全強制或轉換，將這些組件劃分成組，并且將這些組獨立地部署到服務器網絡中。

簡單說來：將 XML 消息工作負載分段為“相似的”功能，并且根據功能段來使用處理資源，這對于產生穩定的響應時間是至關重要的，而且對于確?；?Web 服務的系統中高吞吐量級別也是必不可少的。

在 J2EE 體系結構中經常使用分段工作負載技術的應用程序。例如，分段通常直接應用于表示層（Web 服務器）和業務層，這些層次通常是分散的，并由不同的服務器提供支持。

但是，在大容量 Web 服務的環境中，需要在更細的粒度上進行分段，將消息處理分割為更易于優化的段，并因而提供更加穩定的伸縮和響應時間，即使這種技術可能需要更加復雜的服務管理機制。

當然，如果 XML 消息分段很簡單，那么現在就會更加普遍地使用了。該技術的一個問題就是如何實現分段。更為重要的是，該體系結構調用了截獲 XML 消息的多層方法。我們應該如何正確地去完成這項工作呢？同時，在分段工作負載之后，可能還需要平衡工作負載分段的附加基礎結構。這就帶來了另一個問題，即什么是進行面向分段的負載平衡的最有效的方案？下面的討論將會回答其中的部分問題，并提供了使用 SOA 消息傳遞來處理這些問題的提示和技巧。

消息處理模式

在 SOA 環境中，有兩種主要的用于進行 XML 消息處理的結構模式，如圖 2 所示：

• 消息攔截器網關模式，用于在 Web 服務層之前集中和協調 XML 消息相關的任務，它與 Facade 或者適配器模式相似，扮演了 Web 服務基礎結構“代理”（前端）的角色，在消息抵達服務端點之前進行安全強制或中介等執行大量消息處理的任務，換句話說，截獲進入服務的消息。
• 消息檢查器模式，用于在 Web 服務層中執行所有的 XML 消息相關的任務，換句話說，在消息到達服務之后對其進行處理。

消息攔截器網關模式常用來處理 Internet 和 Intranet 環境之間的 Web 服務調用。具體說來，要使得內部 Web 服務可以在企業范圍之外可用，或者要使得外部 Web 服務在內部系統中可用，就可以應用該模式。

網關模式最主要的優點之一是，它允許服務以未經設計的協議來提供。并且，如果同一個服務有好幾種不同的實現，那么可以實現在網關中為每個傳入的請求選擇最合適的目標服務的機制。

消息檢查器模式用于處理企業內的 Web 服務調用，以實現企業內部目的。這種模式對于在調用操作前進行參數驗證是最有效的。應用程序特定參數的驗證包括驗證 XML 模式、業務數據的相關方面及其特性（如數據類型，字符串或整型，格式、長度、范圍），以及檢查字符集、區域、上下文和可用值（尤其是對空值的處理）。

從模式實現來看，這兩種模式最常用的實現技術都是使用 JSR 101 和 921 所定義的 JAX-RPC 處理程序（請參閱參考資料）。JAX-RPC 處理程序的使用越來越廣泛，因為不論處理程序部署于 Web 服務層之內還是之外，它們都能夠提供良好的 SOAP 格式消息的查詢（通過 HTTP 或 JMS 協議），包括對 SOAP Body 和 Header 的大多數元素的雙向修改。然而 JAX-RPC 也有其局限性。最重要的是，它只能用于 SOAP 格式的消息，并且不能修改消息部分的類型或者消息查詢的順序，而對于大容量情況而言，這一點有時是至關重要的。

WebSphere Application Server V6 帶來了什么？

請允許我重申引入的基于“分治處理”原則的結構方法的精髓。此方法是關于提供上述兩種模式中的 XML 消息處理功能，并且支持在分布式的網絡方式下提供這些功能，從而充分利用 SOA 獨特的異構優勢。

這種結構方法展示了“對應用程序邏輯層中的內容進行分割”的概念的演化，特別是在業務邏輯（處理作為應用程序功能的完整單元的“服務功能”）和應用程序邏輯（處理“服務表現”，即如何為服務客戶提供最好的服務，而不論實際請求如何組織以及通過什么協議進行傳遞）之間。

您可能會說，“請稍等，這不正是 Enterprise Service Bus (EBS) 嗎？”如果我們將 ESB 看作一種結構模式，而不是特殊的技術，那么答案是“對”。在功能方面，EBS 是服務端點的“前端”，目標是提供協議/傳輸映射、安全功能、消息結構的中介、SOAP 消息審核等等。但不幸的是，目前的商用 ESB 實現并沒有為網絡服務器容器（例如，Java 虛擬機）中的功能分段和分段分發提供簡便的可配置選項。但是，如果我們不僅將 ESB 看作一種模式，而且將其看作是特殊的技術，那么和這里所描述的相似，面向分段的消息傳遞體系結構的實現就不同于傳統的 ESB 技術。進而，SOA 的面向分段的體系結構的實現應該被看作是 ESB 之外的。因此，根據前面提出的體系結構模式，目前還沒有現成的技術能夠明確地實現分段。

然而從實際實現的角度來看，有趣的是 WebSphere Application Server Version 6 為分段和跨多個服務器容器分配消息處理提供了所需的功能。讓我們來詳細地探討這一點。

WebSphere Application Server V6 是 WebSphere Application Server 的首個明確解決消息分段問題的發行版本。WebSphere Application Server V6 提出了一個稱作“服務集成總線 (SIBus)”的新框架。SIBus 用來扮演服務請求者和服務提供者之間的特殊層（在需要時，既是邏輯的也是物理的），啟用消息截獲與檢查功能以支持協議切換、安全支持、路由和消息轉換。

由于以下幾點關鍵原因，SIBus 比 ESB 提供了更多的組成部件：

• 它使用了常見的 JAX-RPC 處理程序和一些新的東西，即所謂的“中介器”，在一個框架中允許對 SOAP 和非 SOAP 消息傳遞進行直接的應用程序控制。
• 它接收現有的服務目標，并動態地、無縫地將它們替換為使用所謂的“入站與出站”Web服務的新生成的端點。
• 它允許配置網關和代理服務來建立對傳入的 Web 服務請求的單點控制，由此進行消息間的協議轉換（例如，在 SOAP/HTTP 和 SOAP/JMS 服務間進行切換）。WebSphere Application Server Version 5 引入的 Web 服務網關在 WebSphere Application Server Version 6 中得到擴展，允許單個網關服務端點有多個目標服務。從而可以定義多個網關實例來劃分或分段網關和代理服務，以允許簡單的伸縮。
• 它提供了稱為“Buss Object”的 EIBus 資源分組的具體構造。Buss Object，在 WebSphere Application Server Version 6 文檔中又稱作“Buss”，是邏輯分組構造，在它之上定義了所有的其他資源（網關/代理服務、中介器、入站/出站服務等等）。

回頁首

中介器能做些什么？

EIBus 中介器是一個無狀態會話的 EJB，它實現了 com.ibm.websphere.sib.mediation.handler.MediationHandler 接口并且依賴于一些特定的部署描述符配置細節，以將其標識為 EIBus 中介器。除了 JAX-RPC 處理程序，還可以使用中介器，尤其當需要：

• 將消息從一種格式轉換為另一種格式，特別是處理復雜的行業特定的格式轉換時（如 ACORD 和 IFX 之間的格式轉換）。
• 訪問和增加消息內容來添加或刪除數據，或者將應答（出站）XML 文檔的消息部分重新打包。
• 通過重定向端口來選擇最合適的目標服務。

創建中介器的過程和創建任何 EJB 類似。首先，創建一個包含將要作為中介器的 EJB 的企業應用程序。然后，創建實現 com.ibm.websphere.sib.mediation.handler.MediationHandler 接口的中介處理程序類，并為這個類添加所需的邏輯。最后，更新 EJB 部署描述符，以將新創建的中介器添加至中介處理程序列表。中介處理程序列表可能包含一個或多個中介，并且控制中介的執行順序。

EIBus 中介器可以關聯于特定總線中的任何目標以創建中介目標。例如，可以將中介器關聯于處理請求和響應消息的網關服務，或者出站服務，以協調動態端口選擇/重定向到最合適的目標服務。然而，考慮到本文的背景是消息處理的“分段”，中介器是最好的實現消息檢查器模式的方式。

WebSphere Application Server V6 的核心分段模式

圖 3 展示了 WebSphere Application Server V6 的核心分段模式。圖 3 要求遵循以下兩個關鍵要點：

1. 同時使用 Web 服務網關和入站服務，允許應用同一處理程序和大量不同服務使用者之間的中介列表，以不同的綁定方式（SOAP/HTTP 或者 SOAP/JMS）從多個目標 Web 服務中請求信息；該網關使得不需要為使用者——目標服務交互的每一種類型創建獨立的攔截器類型（或代理）服務。
2. 同時使用出站服務和帶有中介列表的出站服務，允許將單個轉換或配置資源應用于許多 Web 服務。

下面的實際場景中展示了這些方法，以及對于大容量 SOA 系統如何采用圖 3 所示的基于面向分段模式的體系結構。

假設我們正在處理一個信用評估和授權系統，它服務于：

• 銀行
• 保險公司
• 汽車銷售商
• 公寓租賃商
• 其他

由于我們要處理的是系統提供的高度機密的信息，這個場景中的消息處理的關鍵業務問題可以分為如下幾類：

• 建立通用的安全處理功能，請求的驗證/授權、消息源驗證、或許還要啟用元素級別的安全（不應該讓所有的使用者獲得所有的信用信息）。
• 提供消息記錄和審核。
• 提供消息互操作能力，由于需要為多個不同的使用者服務，所以應該支持多種格式消息（例如，對銀行使用 IFX，對保險公司使用 ACORD，對租賃者使用專有格式等等）。
• 根據負載大小和消息表現來將消息路由到多個端點（例如，有些請求可能需要返回完整的信用報告，其他的可能只需要信用評分）。

圖 4 描述了處理這個場景的一種可能的體系結構策略。該策略使用了圖 3（使用 Web 服務網關）中的模式 A。如圖 4 所示，該策略基于為緊耦合于中介層次的不同的綁定創建通道，而中介層次管理使用者和服務提供者之間所有可能的轉換選擇。這種策略帶來了對服務分發機制進行優化的設計能力，以實現與不同級別的篩選（主題、內容、內容加規則）的協同工作，或者支持消息負載的不同格式（如 XML、PDF 和 JPEG）。

總結

盡管 WebSphere Application Server V6 中引入的 EIBus 主要是一個邏輯構造，但可以使用 WebSphere Application Server 集群在物理上對其進行外部化。經過物理外部化之后，單個總線可以扮演一組一個或多個互相連接的 WebSphere Application Server V6 服務器或集群的角色，作為消息引擎組與組成員（如入站/出站服務、中介器或者 JAX-RPC 處理程序）所定義的屬性或者功能關聯。應用程序連接到使用文中介紹的模式所實現的消息引擎之一，然后訪問組屬性。