网上交易平台架构设计

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 class="indent">

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

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修改过]

jzxw
2009-12-12 21:56
看到这个设计不知道该说什么,感觉很奇怪,是很多公司很经典的设计(当然不是很大型的系统),这样的设计最后会是一个很臃肿的结果,很难维护,性能不会好的。

xysniper
2009-12-13 20:32
2009年12月12日 21:56 "jzxw"的内容
看到这个设计不知道该说什么,感觉很奇怪,是很多公司很经典的设计(当然不是很大型的系统),这样的设计最后会是一个很臃肿的结果,很难维护,性能不会好的。

看到这位大哥的回复,很想知道原因,是不是臃肿在EJB这块,能不能讲讲你的思路,你认为像网上交易平台这样的网站应该怎么设计?希望能得到你高人的指点

xuejianlong
2009-12-13 23:52
综合以上理解如下:

web层:
1. jsp+ajax
2. jsf+ajax

会话层:
1.引入负载平衡,比如类似REST那种在Html引入不同服务器的访问,使用apache作为分发器。
2.页面及业务缓存使用分布式缓存或key-value存储

业务层(Not Only SQL):
1. 需要事务的业务—》EJB会话bean或者SSH。
2. 不需要事务的业务--> MDB或者NoSQL等异步处理(切分,异步,BASE)

数据访问层:
1.Hibernate
2. 数据缓存:Hibernate + Ehcache + terracotta



请指教

[该贴被xuejianlong于2009-12-13 23:58修改过]

r7raul
2009-12-14 10:18
淘宝的架构如何?

banq
2009-12-14 10:39
2009年12月13日 23:52 "xuejianlong"的内容
综合以上理解如下:

web层:
1. jsp+ajax
2. jsf+ajax

会话层:
1.引入负载平衡,比如类似REST那种在Html引入不同服务器的访问,使用apache作为分发器。
2.页面及业务缓存使用分布式缓存或key-value存储

业务层(Not Only SQL):
1. 需要事务的业务—》EJB会话bean或者SSH。
2. 不需要事务的业务--> MDB或者NoSQL等异步处理(切分,异步,BASE)

数据访问层:
1.Hibernate
2. 数据缓存:Hibernate + Ehcache + terracotta



这个架构是不错的,但是我们会发现一个实施的难易程度,在架构 vs. 编程一文已经提出,架构必须不能带来高的学习成本,上述架构涉及技术广泛,个人认为带来架构复杂性。

架构简单,代码才会优美,有人说:手上无框架,心中有框架就是这个道理。

所以,个人认为,在保持原则不变的基础上,必须对这个方案进行精简,实现架构统一和单一化。大家可以群献群策,帮帮架构师MM哦。

关于淘宝的架构,好像没有Ebay那样的公开资料,不便评说,有“好事者”可以贴出来共享一下。

[该贴被banq于2009-12-14 10:41修改过]

atester
2009-12-14 16:33
terracotta收购了Ehcache?

banq
2009-12-14 16:48
2009年12月14日 16:33 "atester"的内容
terracotta收购了Ehcache?

是的,旧闻了。

atester
2009-12-14 17:08
弱弱的问一下,俺在EJB容器中使用CMP管理实体Bean是不是就获得了容器提供的缓存功能?这是不是就是类似Ehcache提供的功能呢?

atester
2009-12-14 17:17
摘录

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



诚如前边大家讨论的,如果伸缩的瓶颈在于数据(库),那么,可伸缩性限制,是不是很大程度上不是因为使用了EJB的框架呢?

如果是,那就是应该更多的倡导not only sql,而并不是no ejb? 毕竟ejb带来方便是一堆一堆的,比如在B/S应用中加了一下C/S功能,就可以直接把会话bean发布成web service然后由delphi等工具调用。

[该贴被atester于2009-12-14 17:23修改过]

xysniper
2009-12-14 18:24
2009年12月13日 23:52 "xuejianlong"的内容
业务层(Not Only SQL):1. 需要事务的业务—》EJB会话bean或者SSH。 2. 不需要事务的业务--> MDB或者NoSQL等异步处理(切分,异步,BASE)数据访问层: 1.Hibernate2. 数据缓存:Hibernate + Ehcache + terracotta请指教[该贴被xuejianlong于2009-12-13 23:58修改过]

我不想使用EJB的声明式事务,我想使用hibernate来控制,这样可以有效缩小事务范围,保证良好的性能。另外MDB可以考虑使用,但我想要根据业务特点来决定,另外,是否使用NoSQL,还要再考虑一下,必经是新生事务。感谢xuejianlong

[该贴被xysniper于2009-12-14 18:50修改过]

2Go 1 2 下一页