<http://onecan.iteye.com/blog/1333529>

http://www.iteye.com/topic/1119464

 看到別的朋友在ITEYE上發表的“開發電子商務網站技術選型“有感而發。地址是
[url]http://www.iteye.com/topic/1119464 [/url],那我們另開一個多使用者商城的話題來討論，
本人一直從事Java企業級開發，因此接觸過不少Java的開發框架。目前作一個多使用者商城的創業專案，因為本人只專著於JAVA,那沒有辦法，都不用選型了。進入JAVA世界之後又有很多框架可以選擇，列舉幾個熟悉的，例如表示層struts, spring mvc, jsf,tapestry..., 控制層：spring/ejb, ejb不知道算不算阿，反正spring的作者說了他開發spring是為了跟ejb抗衡而生的，見那本經典的紅皮書：Expert One-on-One J2EE Development without EJB，這本也是我剛學spring所用到的。資料持久層：hibernate/ibatis/jdbc，歸根到底都是jdbc,這個一定要掌握。下面說說各個層面的選型比較。除了這幾個層面的，當然還有其他的框架要選擇的了，java就是框架太多了，剛進門的朋友估計眼睛都看花了。不過我奉勸各位新入門的朋友，一定要注意Java基礎，所有的框架都是在這些基礎上幻變而成，而Java作web應用的核心技術就servlet/jsp/jdbc/這幾個（ejb應該也算吧，我看到很多大型應用都離不開JMS/EJB等），有空研究一下JDK,Spring,Hibernate,Tomcat等開源框架的程式碼，裡面體現了n多的設計模式，程式碼規範等，一定會給你帶來技術上的昇華。我本人也剛開始看，覺得獲益不淺，如果我們只是知道怎麼應用框架而不知道他底層的含義，那只是停留在程式設計師的水平而以，所以往架構師方向發展的話，Java要越做越底層。


先交待一下專案背景，要不就不知道為啥要這麼選擇了。現在電子商務是越來越火，淘寶和京東的廣告已經滲透和生活的各個角落。雖然最近團購網是不太景氣，也有不少電商關門大吉。
但是我們有理由相信未來十年電子商務也是處於上升空間的。理由有下：
    1。 有研究說美國的電子商務比例要比中國大很多，中國IT行業流行的東西往往要比外國晚一些，中國電子商務還是有很大的發展空間。
    2。 中國上網人群越來越多，現在哪個小孩子不會使用電腦，哪怕是窮二代也好。而年紀大的人不一定會的
    3。 網購確實給人們生活帶來了方便，尤其經濟不好時，可以給大家提供更便宜合適的產品。
    4。 中國做的有點規模的公司應該不會只滿足於在淘寶/拍拍等網站上面開個店而已，京東/走秀網的成功會刺激其他人加入這個行業競爭。
    5。 淘寶實行提高門檻的做法，可能會把一部分小商家擠出來，不排除這些商家有建立獨立網站的需求，但是要解決信用，流量的問題先。
   
    以上理由是個人YY出來的，大家不要太認真，反正我們就是要以商城為主導來進行一個創業專案。OK,好了，那開始分析目前獨立商城系統的競爭對手。
   
    目前php商城佔據了大部分市場，跟著是.net商城，java商城沒有幾個好的，為排除作廣告嫌疑，這裡不出現任何商城系統的名字。為什麼有這個現象呢，其實java語言的優勢是非常明顯的，銀行電信行業基本都是以java為主，這個是我本人工作經歷所見。包括現在淘寶/京東都有向java方向靠攏的趨勢，由於java語言本身的架構是比較合適做大型應用，我們有理由相信java商城會由更大的發展空間。我們要著手解決Java開發成本高的問題，因此好的框架和開發模式是少不了的。
   
    因此我們寫了一個Java多使用者商城系統立足B2C,跟進C2C，前面的C其實是很多個B組成的，可以理解為B2B2C，類似淘寶商城模式。這樣我們可以滿足B2C的需求，也可以滿足那些C2C人的要求，也避開市場上已有的成熟的商城的競爭。這裡有一個好處是可以結合淘寶和百姓網趕集網模式作本地商家運營，就是每個城市或者高校都找一家代理商獨自運營，資料都單獨保留在他們的伺服器上，我們總站只保留少量資料，例如單點登陸，統一的社群，統一的搜尋體驗等，這是個大project,暫時還沒能推進下去，但是這個前途是無可限量的。已經有好些人諮詢過類似方案，這樣可以集百家之長來跟一些大型的商城抗衡，也就是B2B2C的模式吧，是個很好的思路，但是需要有實力的人去推動才行，估計以後會由類似商城出現。
   
    說太多的背景了，話回主題。目前系統已經小有成績，但是也遇到不少問題，這裡拿出來跟大家分享。
   
    我心目中最好的框架組合是：
    表示層:spring mvc 3.1 + annotation
    控制層:spring 3.1
    持久層：hibernate 3.6 +jdbcTemplate
    後臺列表控制元件：displaytag 1.2
    Ajax框架: DWR 3
    JS框架 ： Jquery
    快取機制：spring 3.1 cache + ehcache/memcached
    靜態化機制： Freemarker靜態化/spring mvc偽靜態化
    頁面技術： EL + JSTL +JSP
    安全框架 spring security
    搜尋引擎： Lucene
    中文分詞：IKAnalyzer
    模板引擎： apache tiles 2.22
   
   
    以上框架均使用目前最新框架，如果有更新特性出來的話可能會更換。
   
    部署檢視所需：
    資料庫： mysql
    Web 伺服器： windows 下用apache, linux 下用ngnix
    應用伺服器： Tomcat
   
    另外一些分散式的技術，例如EJB/web service/JMS等沒有使用，如果改變部署方案時或者需要整合其他系統時可能會引入。
   
    一箇中小型的部署方案是1臺Web 伺服器 + 2臺Tomcat伺服器 + 1臺memcached伺服器 + 1臺圖片伺服器 + 1臺數據庫，此方案是方便系統不斷的升級，而又使得投資比較少。
