大型Java Web系統選型問題探討

   
    一位ID是jackson1225的網友在JavaEye詢問了一個大型Web系統的架構和部署選型問題，希望能提高現有的基於Java的Web應用的服務能力。由於架構模式和部署調優一直是Java社區的熱門話題，這個問題引發了很多熱心網友的討論，其中一些意見對其它大型Web項目也有很好的指導意義。在討論之初jackson1225這樣描述了當前的應用的架構和部署方案：

　　目前系統架構如下:

　　web層採用struts+tomcat實現，整個系統採用20多台web伺服器，其負載平衡採用硬體F5來實現；
　　中介層採用無狀態會話Bean+DAO+helper類來實現，共3台weblogic伺服器，部署有多個EJB，其負載平衡也採用F5來實現；
　　資料庫層的操作是自己寫的通用類實現的，兩台ORACLE資料庫伺服器，分別存放使用者資訊和業務資料；一台SQL SERVER資料庫，是第三方的業務資料資訊；
　　web層調用EJB遠程介面來訪問中介軟體層。web層首先通過一個XML設定檔中配置的EJB介面資訊來調用相應的EJB遠程介面；

　　該系統中一次操作涉及到兩個ORACLE庫以及一個SQL SERVER庫的訪問和操作，即有三個資料庫連接，在一個事務中完成。

　　這樣的架構其實很多公司都在使用，因為Struts和Tomcat分別是最流行的Java Web MVC架構和Servlet容器，而F5公司的負載平衡是橫向擴充常見的解決方案（例如配置session sticky方案）。由於這個系統中有跨資料來源的事務，所以使用Weblogic Server EJB容器和支援兩階段交易認可的資料庫驅動就可以保證跨資料來源的事物完整性（當然，容器管理的分散式交易並非是唯一和最優的解決方案）。

　　但是隨著Rod Johnson重量級的著作《J2EE Development without EJB》和其中的Spring架構的流行，輕量級架構和輕量級容器的概念已經深入人心。所以對於jackson1225提出的這個情境，大多數網友都提出了置疑，認為這個系統濫用了技術，完全是在浪費錢。網友們大都認為SLSB（無狀態會話Bean）完全沒有必要出現在這個情境中，認為SLSB通過遠程介面訪問本地資源會有很大的效能開銷，這種觀點也是Rod johnson在without EJB中批判EJB 2.x中的一大反模式。

　　由於JavaEE是一個以模式見長的解決方案，模式和架構在JavaEE中佔有很重要的地位，所以很多業內專家也都警惕“反模式（Anti-patterns）”的出現。對於上面所述的方案是否是反模式，jackson1225馬上站出來申辯：

　　我們項目就是把EJB作為一個Facade，只是提供給WEB層調用的遠程介面，而且只用了無狀態會話Bean，所以效能上還可以的。

　　這個解釋很快得到了一些網友的認可，但是大家很快意識到架構的好壞決定於是否能夠滿足使用者的需求，davexin（可能是jackson1225的同事）描述了這個系統的使用者和並發情況：

　　現在有使用者4000萬，馬上要和另一個公司的會員系統合并，加起來一共有9000萬使用者。資料量單表中有一億條以上的資料。這是基本的情況，其實我覺得現在的架構還是可以的，現在支援的並發大概5000並發使用者左右，接下來會進行系統改造，目標支援1萬個並發使用者。

　　具體的並發量公布後又有網友置疑這個資料，認為這個系統的Servlet容器支援的並發數太小，懷疑是否配置不夠最佳化。davexin又補充了該項目的伺服器配置：

　　系統前端tomcat都是用的刀片，配置在2G記憶體，cpu大概在2.0G，每台機器也就支援250-400個並發，再多的話，就會相應時間非常的常，超過20秒，失去了意義 ，所以我們才得出這樣的結論的。

　　一位ID是cauherk的網友提出了比較中肯的意見，他沒有從Web容器單純的並發支援能力上提出改進方案，而是提出了對於類似的應用的一些通用的改進提示，這裡摘要一下：

　　資料庫壓力問題
　　可以按照業務、地區等等特性對資料庫進行配置，可以考慮分庫、使用rac、分區、分表等等策略，確保資料庫能正常的進行交易。

　　事務問題
　　要在兩個資料庫中操作，那麼必須考慮到分散式交易。你應該仔細的設計你的系統，來避免使用分散式交易，以避免分散式交易帶來更多的資料庫壓力和其它問題。推薦你採用延遲提交的策略(並不保證資料的完整)，來避免分散式交易的問題，畢竟commit失敗的幾率很低。

　　web的最佳化
　　將靜態、圖片獨立使用不同的伺服器，對於常態的靜態檔案，採用E-TAG或者用戶端緩衝， google很多就是這樣乾的。對於熱點的功能，考慮使用完全裝載到記憶體，保證絕對的響應速度，對於需要頻繁訪問的熱點資料，採用集中緩衝(多個可以採用負載平衡)，減輕資料庫的壓力。

　　對於幾乎除二進位檔案，都應該在L4上配置基於硬體的壓縮方案，減少網路的流量。提高使用者使用的感知。

　　網路問題
　　可以考慮採用鏡像、多路網路接入、基於DNS的負載平衡。如果有足夠的投資，可以採用CDN(內容分髮網)，減輕你的伺服器壓力。

