分享我的大型Java多用户商城系统开发的心得和困难

我会带着你远行 2024-02-17 21:33 84阅读 0赞

### **如果有需要请联系下方微信** ###

看到别的朋友在ITEYE上发表的“开发电子商务网站技术选型“有感而发  
  
本人一直从事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品牌商城是很有挑战和难度的。