13
14
看到別的朋友在ITEYE上發表的“開發電子商務網站技術選型“有感而發。地址是
http://www.iteye.com/topic/1119464
本人一直從事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品牌商城是很有挑戰和難度的。
轉自:http://onecan.iteye.com/blog/1333520