|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
首先java功能强大的背后是其复杂性,就拿web来说,当今流行的框架有很多,什么struts,spring,jQuery等等,而这无疑增加了java的复杂性。前文汇总和PDF下载:揭开J2EE集群的奥秘面纱
8J2EE集群的神话
8.1生效转移能够完整制止毛病——否认
在Jboss的文档中,全部章节都在告诫你“你真的必要HTTP会话的复制吗?”。是的,偶然没有生效转移的高可用性的办理计划也是可承受而且是便宜的。生效转移并非你设想的那末健壮。
那末生效转移究竟给你带来了甚么?你大概想生效转移能够制止毛病。你看,没有会话的生效转移,当一个服务器实例生效后,会话数据将丧失而招致毛病。经由过程生效转移,会话能够从备份中恢复,而哀求能够被其他服务器实例所处置,用户基本认识不到生效。这是现实,但这是有前提的!
回忆一样我们界说的“生效转移”,我们界说了一个前提是生效转移是在“两个办法挪用之间”产生的。这是说假如你有两个一连的对远程对象的办法挪用,生效转移只会在第一挪用乐成后而且第二挪用的哀求收回前才干产生。
如许,当远程服务器在处置哀求的过程当中生效了会产生甚么呢?谜底是:多半情形处置将会中断而客户端将会看到毛病信息。除非这个办法是等幂的(Idempotent),只要这个办法是等幂的,一些负载平衡器更智能,它会重试这些办法并将它生效转移到其他实例上。
为何“等幂”主要呢,由于客户端不晓得当生效产生的时分哀求被实行到甚么中央。是才方才初始化仍是差未几就要完成了?客户端没法判别!假如办法不是等幂的,在不异办法上的两次挪用大概会两次修正体系的形态,而使得体系呈现纷歧致的情况。
你大概想一切在事件中的办法都是等幂的,究竟,假如毛病产生,事件将被回滚,事件形态的改动都将被复位。但现实上事件的界限大概不包含一切的远程办法挪用历程。假如事件已在服务器上提交了而前往给客户端时收集溃散怎样办呢?客户端不晓得服务器的事件是不是是乐成了。
在一些使用程序中,将一切的办法都做成等幂的是不成能的。如许,你只能经由过程生效转移削减毛病,而不是制止它们。拿在线商铺为例,假定每台服务器能够同时处置100个在线用户的哀求,当一台服务器生效了,没有生效转移的办理计划将丧失100个用户的会话数据并激愤这些用户。而有生效转移的办理计划中,当生效产生的时分有20个用户正在处置哀求,如许20个用户将被生效激愤。而其他80个用户正处于思索工夫或在两个办法挪用之间,这些用户能够通明地取得生效转移。如许,你就需做以下的思索:
- 激愤20个用户和激愤100个用户形成影响的区分。
- 接纳生效转移和不接纳生效转移产物本钱的区分
8.2自力使用能够通明的迁徙到集群布局中——否认
只管一些供给商传播鼓吹他们的J2EE产物有如许的天真性。不要信任他们!现实你要在入手下手体系计划时就要筹办集群,而这将影响开辟和测试的一切阶段。
8.2.1HttpSession
在集群情况中,如我后面提到的,利用HTTPSession有良多限定,这取决于你的使用程序服务器接纳了那种会话生效转移的机制。第一个主要的限定就是一切保留的HTTPSession中的对象必需是可序列化的,这将限定计划和使用程序布局。一些计划形式和MVC框架会用HTTPSession保留一些不序列化的对象(如ServletContext,EJB当地接口和WEB服务援用),如许的计划不克不及在集群中事情。第二,对象的序列的反序列化对功能的影响很年夜,出格是数据库保留的体例。在如许的情况中,应当制止在会话中保留年夜的或是浩瀚的对象。假如你接纳了内存复制的体例,如前所述你必需当心在会话中属性的交织援用。其他在集群情况中的次要区分是在会话不论任何属性修正,你必需挪用“setAttribute()”办法。这个办法挪用在自力的体系中是可选的。这个办法的目标是区分已修正的属性和那些没用到属性,如许体系能够只为生效转移备份需要的数据,从而进步功能。
8.2.2缓存
我履历过的年夜多半J2EE项目都用了缓存来进步功能,同时盛行的使用程序服务器也都供应了分歧水平的缓存用来加速使用程序的速率。但这些缓存都是为那些典范的自力情况计划的,只能在单JVM实例中事情。我们必要缓存是由于一些对象很“重”,创立它需消费大批的工夫和资本。因而我们保护了对象池用于重用这些对象,而不必要在前面创立。我们只要当保护缓存比创立对象更便宜时才干取得功能的进步。在集群情况,每一个JVM实例都要保护一份缓存的拷贝,这些拷贝必需同步以保持一切服务器实例形态的分歧性。偶然这类范例的同步会比没有缓存带来更糟的功能。
8.2.3Static变量
当我们计划J2EE使用程序时,在架构上常常会利用一些计划形式。这些如“Singleton”的计划形式会用到静态变量来在多对象之间共享形态。这类体例在单服务中事情得很好,但在集群情况将生效。集群中的每一个实例城市在它的JVM实例中保护一份静态变量的拷贝,如许就损坏了形式的机制。一个利用静态变量的例子就是用它来坚持在线用户数。用静态变量来保留在线用户数是一个很复杂的举措,当用户进进或分开时就增添和削减它。这类体例在单服务器中相对是好的,但在集群情况将生效。在集群中更好的体例是将一切形态保留到数据库。
8.2.4内部资本
只管J2EE标准不撑持,但为各类目标仍旧会用内部I/O的操纵。比方,一些使用会利用文件体系来保留用户上传的文件,或是创立一个静态设置的XML文件。在集群情况是没有举措来在其他实例之间来复制这些文件的。为了在集群中事情,举措是用数据库作为内部文件的寄存点,别的也能够利用SAN(存储地区网,StorageAreaNetwork)作为寄存点。
8.2.5特别服务
一些特别的服务只在自力的情况中才成心义,准时服务就一个很好例子,这类服务能够在一个流动的距离工夫有纪律的触发。准时服务经常使用于实行一些主动化办理义务。如日记文件转动,体系数据备份,数据库分歧性反省和冗余数据清算等。一些基于事务的服务也很难被迁徙到集群情况中。初始化服务就是个好例子,它只在全部体系启动时才产生。邮件关照服务也一样,它在一些告诫前提下触发。
这些服务是被事务而不是被哀求触发的,并且只被实行一次。这些服务使得负载平衡和生效转移在集群中没几意义。
一些产物筹办了这些服务,如Jboss利用了“集群单例举措措施”来和谐一切实例,包管实行这些服务一次且唯一一次。基于你所选择的平台,一些特别的服务大概会是把你的使用迁徙到集群布局中的停滞。
8.3散布式布局比并置布局更天真——纷歧定
J2EE手艺,特别是EJB,生成就是用来做散布式盘算。解耦营业功效,重用远程组件,这些使很多层使用十分盛行。可是我们不克不及将一切的工具都散布。一些J2EE架构师以为Web层与EJB层并置得越近越好。这些计论前面会持续。先让我注释一下。
如0所示,这是一个散布式布局。当哀求来了,负载平衡器将哀求分发到分歧服务器中的分歧WEB容器,假如哀求包括了EJB挪用,WEB容器将重发EJB挪用到分歧的EJB容器。如许,哀求将被负载平衡和生效转移两次。
一些人看散布式布局,他们会指出:
- 第二次负载平衡没有需要,由于它不会使义务分派更平展。每一个服务器实例都有它们本人的WEB容器和EJB容器。把EJB容器用来处置来自其他实例WEB容器的哀求比只在服务器外部挪用并没有甚么上风。
- 第二次生效转移没有需要,由于它不克不及是高可用性。多半供给商完成J2EE服务器城市在统一服务器中运转的WEB容器和EJB容器放在一个JVM实例中。假如EJB容器生效了,多半情形下在统一个JVM中的WEB容器也将同时生效。
- 功能将下落。想像一下对你的使用的一次挪用包括一组对EJB的挪用,假如你负载平衡了这些EJB,这将超过每一个服务器实例,招致很多不用要的服务器到服务器的交互。另有,假如这个办法在事件局限内,那末事件界限将包括很多服务器实例,这将严峻影响功能。
实践上在运转期,多半的供给商(包含SunJES,WebLogic和Jboss)城市优化EJB挪用机制,使哀求起首选择统一个服务器中的EJB容器。如许,如1所示,我们只在第一层(WEB层)做负载平衡,然后挪用不异服务器上的服务。这类布局我们称之为并置布局。手艺上说,并置布局是散布式布局的一种惯例。
一个风趣的成绩是,既然多半的部署在运转期都演进成了并置布局,为何不必当地接口取代远程接口,这将年夜进步功能。你固然能够,可是记着,当你利用当地接口后,WEB组件和EJB耦合得很紧,而办法挪用也是间接的而欠亨过RMI/IIOP。负载平衡和生效转移分发器没无机会参与当地接口挪用。“WEB+EJB”全体处置负载平衡和生效转移。
但不幸的是,在集群中利用当地接口在多半J2EE服务器中有范围性。利用当地接口的EJB是当地对象,是不成序列化的,这一个限定就使当地援用不克不及保留在HTTPSession中。一些产物,如SunJES,会将当地接口区分对待,使它们能够序列化。如许就能够用在HTTPSession中。
另外一个风趣的成绩是,既然并置布局这么盛行而且有好的功能,为何还要散布式布局呢?这在多半情形下是有事理的,但偶然散布式布局是不成替换的。
- EJB不但被WEB容器利用,富客户端也会利用它。
- EJB组件和WEB组件需在分歧的平安级别上,并必要物理分别。如许防火墙将被设置用于回护运转EJB的主要呆板。
- WEB层和EJB层极度不合错误称使得散布式布局是更好的选择。好比,一些EJB组件十分庞大而且很损耗资本,它们只能运转在高贵的年夜型服务器上,另外一方面,WEB组件(HTML,JSP和Servlet)复杂得只需便宜的PC服务器就可以满意请求。在这类情形下,专门的WEB服务器能够用来承受客户端毗连哀求,很快处置静态数据(HTML和图象)和复杂的WEB组件(JSP和Servlet)。年夜型服务器只被用来做庞大盘算。这将更好的使用投资。
9结论
集群与自力情况分歧,J2EE供给商接纳分歧的办法来完成集群。假如你的项目为做到高伸缩性而利用集群,你应当在你的项目入手下手的时分就做筹办。选择切合你的需求的准确的J2EE产物。选择准确的第三方软件和框架并确保它们能撑持集群。最初计划准确的架构使得能从集群中受害而不是受益。
来自:http://blog.csdn.net/esoftwind/archive/2006/10/20/1342448.aspx译者:ESoftWind
因为能用到多少功能就用多少,不能用就不用!总的来说:要简单要性能好,可以不用框架。你说java复杂,就是因为你把java(j2ee)与这些框架混在了一起。 |
|