网上交易平台架构设计

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

有2页 Go 1 2 下一页