网上交易平台架构设计

09-12-12 xysniper
    

小女不才想设计一个网上交易平台,实现B2B, B2C,初步设计了一个架构,欢迎各位前辈指教,给予建议不甚感激:
技术选择入架构设计如下:
前端页面:jsp+ajax(正考虑使用jsf+ajax)
业务:EJB
DB操作: Hibernate
页面及业务缓存:Jboss cache

由于正在设计需求,将来可能有很多模块,想分布式部署,App与Model之间是EJB调用:

           前置机(loader balance)

App1      App2    App3     App4     App5 .........------->集群部署



Model1    Model2    Model3    Model4     Model5  .......----->分布式部署


App 硬件:IBM unix   10颗cpu   30G内存   500G硬盘

数据库:Oracle10g以上,数据库可能设计三个instance,分别有plat, core1, core2,....(现暂三个结点)
plat存放基础数据, core是业务数据, plat与core之前通过视图同步数据,可能也会设计procedure和funtion
<p>

[该贴被xysniper于2009-12-12 12:26修改过]

    

4
banq
2009-12-12 12:32

个人以为做电子商务架构,参考EBay是必须的,Ebay架构特点(HPTS 2009)

EBay是NoSQL运动主要参与者,当然鉴于业务特点,他们是Not Only SQL,所以他们的架构思路值得借鉴。

要注意NoSQL是对现有Java世界的同步系统的一种颠覆发展,EJB(除MDB)基本以同步为主。

所以,如果你要做分布式,需要可伸缩性,就不能用EJB,虽然EJB本身也是可伸缩的,但是它和关系数据库一样,是在一个盒子内的可伸缩,而不是廉价的 方便的 无边际的可伸缩。

当然,做项目除外,现在软件产品都是边运营边研发,所以,让软件能够伴随你的运营规模成长,廉价无缝成长很重要。

缓存还是用EHcache吧,是免费缓存产品最好的。Hibernate + Ehcache + terracotta方案还是比较成熟的。

JSF和EJB是都比较重量,一般是JSF + Seam + EJB组合。

重量的意思:请佛容易,赶佛难,以后你就围绕他们转了,你自己的业务特点和架构特点顾不上了,变成次要部分。

个人认为采取复杂的框架产品架构组合,导致复杂性,不如不用,就象EBay只用JavaEE的servlet.

[该贴被banq于2009-12-12 13:35修改过]

xysniper
2009-12-12 14:02

2009年12月12日 12:32 "banq"的内容
一般是JSF + Seam + EJB组合。重量的意思:请佛容易,赶佛难,以后你就围绕他们转了,你自己的业务特点和架构特点顾不上了,变成次要部分。个人认为采取复杂的框架产品架构组合,导致复杂性,不如不用,就象EBay只用JavaEE的servlet.[该贴被banq于2009-12-12 13:35修改过]

Seam=JSF+EJB3.0, Seam我可以考虑使用,不过,可能不用Seam了,我直接使用jsp+ejb3.0了。使用EJB+JSF导致架构复杂确实是,以后容器要升级等等,成本大,但是我想问如果不使用EJB,请问实现分布式,对象池等要自己开发?我一直觉的EJB在分布式,集群性能上支持很好,比javabean要好,记得以前有一个系统就是使用单纯的javabean,用户量上来后,内存有大量的javabean对象,gc不断启动,应用逐渐变慢,导致机器崩溃

oojdon
2009-12-12 17:49

膜拜一下MM架构师

banq
2009-12-12 18:06

2009年12月12日 14:02 "xysniper"的内容
我一直觉的EJB在分布式,集群性能上支持很好,比javabean要好,记得以前有一个系统就是使用单纯的javabean,用户量上来后,内存有大量的javabean对象,gc不断启动,应用逐渐变慢,导致机器崩溃

现在分布式世界已经非常丰富,今非昔比,特别是NoSQL运动呈现的都是各种简单方便的可伸缩性方案,对于机器崩溃,如果确定是访问量引起的,首先引入负载平衡,比如类似REST那种在Html引入不同服务器的访问,使用apache作为分发器,使用分布式缓存或key-value存储,都可以根据情况具体选择,灵活性大呢。

相当于把EJB盒子打破了,花样还是那些,以前包装在EJB后面帮你做了,你只要买昂贵的EJB服务器就可以了,但是一条裤子不一定适合所有人,隔着EJB裤子搔痒,碍手碍脚,麻烦啊。

你现在可以根据CAP定理和BASE理论,对你的业务功能进行筛选,哪些需要事务?需要高一致性,哪些不需要,将不需要事务的和需要事务分类,然后分别用不同架构实现,比如不需要事务的就不用EJB了,当然,你可以让具体EJB事务失效,这需要一个个设置,如果有几百个类设置相当麻烦。

JavaEE现在明显落后了,它提供的EJB和JMS缺省场景都是事务性(包括SSH Spring+Hibernate),认为用软件的人都是重视事务的,不给人讨价还价余地,事务确实保证了数据一致性,特别是EJB的分布式事务(包括2PC),但是哪知道CAP定理上来说了,分布式环境中,不可能将高一致性和可用性以及容错性三个同时得到,EJB三个都给你,你如果不知道CAP定理,挣扎多年后最后一个都得不到,如果你知道CAP定理,何必用EJB呢?

CAP原理和BASE思想

[该贴被banq于2009-12-12 18:18修改过]

5Go 1 2 3 4 ... 5 下一页