一个J2EE系统方案

构造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

请各位大侠来讨论讨论

由于系统有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

聆听ing

学习。。。。。

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

我个人认为,架构2、3、4可以混合使用,没有矛盾的地方,根据你实际运行情况,决定哪个架构占据多数成分,不用不对比,哪能明白啊?

不知道在WEB服务器集群的情况下,附件该怎么放置

是不是做集群的话,只能用:(
架够2:struts+sessionBean+hibernate
架够3:struts+sessionBean+DAO+jdbc,加上cache功能(参考jive,apache的pool)
架够4:struts+sessionBean+cmp)
struts+hibernate似乎不能实现集群吧

很久没人了,自己顶顶

关注ing