本文就我所經歷和使用過的技術和框架， 討論 Java / Javascript 技術組合構成的Web 應用架構。
一、 概述
Web 應用架構可以劃分爲兩大子系統：前端子系統和後臺子系統。
前端子系統：
1. 基礎技術： Html/Javascript/CSS / Flash
2. 開發框架： jQuery, Extjs , Flex 等；
後臺子系統：
1. 基礎技術： Java Servlet；
2. 開發框架： Struts, Spring, Hibernate, ibatis 等；
3. 應用服務器： Tomcat / Jetty
編程模型： B/S 模型。 客戶端向服務器端發送請求， 服務器經過處理後返回響應， 然後客戶端根據響應及需求繪製前端展現。 在用戶客戶端和實際提供功能的Web 服務器之間還可能存在着代理服務器， 負載均衡服務器， 不過那些屬於錦上添花的事物，暫時不在考慮範圍內。
富客戶端應用理念： 客戶端承擔大量的交互邏輯及渲染工作，服務器端主要是處理請求和返回數據。
前後端系統耦合： 客戶端和服務器端各自處理自己內部的子系統耦合；而客戶端與服務器端的耦合簡化爲一個通信與數據通道。該通道用來傳輸通信請求和返回數據；
請求通信： 採用 Http / Tcp 協議
數據通道： 採用 Json, xml , 文本字符串，字節。 內部系統一般採用 Json 作爲數據交換格式；系統間的互操作則採用XML 來規範； 文本字符串是最一般的形式， 字節是最底層的形式。
二、 架構演變
最輕的架構： jQuery + Servlet + ajax
在客戶端使用 jQuery發送 ajax 請求給Java 服務端的 Servlet 進行處理， Servlet 僅僅返回數據給客戶端進行渲染。 該架構有效地分離了前端展示和後臺請求處理，同時又保持了最輕的複雜性， 只需要學會編寫 Servlet 及使用 jQuery ， 就能構建簡單的應用。
如果只是做個人創意演示， 可以採用該架構， 快速實現自己的創意功能。 Servlet 是Java web 應用的基礎技術，jQuery 則是前端開發的簡單易用的利器。
後臺架構演變：
邏輯與頁面的分離： JSP/Servlet
JSP 實現了頁面邏輯與外觀的分離，但是， 前端子系統與後臺子系統仍然是緊密耦合的； 前端設計人員實際上只需要服務端返回的數據， 就可設計出非常專業的界面顯示；
MVC 架構：Struts2(含Servlet，MVC) + JDBC
用Servlet 來添加服務器功能是基本的選擇，但在web.xml中配置大量的 Servlet 卻不是最佳的選擇。Struts2 在服務端實現了更豐富的MVC 模式， 將本來由應用決定的控制器從web容器中分離；
SSH 架構： Struts2(含Servlet, MVC) + Spring (Ioc) + Hibernate (ORM，對象-關係映射)
通常， 應用系統中需要預先創建一些單例對象， 比如 Controller, Service, Dao, 線程池等， 可以引入 Spring Ioc 來有效地創建、管理和推送這些對象； 使用 Hibernate 來實現關係數據庫的行與面向對象的屬性之間的映射與聯接， 以更好地簡化和管理應用系統的數據庫操作。SSH 可以說是 JavaWeb應用系統開發的三劍客。
SI 架構： SpringMVC(含Servlet, Ioc, MVC, Rest) + iBatis (Semi-ORM)
過於複雜的架構會將人搞暈。因此，在適應需求的情況下， 儘量選擇簡單的架構，是明智之選。 這種架構使用面向資源的理念， 着重使用Spring作爲MVC及應用基礎服務設施， 同時使用 iBatis 來實現更簡單靈活的ORM映射， 使之在可以理解和維護的範圍內。
前端架構：
1. Flash 架構： Flex + jQuery + JSP
這是一種比較傳統的前端架構，採用同步模式， Flex 承擔大量的頁面渲染工作， 並採用AMF協議與Java端進行通信， 而JSP 則可以用於更快速的頁面顯示。優點是： 經過考驗的結構， 通常是值得信賴的； 缺點是， 由於採用同步模式， 在交互效果上可能不夠流暢， 需要進行比較耗時的編譯過程； 此外， Flex 基於瀏覽器插件運行，在調試方面有些麻煩。
2. MVC 架構： Extjs + jQuery
這是一種比較現代的前端架構， 採用異步模式， Extjs4 可以實現前端子系統的MVC 分離， 對於可維護性是非常不錯的支持； 此外， jQuery 可以作爲有效的補充。優點： 異步， 快速， 對於企業內部的後臺管理系統是非常好的選擇。 缺點： Extjs4 的可定製性、可適應性可能難以適應各種特殊的需求，需要用其它組件來補充， 比如大數據量的繪製。對於互聯網應用， 速度可能是致命傷。
三、 架構的選擇
不要去詢問哪種架構更好， 更需要做的是清晰地定位項目目標，根據自己的具體情況來選擇和定製架構。反覆地嘗試、觀察和改進，反覆磨鍊技藝，這樣才有助於設計水平的提升。
架構的選擇通常有四種關注點：
1. 適用性： 是否適合你的項目需求。 架構有大有小， 小項目用小架構， 大項目用大架構；
2. 可擴展性： 該架構在需要添加新功能時，是否能夠以常量的成本添加到現有系統中， 所做的改動在多大程度上會影響現有功能的實現（基本不影響，還是要大面積波及）；
3. 便利性： 使用該架構是否易於開發功能和擴展功能， 學習、開發和測試成本有多大；
4. 複雜性： 使用該架構後， 維護起來的成本有多大。你自然希望能夠寫一條語句做很多事，使用各種成熟的組件是正確的方式，同時，在項目中混雜各種組件，也會提升理解和維護系統的複雜度。便利性和複雜性需要達到較好的平衡；
特殊的關注點：
譬如，應用需要支持高併發的情況， 需要建立一個底層的併發基礎設施， 並向上層提供簡單易用的接口，屏蔽其複雜性。
四、 架構演進的基本手段
架構並不是一成不變的， 在做出最初的架構之後，隨着開發的具體情況和需求的變更， 需要對最初架構做出變更和改進。
架構演進的基本手段：
一致性， 隔離與統一管理， 螺旋式重構改進， 消除重複， 借鑑現有方案
1. 一致性： 確保使用統一模式來處理相同或相似的功能； 解決一次， 使用多次；
2. 模塊化、隔離與統一管理： 對於整體的應用， 分而治之，將其劃分爲隔離性良好的模塊，提供必要的通信耦合；對於特定的功能模塊， 採用隔離手段，將其隔離在局部統一管理，避免分散在系統的各處；
3. 不斷重構改進， 一旦發現更好的方式， 馬上替換掉原有方式；
4. 儘可能重用，消除重複；
5. 儘可能先借鑑系統中已有方案並複用之；如果有更好方案可替換之；
有一條設計準則是： 預先設計， 但不要過早設計。
意思是說， 你需要對需求清楚的部分進行仔細的設計， 但是對於未知不清楚的需求，要堅持去理解它，但不要過早地去做出“預測性設計”； 設計必須是明確的、清晰的、有效的， 不能針對含糊的東西來設計。可以在後期通過架構演進來獲得對後續需求的適應能力。