1樓
wangxinxin 發(fā)表于：2010-12-11 9:38:15
如果 Web 2.0 應用程序使用的是基于標準的 Java Platform, Enterprise Edition 5 (Java EE) 開發(fā)方法，那么將會面臨著嚴重的性能和可伸縮性問題。這是因為，大量支持 Java EE 平臺的底層設計原理（尤其是使用同步 API 的應用）并不適合 Web 2.0 解決方案的需求。本文將解釋 Java EE 和 Web 2.0 方法之間的不一致性，并對一些使用 Java 平臺開發(fā)異步 Web 應用程序的解決方案進行評估。
很多成功的企業(yè)應用程序都是使用 Java EE 平臺構建的。但是，Java EE 的設計原理并不能夠有效地支持 Web 2.0 應用程序。深入了解 Java EE 和 Web 2.0 原理之間的脫節(jié)可幫助您制定明智的決策，從而使用各種方法和工具在一定程度上解決這種脫節(jié)。本文將解答 Web 2.0 和標準 Java EE 平臺緣何成為失敗的組合，并演示為何由事件驅動的異步架構更適合 Web 2.0 應用程序。本文還介紹了一些框架和 API，它們通過支持異步設計使得 Java 平臺更加適合 Web 2.0。
Java EE 平臺的創(chuàng)建目的就是為企業(yè)到客戶（B2C）和企業(yè)到企業(yè)（B2B）應用程序提供支持。企業(yè)發(fā)現(xiàn)了 Internet 的價值之后就開始使用它增強與合作伙伴和客戶之間的現(xiàn)有業(yè)務流程。這些應用程序通常要與一個現(xiàn)有企業(yè)集成系統(tǒng)（EIS）進行交互。大多數(shù)常見基準測試（測試 Java EE 服務器的性能和可伸縮性）— ECperf 1.1、SPECjbb2005 和 SPECjAppServer2004的用例都將這一點反映到了 B2C、B2B 和 EIS 中。類似地，標準的 Java PetStore 演示也是一個典型的電子商務應用程序。
很多有關 Java EE 架構可伸縮性的明顯和暗含的設想都反映在基準測試中：
- 從客戶機角度來看，請求吞吐量是影響性能的最重要特性。
- 事務持續(xù)時間是最重要的性能因素，并且，縮減所有個體事務的持續(xù)時間將改善應用程序的總體性能。
- 事務之間通常都是彼此獨立的。
- 除長期執(zhí)行的事務以外，只有少數(shù)業(yè)務對象會受事務影響。
- 應用服務器的性能和部署在同一管理域的 EIS 會限制事務的持續(xù)時間。
- 通過使用連接池可以抵消一定的網(wǎng)絡通信成本（在處理本地資源時產(chǎn)生）
- 通過對網(wǎng)絡配置、硬件和軟件進行優(yōu)化，可以縮短事務持續(xù)時間。
- 應用程序所有者可以控制內(nèi)容和數(shù)據(jù)。在不依賴外部服務的前提下，向用戶提供內(nèi)容的最重要限制因素是帶寬。
這些設想產(chǎn)生了以下 Java EE API 構建原理：
- 同步 API。Java EE 在很多應用中都需要使用同步 API（重量級并且繁瑣的 Java Message Service (JMS) API 基本上是惟一的例外）。這種需求更多地源于可用性的需要，而非性能需求。同步 API 易于使用并且開銷較低。但需要處理大型多線程時，則會出現(xiàn)嚴重問題，因此 Java EE 嚴格限制未受控制的多線程處理。
- 有限的線程池。人們很快發(fā)現(xiàn)線程是種重要的資源，并且當線程數(shù)量超過某一界限后，應用服務器的性能將顯著下降。然而，根據(jù)每個操作都很短暫的設想，這些操作可以分配到一組有限的線程中，從而維持較高的請求吞吐量。
- 有限的連接池。如果只使用一個數(shù)據(jù)庫連接，則很難獲得最優(yōu)的數(shù)據(jù)庫性能。雖然一些數(shù)據(jù)庫操作可以并行執(zhí)行，但是增加額外的數(shù)據(jù)庫連接只能將應用程序提速到某一點。當連接數(shù)達到某一值后，數(shù)據(jù)庫性能將開始下滑。通常，數(shù)據(jù)庫連接的數(shù)量要小于 servlet 線程池中可用線程的數(shù)量。因此，連接池在創(chuàng)建時允許向服務器組件 — 例如 servlet 和 Enterprise JavaBeans (EJB) — 分配一個連接并在以后返回給連接池。如果連接不可用，組件將等待阻塞當前線程的連接。因為其他組件只對連接占用很短的時間，因此這種延遲通常較短。
- 固定的資源連接。應用程序被假設只使用很少一些外部資源。與各個資源的連接工廠通過 Java Naming and Directory Interface (JNDI)（或 EJB 3.0 的依賴性注入）獲得。實際上，支持與不同 EIS 資源進行連接的主要 Java EE API 只有企業(yè) Web 服務 API。其他 API 多數(shù)都假設資源是固定的并且只有諸如用戶憑證這樣的額外數(shù)據(jù)應該提供給開放連接操作。
在 Web 1.0 中，這些原理玩轉得非常好。可以將一些獨特的應用程序設計為遵守這些規(guī)則。但是，這些原理不能有效支持 Web 2.0。
Web 2.0 應用程序具有很多獨特需求，因此，不適合將 Java EE 用于 Web 2.0 實現(xiàn)。其中一個需求就是，Web 2.0 應用程序更多地通過服務 API 使用另一個 Web 2.0 應用程序，而不是使用 Web 1.0 應用程序。Web 2.0 應用程序的一個更為重要的因素是，極度傾向于用戶到用戶（C2C）交互：應用程序所有者只生成一小部分內(nèi)容；用戶負責生成大部分內(nèi)容。
在 Web 2.0 環(huán)境中，聚合應用程序經(jīng)常使用通過 SOA 服務 API 公開的服務和提要。這些應用程序需要在 B2C 環(huán)境中使用服務。例如，一個聚合應用程序可能從三個不同的數(shù)據(jù)源提取數(shù)據(jù)，如天氣信息、交通信息和地圖。檢索這三種獨特數(shù)據(jù)所需的時間延長了總的請求處理時間。不管數(shù)據(jù)源和服務 API 的數(shù)量是否增加，用戶仍然期望得到具有高反應度的應用程序。
諸如緩存這類技術可以緩解延遲問題，但是不適用于所有場景。比如，可以緩存地圖數(shù)據(jù)來減少響應時間，但通常并不適合將搜索查詢結果或者實時交通信息進行緩存。
服務調(diào)用本來就是一種高延遲過程，在客戶機和服務器上通常只分配很小一部分 CPU 資源。Web 服務調(diào)用的持續(xù)時間很大一部分用于建立連接和傳輸數(shù)據(jù)。因此，通常來講，提升客戶端或服務器端的性能對于減少調(diào)用持續(xù)時間效果甚微。
Web 2.0 對用戶參與的支持引發(fā)了另外一大挑戰(zhàn)，因為應用程序要處理來自每個活動用戶的更多數(shù)量的請求。下面這些理由證明了這一點：
- 因為大多數(shù)事件是由其他用戶的操作引起的，因此會引發(fā)更多相關事件，并且用戶具備更強大的能力來生成事件。這些事件通常使用戶能夠更加積極地使用 Web 應用程序。
- 應用程序為用戶提供了更多的用例。Web 1.0 用戶僅僅可以瀏覽類別、購買商品并跟蹤他們的訂單處理狀態(tài)。現(xiàn)在，用戶可以通過論壇、聊天、聚合等等方法與其他用戶進行積極地交流，這將產(chǎn)生更高的通信負載。
- 如今的應用程序越來越多地使用 Ajax 改善用戶體驗。與普通 Web 應用程序的頁面相比，使用 Ajax 的 Web 頁面加載要慢一些，因為頁面是由一些靜態(tài)內(nèi)容、腳本（可能會非常大）和一些發(fā)往服務器的請求組成。加載完成后，Ajax 頁面通常會向服務器生成一些短小的請求。