一个J2EE系统方案

04-04-19 jia2612
构造5000人左右同时在线访问的WEB系统方案,该系统有在线交易,直接与银行打交道

硬件方案:四台中型商业服务器(大概6万一台),两台做应用服务器(Jboss3.2.3),两台数据库服务器(oracle9i),两组服务器分别做集群

软件架够1:struts+hibernate

架够2:struts+sessionBean+hibernate

架够3:struts+sessionBean+DAO+jdbc,加上cache功能(参考jive,apache的pool)

架够4:struts+sessionBean+cmp

请各位大侠来讨论讨论

         

孤独的我
2004-04-20 13:06
由于系统有5000个同时在线,对应用系统来说,属于中,大型的系统了。

从单纯的系统架构来说,用下面4种都是可以的。

但做一个系统,不仅仅是架构,要既考虑系统的安全性,可靠型,稳定性,

也要考虑项目组的对这些组件的熟悉程度,以及项目开发的投入时间,人力等因数。

如果单纯从架构来说:

我个人觉得,如果公司已经有积累,架构1在开发周期上是最短,如果项目组已经确定在设计模型中确定了边界类,控制类,实体类.那么,边界类,控制类很容易建立和struts的映射关系,而实体类又可以用hibernate映射成数据库实现。那么基本上系统的结构就形成。但缺点是:hibernate不想EJB,在cache方面没有优势那么同时5000的访问,是否又问题,以及出了问题是否有强力的支持,这些都是项目风险。

我个人觉得:架够2是一个比较好的方式,即用了struts的MVC,又使用了hibernate强大ORM能力,同时也可以借助ejb容器强大的cache和安全,事务等的能力。。

架构3,我个人认为,这种方式处理大结果级的返回时候可以用,但全系统的应用是不理想的。

架构4:等于就完整的应用,应用服务器的功能来实现,中间可能再穿擦一些成熟的世界模式来处理性能问题,比如会话外观,值对象,复合实体等。但这个架够需要强大的设计,对程序员要求也高,同样和架够1,架够2有同样的问题,处理大量数据delte和update很不方便,同时在处理数据模型关系很复杂的结构时候,处理很麻烦。

以上是一点点观点,综合来看,其实在架够选则前,还有很多东西要考虑,以后系统业务需求的变化有多大,有可能要支持异构的数据库,是否有可能由于系统性能问题,需要迁移平台到商业化的平台等等。。。这都对架够设计有影响!

而且架够的设计也并不是就不能一呈不变,因为各有各的优势需要取舍,比如

cmp,hibernate对大量的数据delte,update就比较劣势。所以我们也许可以对这样应用直接用jsp+jdbc处理.cmp,和hibernate对大结果级的查询也有劣势,所以也可以改jsp+struste的标记库+sessionBean+jdbc

一点点心得请大家一起讨论!!!

架够1:struts+hibernate

架够1:struts+sessionBean+hibernate

架够3:struts+sessionBean+DAO+jdbc,加上cache功能(参考jive,apache的pool)

架够4:struts+sessionBean+cmp

cats_tiger
2004-04-20 15:42
聆听ing

萧风
2004-04-21 08:57
学习。。。。。

廉价劳力
2004-04-21 13:11
关注,不知道2台jboss能撑得住5000在线吗,如果每人平均10秒按一次页面,就是500 page/seconds,还要考虑峰值情况。

猜你喜欢
2Go 1 2 下一页