　　cauherk的這個分析比較到位，其中ETags的方案是最近的一個熱點，InfoQ的“使用ETags減少Web應用頻寬和負載”裡面對這種方案有很詳細的介紹。一般以資料庫為中心的Web應用的效能瓶頸都在資料庫上，所以cauherk把資料庫和事務問題放到了前兩位來討論。但是davexin解釋在所討論的這個項目中資料庫並非瓶頸：

　　我們的壓力不在資料庫層，在web層和F5。 當高峰的時候 ，F5也被點死了，就是每秒點擊超過30萬，web動態部分根本承受不了。根據我們程式記錄，20台web最多承受5000個並發，如果再多，tomcat就不響應了。就像死了一樣。

　　這個回複讓接下來的討論都集中於Web容器的效能最佳化，但是JavaEye站長robbin發表了自己的意見，將話題引回了這個項目的架構本身：

　　performance tuning最重要的就是定位瓶頸在哪裡，以及瓶頸是怎麼產生的。

　　我的推測是瓶頸還是出在EJB遠程方法調用上！

　　tomcat上面的java應用要通過EJB遠程方法調用，來訪問weblogic上面的無狀態SessionBean，這樣的遠程方法調用一般都在100ms~500ms層級，或者更多。而如果沒有遠程方法調用，即使大量採用spring的動態反射，一次完整的web請求處理在本地JVM內部的完成時間一般也不過20ms而已。一次web請求需要過長的執行時間，就會導致servlet線程被佔用更多的時間，從而無法及時響應更多的後續請求。

　　如果這個推測是成立的話，那麼我的建議就是既然你沒有用到分散式交易，那麼就乾脆去掉EJB。weblogic也可以全部撤掉，業務層使用spring取代EJB，不要搞分布式架構，在每個tomcat執行個體上面部署一個完整的分層結構。

　　另外在高並發情況下，apache處理靜態資源也很耗記憶體和CPU，可以考慮用輕量級web server如lighttpd/litespeed/nginx取代之。

　　robbin的推斷得到了網友們的支援，davexin也認同robbin的看法，但是他解釋說公司認為放棄SLSB存在風險，所以公司傾向於通過將Tomcat替換為Weblogic Server 10來提升系統的使用者支撐能力。robbin則馬上批評了這種做法：

　　坦白說我還從來沒有聽說過大規模互連網應用使用EJB的先例。為什麼大規模互連網應用不能用EJB，其實就是因為EJB效能太差，用了EJB幾乎必然出現效能障礙。

　　web容器的效能說到底無非就是Servlet線程調度能力而已，Tomcat不像WebLogic那樣附加n多管理功能，跑得快很正常。對比測試一下WebLogic的資料庫連接池和C3P0串連池的效能也會發現類似的結論，C3P0可要比WebLogic的串連池快好幾倍了。這不是說WebLogic效能不好，只不過weblogic要實現更多的功能，所以在單一的速度方面就會犧牲很多東西。

　　以我的經驗來判斷，使用tomcat5.5以上的版本，配置apr支援，進行必要的tuning，使用BEA JRockit JVM的話，在你們目前的刀片上面，支撐500個並發完全是可以做到的。結合你們目前20個刀片的硬體，那麼達到1萬並發是沒問題的。當然這樣做的前提是必須扔掉EJB，共置web層和業務層在同一個JVM內部。

　　接下來robbin還針對davexin對話題中的應用分別在tomcat和weblogic上的測試資料進行了分析：

　　引用：
　　2。1台weblogic10 Express（相當於1台tomcat，用於發布jsp應用）加1台weblogic10（發布ejb應用），能支援1000個並發使用者......
......
　　4。1台tomcat4.1加1台weblogic8，只能支援350個並發使用者，tomcat就連結逾時，說明此種結構瓶頸在tomcat。

　　這說明瓶頸還不在EJB遠程調用上，但是問題已經逐漸清楚了。為什麼weblogic充當web容器發起遠程EJB調用的時候可以支撐1000個並發，但是tomcat只能到350個？只有兩個可能的原因：

　　你的tomcat沒有配置好，嚴重影響了效能表現
　　tomcat和weblogic之間的介面出了問題
　　接著springside項目發起者江南白衣也提出了一個總體的最佳化指導：

　　1.基礎配置最佳化

　　tomcat 6？ tomcat參數調優?
　　JRockit JVM? JVM參數調優？
　　Apache+Squid 處理靜態內容？

　　2.業務層最佳化

　　部分功能本地化，而不調remote session bean?
　　非同步提交操作,JMS？
　　cache熱點資料？

　　3.展示層最佳化

　　動態網頁面發布為靜態頁面？
　　Cache部分動態網頁面內容？

　　davexin在調整了Tomcat配置後應驗了robbin對tomcat配置問題的質疑，davexin這樣描述經過配置最佳化以後的測試結果：

　　經過測試，並發人數是可以達到像robbin所說的一樣，能夠在600人左右，如果壓到並發700人，就有15%左右的失敗，雖然在調整上面參數之後，並發人數上去了，但是在同樣的時間內所完成的事務數量下降了10%左右，並且回應時間延遲了1秒左右，但從整體上來說，犧牲一點事務輸送量和回應時間，並發人數能夠提高500，覺得還是值得的。

　　至此這個話題有了一個比較好的結果。這個話題並非完全針對一個具體的項目才有意義，更重要的是在分析和討論問題的過程中網友們解決問題的思路，尤其是cauherk、robbin、江南白衣等幾位網友提出的意見可以讓廣大Java Web項目開發人員瞭解到中、大型項目所需要考慮的架構和部署所需要考慮的關鍵問題，也消除了很多人對輕量Servlet容器與EJB容器效能的一些誤解。