网上交易平台架构设计
|
[该贴被xysniper于2009-12-12 12:26修改过]
[该贴被xysniper于2009-12-12 12:26修改过]
个人以为做电子商务架构，参考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修改过]
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不断启动，应用逐渐变慢，导致机器崩溃
膜拜一下MM架构师
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呢？
[该贴被banq于2009-12-12 18:18修改过]
看到这个设计不知道该说什么，感觉很奇怪，是很多公司很经典的设计（当然不是很大型的系统），这样的设计最后会是一个很臃肿的结果，很难维护，性能不会好的。
2009年12月12日 21:56 "jzxw"的内容
看到这个设计不知道该说什么，感觉很奇怪，是很多公司很经典的设计（当然不是很大型的系统），这样的设计最后会是一个很臃肿的结果，很难维护，性能不会好的。
看到这位大哥的回复，很想知道原因，是不是臃肿在EJB这块，能不能讲讲你的思路，你认为像网上交易平台这样的网站应该怎么设计？希望能得到你高人的指点
综合以上理解如下：
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修改过]
淘宝的架构如何？
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修改过]
terracotta收购了Ehcache？
2009年12月14日 16:33 "atester"的内容
terracotta收购了Ehcache？
是的，旧闻了。
弱弱的问一下，俺在EJB容器中使用CMP管理实体Bean是不是就获得了容器提供的缓存功能？这是不是就是类似Ehcache提供的功能呢？
摘录
所以，如果你要做分布式，需要可伸缩性，就不能用EJB，虽然EJB本身也是可伸缩的，但是它和关系数据库一样，是在一个盒子内的可伸缩，而不是廉价的 方便的 无边际的可伸缩。
诚如前边大家讨论的，如果伸缩的瓶颈在于数据(库)，那么，可伸缩性限制，是不是很大程度上不是因为使用了EJB的框架呢？
如果是，那就是应该更多的倡导not only sql，而并不是no ejb? 毕竟ejb带来方便是一堆一堆的，比如在B/S应用中加了一下C/S功能，就可以直接把会话bean发布成web service然后由delphi等工具调用。
[该贴被atester于2009-12-14 17:23修改过]
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修改过]