发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 3 4 ... 12 下一页 Go 12

谁偷走了我的ejb?

         
2003-11-12 20:45
赞助商链接

首先介绍一下,我所在公司的主要产品是中国移动的BOSS--基础业务
支撑系统,用户总数大约3000人,同时在线1000人,也许这里有的道友
还是同行。

论坛里的帖子看了一些,让我很疑惑的是为什么EJB看来是如此的成功
但我却发现在公司和其它竞争对手中使用EJB的是少之又少

bea不断声称自己的weblogic是如此的出色,以至于weblogic 8出来后
我们这些日日夜夜的不停推磨的驴子简直都可以洗洗睡了。
但具有讽刺意味的,tuxedo可能是bea在中国的企业级应用中使用最受
认可的,稳定而又快速。
倘若bea问我们为什么也买了它的weblogic,我们只能告诉它因为sun的
iplanet不停的挂掉,我们终于受不了,也不敢再相信sun one server
选择weblogic实在只是我们需要一个支持jsp的可靠的web server罢了

我们公司boss系统的结构大约是weblogic(做web server)+tuxedo+存
储过程、事务基本都是放在存储过程中实现的,也许会有师兄说真傻,
好原始。确实,听起来好像就在原始社会,但真是不知道还有多少个公
司和我们做了一样的选择。尽管结构不清晰,代码可读性差,移植性
差,每换一次数据库就是一项浩大的工程,天数的存储过程要改写,
(经常有一些db厂商的好东东让你非常想用,可是等移植的时候就恨不
得全是sql92)。痛苦的就是这样做牺牲的情况下,系统速度还是不理
想,每月初是一个使用高峰,都要过一次小关,阵痛一把。如果用
ejb或者hibernate不知道能不能实现如此复杂的事务,实现了又是什么
样,个人估计就算不死成什么样,也不知道会慢成什么样。
另一公司因为使用jsp+javabeans 两层结构,使用jdbc直连数据库(相
同水平下,理论上速度应比使用ejb更快),慢的导致用户不满,已经
被中途踢掉了。

说到这里,或许有人会说那是因为你们设计不合理,管理不到位,试问
如果我们用c做的出来,用java做不出来,是不是充分证明我们java水
平很低。那其它的公司也做不到,又是什么原因,是不是充分证明我
们整个中国程序员的java水平都很低?倘若是,java门槛这么高,我们
岂不是永远要喝三块钱的稀饭,看着sun、ibm们来大鱼大肉

有人曾经说,为了系统的扩展性,我们应该牺牲一点性能。我不知道他
遇到的是什么样的用户,我们的用户要求是稳定第一、性能第二、扩展
性他们并不关注的,用户并不知道程序是什么的,他们只知道功能是什
么样,是否按照要求实现,扩展性根本不是他们所关心的。不要让我们
陷入程序的误区,因为写程序而写程序。一些工作都是要赚钱的,不正
视肯定要碰钉子,就象拍艺术电影的总看不起拍商业电影,实际上那一
样难度更大,不用说也明白的,如果商业电影容易拍,那帮人早溜光了
去挣大把rmb
//sorry 走题了,:)

也许,在电信这个领域比较特殊,不知道banq、bruce、robbin、icean
们经历过多大的项目,能否以下面的指标指点方向:多少人使用,什么
样的业务复杂度,最大并发数多少,最大并发时每笔事务平均耗时等
数据库表的多少能否表明业务复杂度?我们的表大约是一千多张。请不
要说他们数据库设计水平低,我对设计数据库的同事们有相当信心

其实很想用J2EE,java人不用J2EE就好比鸟儿被剪了一只翅膀,我在
学习hibernate中、希望不久的将来可以有所运用,说sun在搞JBOSS,
做的是同样的工作么?也许象大客户管理,网管,oa什么的可能早点
用上
应该承认java真是很慢,但情人眼里出西施,没办法,我就喜欢

mep
2003-11-13 16:59

如此之多的人认为EJB的性能存在严重的问题,以至于我想说说不同的意见。

首先我想声明,我并不是认为EJB模型没有任何问题,我本身也没有非常丰富的大工程的经验;之所以跳出来出话,可能是因为我的一点点哗众

取宠的心理,再加上一点点探索精神。

对于一个项目,我们首先明确目标是什么。如果是外包的项目,也不会涉及升级的问题,那么扩展性就完全可以抛到一边。如果是自己的项目

,可能就需要明确扩展能力了。我认为你提到的“扩展”是指接入新的应用的能力,与Scalability没有关系,Scalability是指能够应付不同

规模的客户端的能力。如果有误解,请纠正。
我们讨论性能。如果你认为EJB的性能有问题,请证明给我看,最好使用数据来说话。我不认为EJB有致命的性能问题,如果能够列举出数据来

,也算是为我解惑吧。楼上的在文中也说了jsp+javabean+jdbc都不行,就不能证明问题是在EJB模型中。

下面我做一个定性的分析,请有条件的网友能够做一个测试,得到其中的一个延迟的数据。
我们知道,对于一个典型的三层应用来说,大致过程是这样,客户端web browser<==>web server<==>EJB<==>DB,假设“<==>”是指代网络。

那么来分析一下中间大致有哪些过程消耗了大量的时间:
1、从browser到web server的网络传输延迟;如果是internet应用,这个延迟可能达到秒级;web browser处理的时间就忽略不计了。
2、web server除了处理客户的http请求,它还是一个EJB client。那么这里一般使用JSP/Servlet,在web server这一层的时间消耗到了哪里

?我想对于少量客户和大规模的客户群是有不同的情况的。少量客户的情况下,时间可能主要是消耗在了EJB client对请求进行

marshal/unmarshal中,如果有大量的请求到达,那么处理请求的时间就会变长,如果web server成了整个应用的瓶颈,可以考虑一下使用

cluster了(比如apache web server)。
3、从web server到ejb server的网络延迟,这部分的延迟应该是以毫秒来计的。这个网络延迟可能会成为瓶颈吗?我不知道。
4、EJB server的处理。EJB server对数据进行unmarshal/marshal,应该也消耗了不少的时间。java抛出异常、进行type cast等操作都是非常

耗时的操作。如果这部分成为瓶颈,可以考虑Session Bean cluster;
5、从EJB server到DB的网络延迟;
6、DB操作,这部分是耗时的,可以考虑不同数据库操作的频率,以便进行表格、查询的优化。

其中还有事务是比较耗时的。
总之,我认为EJB+三层结构,存在很多优化的空间,如果觉得性能有问题,就找出问题,然后试图去解决它;而不是凭直觉去做判断。
如果考虑成本,可以去评估一下开源的东西。

2003-11-13 17:13

主要是EJB体系过于繁琐,导致了只有专家才能设计出真正高性能的应用,不过这也不矛盾,EJB本来就是"高端"架构,有哪个做高端应用的人不是专家呢?
不过enity bean的确应当是optional的,可能,MS的体系中就没有实体组件,也许它今后能变好.

2003-11-19 11:48


用ejb开发的大部分项目都是为了用ejb而使用,如果不是基于分布,安全的原因,完全不必用ejb,否则只会带来麻烦和更多的花费。

2003-11-19 11:56

可以考虑用c来开发部分模块,或者使用多个application server。 别用ejb了,ejb的会更消耗资源,更慢

12Go 1 2 3 4 ... 12 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com