當然更大型的解決方案需要更多的伺服器和在資料庫上做更多的優化動作。最省錢的辦法就是1個伺服器就執行以上所有的服務，這個也不是不行，有個1G的記憶體都已經能應付不少流量了。在那些便宜的JSP空間只要有256/512M記憶體也可以跑，大有大的跑法，小有小的跑法。
  

    下面就比較關注的框架做個簡單的對比：
   
    1 spring mvc vs struts2
    我們本來是採用struts1.3來開發，struts那層用的非常的薄，只是用於接收頁面引數和拿到資料庫資料之後列印到request中讓頁面展現。按理應該直接升級為struts2才對，但是看了spring mvc 2.5的annotation版本之後就拋棄struts2了,spring mvc可以讓我很容易從頁面拿到資料，並且採用非常少的配置和具有很強的靈活性，看了struts2之後覺得都是大同小異的思路，那我何必再引入更多的jar..
    2. hibernate va jpa ibatis
    Jpa跟Hibernate很類似，個人感覺沒有hibernate靈活，hibernate在快速開發上是很有優勢的，加上cache可以部分彌補效能上的損耗，另外儘量不用他的那個配置做複雜的關聯。
    另外可以用jdbcTemplate頂上用的比較多的地方以提高效能。
    3. DWR vs Jquery
    DWR在js和後臺java程式碼之間是很好的橋樑，尤其是跟spring配合的很好，但是Jquery在頁面的功能是少不了，還好兩者不排斥對方，那就一起用了。
    4. spring 3.1 cache + ehcache/memcached
     spring 3.1 直接支援cache了，這次hibernate的二級快取可以退休了。如果在單機選擇ehcache,叢集方式採用memcached。 memcached是遠端呼叫，效能必然會有損耗。
    5. JSP vs freemarker velocity
    自從JSP有了JSTL之後， struts 的標籤我已經不用了，加上EL之後我也沒有找到用freemarker velocity的理由，除了靜態化之外，貌似JSP也可以做靜態化的，這個我研究不深，如果有反對意見可以提出來。
    6. apache tiles vs sitemesh
    由於是學struts出身，tiles熟悉阿，而且現在也支援模糊匹配了，看一些網上評論說效能不會有太大差別，sitemesh3也許會好些，用生不如用熟。不過均不能達到那種實時生效的模板效果，誰能說說java怎麼做？
    7. 其餘幾個就沒什麼懸念了， 由於現在免費的jsp空間比較多的支援mysql和tomcat, 所以這2個是我們要優先支援的，雖然我們也支援oracle等。
   
    問題：
    1。模板技術缺少靈活性，目前Php的大型商城系統有很多的模板可以用，這個也不全都是官方自己開發的，這個是Java商城需要向php商城學習的地方。因為java是mvc方式建設的，有java,jsp, html等，java class需要重啟伺服器才能生效，而且很難像php一樣，把所有東西寫在一個目錄拷貝到伺服器上即可使用，目前我還是沒有什麼好的思路能達到這個效果的，考察了apache tiles/sitemesh/freemarker/velocity等，都沒有想到辦法。。。只能做到內建好模板讓使用者挑選。要達到大家都能做模板的程度，需要把程式碼和文件繼續完善和開源。
    2。B2B2C模式需要大量的人力物力，目前還不成熟。需要有實力和經驗的人加盟我們。
    3。java開發代價是高了些，通過對框架的整合和預設約定，已經把後臺程式碼的使用方式給固定下來，前臺頁面是比較耗時。但如何降低總體開發難度並開創一個Java品牌商城是很有挑戰和難度的。