WebLogic Server 9.0是BEA最新推出的应用服务器版本。这个版本与J2EE 1.4完全兼容,性能有了更好的表现,同时在运行管理方面、可靠性方面有了进一步的提高。同时WebLogic Server9.0提供了非常多的新特性,在运行管理、系统可靠、高效等方面提供了很多使用功能,这里不一一列举,有兴趣可以查看:http://e-docs./wls/docs90/notes/new.html。那么对于我们开发和管理人员,最感兴趣的有哪些,下面着重列出: 应用升级 问题的提出: 当我们将更新应用需要发布到生产系统时,常常会碰到这样的问题:正在进行的业务操作必须中止,将新的应用替换旧有的应用。这样会使当前正在进行的业务操作停止,影响业务工作。另外,从业务上原有未完成的操作,新版本更新之后,如果新、旧版本有差异,会导致前后处理不一致。现在这样的问题,可以在Server9.0很好的解决了。 这一功能就是Server9.0产品模式下应用更新。它可以支持:
访问情况如下所示: 使用该功能要注意以下说明:
Server新加状态说明: 在原有WebLogic Server9.0的运行状态基础之上加入了Admin状态,这一状态的特点是:
因此,使用Server在Admin状态带来的好处:在生产环境部署更新应用时,不用将前端的连接断开,用管理员角色直接进行测试,不再担心前端请求会访问到应用,影响应用的发布和测试。这样对于系统上线前的准备非常有帮助。
如下,是WebLogic Server生命周期图说明:
对于如何切换到Admin状态,有以下两种方式: 1.当WebLogic Server 没有启动时,可以启动Server到Admin状态,在启动脚本startWebLogic.cmd 中java [options] weblogic.Server 命令options选项加入: -Dweblogic.management.startupMode=ADMIN 2.当Server 处于Running状态时,可以在管理控制台,选择Server控制选项,选择Grace Suspend或者Force Suspend将Server切换到Admin状态。 管理控制台中的门户应用程序支持 管理控制台的新架构基于WebLogic Portal Framework,而且管理控制台使用构建在Structs之上的模型-视图-控制器方法,这使得控制台更加开放,更加易于扩展。现在,可以以常用于扩展门户应用程序的方式来扩展管理控制台。控制台扩展可以包括现有页面、新页面和小节,以及JSR 168或WSRP portlet的简单改写。 配置更改的两阶段提交 为了保护修改并防止其他人进行修改,管理控制台中引入了一个新的区域,称为Change Center,在开始修改域配置之前,首先锁定管理控制台。当完成修改时,保存这些修改并将它们发布到域中的所有实例,也可以回滚修改并释放锁定。每台服务器自行决定它是否接收修改。如果所有的服务器都接受修改,它们将更新它们的工作配置树,修改完成。如果有一台或多台服务器不接受修改,那么所有的服务器都不会使修改生效,因此避免了出现未完成的中间状态。这种功能有助于确定WebLogic Server配置信息总是正确和一致的。 生产环境的服务器性能自调整 在WebLogic Server9.0之前,Server的一些性能参数是在Server启动之前设置的,如线程数等,不能随着系统的运行情况进行自动调整,这样可能不会最大限度的使用系统资源。另外,Server上部署不同的应用,但对应用的重要级别不能按照权重分配资源的比例。针对上面的问题,WebLogic Server9.0提供了服务器性能自调整的新特性,可以解决上述问题。而且通过自调整功能简化了对WebLogic Server的配置过程,同时自调整功能有助于防止请求高峰期间的死锁情况。 WebLogic Server中关键的自调整功能包括: 工作负荷(Work Managers)管理——管理员可以在域级别、应用程序级别和模块级别上定义工作调度策略和约束。这样,当我们在WebLogic Server部署多个应用,而这些应用有不同的性能要求,就可以使用Work Managers定义的策略,根据应用的重要情况,分配不同比例的资源。如,网上银行业务有企业银行业务和个人银行业务,因为企业银行业务资金数额大,可靠性要求高,那么就可以使用Work Managers为其分配更多的资源。 自动的线程计数调整——通过基于历史吞吐量和队列大小,自动修改线程池的容量,可以最大化线程池的吞吐量。 线程调度功能——WebLogic Server 9.0实现了commonj work manager API,把线程调度功能公开给开发人员。应用程序也可以使用Work Manager API来异步执行工作,并接收关于执行状态的通知。
Work Manager可以对如下资源进行控制:
Work Managers 可以在如下配置文件进行域级别、应用程序级别和模块级别上定义:
配置示例: <work-manager> 自动的线程计数调整: 在WebLogic Server9.0版本之前,进程有多个执行队列,在不同的执行队列,基于优先级和排队顺序,执行不同的任务,这样可以避免死锁。有缺省的执行队列:weblogic.kernel.default,还有预先定义的队列来做内部管理用,如:weblogic.admin.HTTP和 weblogic.admin.RMI。对性能的调整,可以通过调整缺省队列上的线程数,或者为特定的应用配置自己的执行队列,对这个执行队列指定相应的线程数。 对WebLogic Server9.0,建立了单一线程池,可以执行所有类型的操作。 WebLogic Server基于我们定义的规则和实时运行情况,来调整处理工作的优先级。线程池可以根据系统吞吐情况,自动调整大小。例如,根据历史吞吐量的统计,表明需要更高的线程数量时,WebLogic Server将自动增加线程数目。与此类似,当统计表明减小线程不会影响吞吐量时,WebLogic Server会减少线程数。这一新策略将使管理者更容易配置资源和性能调优,避免向从前一样调整自己的执行队列。 过载保护当系统的负载压力非常大时,如果不对处理容量进行配置,那么会导致内存耗尽(out-of-m异常、执行队列过载等问题。因此在WebLogic Server9.0可以对如下资源进行配置:
广域网或城域网的HTTP会话复制和故障转移 WebLogic Server为我们提供了业界最强的集群功能,它能够实现系统的高扩展性和高可靠性。
整个系统结构见下图: 假定原有集群服务为集群A 提供,在原有负载均衡前配置全局负载均衡器。另外根据Domain A的结构复制建Domain B。这样全局负载均衡器可以根据要求,配置相应负载均衡策略,接收到前端请求时,根据配置,将请求分发给后面的集群。通过复制通道,运行在集群A中的服务器实例上的会话信息,可以被复制到集群B中的服务器实例上。这样当集群A中的某一主Server出现问题时,集群A中的另一个Server可以从集群B获得会话数据,对于此次会话充当主Server。局部负载均衡可以将请求切换到该Server上。如果集群A中所有Server都不能提供服务,局部负载均衡将HTTP请求返回全局负载均衡,全局负载均衡将请求转发给集群B,集群B的局部负载均衡将请求发送给有复制会话信息的Server上。这样就实现了跨集群的负载均衡。这种系统结构会对异地应用备份中心建设有参考意义——建设两个物理位置不同的集群系统,系统部署的应用相同,当其中的一个集群系统发生了网络等故障时,应用的处理可以自动切换到另一个系统,而业务应用不会发生中断。 对跨集群的网络结构,有两种不同的情况:一种为跨城域网(metropolitan area network,MAN)中的集群,另一种为跨广域网(wide area network,WAN)的集群,如地理上相隔很远的地方。对于上述两种网络,跨集群的系统结构是一样的,不同的是会话复制方式不同。 对于跨MAN方式的集群,WebLogic Server提供实时基于两个集群一级的同步会话内存复制,这样要求网络延时比较低,在集群响应时延范围之内。否则会出现超时错误。 处理过程如下:
跨集群容错的几种情况:
对于跨WAN方式的集群,主要使用会话信息通过异步的JDBC持久化到远程的集群实例上来实现容错。对异步的JDBC持久化,即定期地,将会话状态会刷新到远程集群服务器实例上表中的存储器。因为到远程服务器实例的JDBC持久化是异步执行的,它比同步的JDBC复制性能更高,对于在同步JDBC复制情况,数据库写操作延时会影响响应的时间。 处理过程如下:
跨集群容错的几种情况;
上述只是WebLogic Server9.0的几个新特性的介绍,对WebLogic Server在Web Service,JMS,管理框架等方面还是非常值得关注,希望本文对我们今后的使用有所帮助。 |
|
来自: 魔戒 > 《weblogic server》