WebLogic Server9.0产品重点新特性介绍

　　WebLogic Server 9.0是BEA最新推出的应用服务器版本。这个版本与J2EE 1.4完全兼容，性能有了更好的表现，同时在运行管理方面、可靠性方面有了进一步的提高。同时WebLogic Server9.0提供了非常多的新特性，在运行管理、系统可靠、高效等方面提供了很多使用功能，这里不一一列举，有兴趣可以查看：http://e-docs.bea.com/wls/docs90/notes/new.html。那么对于我们开发和管理人员，最感兴趣的有哪些，下面着重列出:

应用升级

问题的提出：

　　当我们将更新应用需要发布到生产系统时，常常会碰到这样的问题：正在进行的业务操作必须中止，将新的应用替换旧有的应用。这样会使当前正在进行的业务操作停止，影响业务工作。另外，从业务上原有未完成的操作，新版本更新之后，如果新、旧版本有差异，会导致前后处理不一致。现在这样的问题，可以在Server9.0很好的解决了。

　　这一功能就是Server9.0产品模式下应用更新。它可以支持:

• 在不中断客户端访问的情况下升级Web和企业应用。
• 在现有应用存在的前提下，并列部署更新的应用版本
• 新的应用版本处于“激活”状态
• 现有应用处于“退休”状态
• 新的客户请求被路由到新的版本
• 现有处理中的客户请求被路由到旧的版本
• 在所有现有客户端完成工作，或是超时后，WebLogic Server将旧版本将解除部署

　　访问情况如下所示:

　　使用该功能要注意以下说明:

• 在产品模式下有效
• 客户端必须通过到Web应用的HTTP访问服务器
• 因此支持WAR和EAR部署
• Web服务、Java RMI等非HTTP访问方法不能使用版本化应用
• 应用应完整，最好使用应用涵盖的JDBC和JMS

Server新加状态说明:

　　在原有WebLogic Server9.0的运行状态基础之上加入了Admin状态，这一状态的特点是:

• Server是运行状态，但只对管理员角色级的操作有效，
• 管理控制台是有效的，只接受管理员角色的请求，对来自所有非管理员的请求都会被拒绝。
• 应用在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可以对如下资源进行控制:

• Fair Share Request Class: 对请求指定线程使用时间所占百分比。例如，Server上运行两个模块，Work Manager指定模块A的Fair Share Request Class为80，指定模块B的Fair Share Request Class为20。当有大业务压力时，请求数量超过线程数，这时WebLogic Server将会分别安排80％和20％的线程使用时间给模块A和模块B。
• Response Time Request Class: 指定响应时间（毫秒为单位）。此时间不是指某一具体的请求响应时间，而是请求处理的平均响应时间。 WebLogic Server会根据响应时间减去平均处理时间，得到容忍等待时间。Server调整前端请求压力，以使平均等待时间和容忍等待时间成比例。例如，Server上运行两个模块，Work Manager指定模块A的响应时间目标为2000ms，模块B的响应时间目标为5000ms，当到大压力情况下，WebLogic Server控制分配到模块A和模块B的请求，使得响应时间大致在2:5。实际的平均响应时间可能会比设定的响应时间高或者低，但响应时间比会大致相同，如模块A的响应时间为1000ms，那么模块B的响应时间会在2500ms。
• Min Threads Constraint: 最小线程限制，这样可以给一些请求分配最小线程数，防止请求申请新线程，而资源没有，产生死锁。
• Max Threads Constraint:最大线程限制，当请求达到最大的线程限制之后，Server将不会接受新的请求处理，直到当前的线程数目下降了。
• Capacity Constraint：容量限制，当到达这一容量限制时，Server会拒绝前端请求，这样保障了Server不会被资源过度消耗，达到系统可靠服务的目的。容量数目包括：等待请求和处理请求之和。

Work Managers 可以在如下配置文件进行域级别、应用程序级别和模块级别上定义:

• config.xml—Work Manager指定应用或应用模块的约束条件，可以使用Server Console来定义Work Manager.
• weblogic-application.xml—Work Manager指定应用或应用内模块的约束条件
• weblogic-ejb-jar.xml or weblogic.xml—Work Managers 指定模块的约束条件
• weblogic-web-app.xml—Work Managers 指定应用的约束条件。

配置示例：

  responsetime_workmanager
    
      my_response_time
      2000
   

自动的线程计数调整:

　　在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可以对如下资源进行配置:

• 因为在Server9.0使用了单一线程池，因此可以在管理配置时，指定最大的队列数目。超过这一配置，Server将会拒绝请求。请求包括：Web 请求；非transaction的RMI请求。为了保证在这种情况下，管理员还可以对Server进行管理，可以配置管理通道来管理，指定的最大队列长度不会包括管理通道数目。
• 在Web应用中限制HTTP 会话数目。这样当到达最大的会话数目之后，Server将拒绝请求创建新的会话。如果是集群环境，其中一实例到达最大会话数，那么将通过Proxy转发到另外一个实例上。
    12
  
• 内存溢出系统自动退出。即当系统运行时，出现内存溢出错误，Server就会自动停机，避免应用处于不稳定运行状态。然后，可以通过节点管理服务器或者其它工具将Server自动重启，缩短宕机时间。配置如下:

   
            system-exit
       

• 过载状态。如果运行实例处于Work Manager容量超限或者低内存状态，Server9.0通过ServerRuntimeMBean.getHealthState()，可以获得Server 新的一个状态Overloaded.可以提示Server已处于不正常状态，便于管理员对系统状况清楚的了解。

广域网或城域网的HTTP会话复制和故障转移

　　WebLogic Server为我们提供了业界最强的集群功能，它能够实现系统的高扩展性和高可靠性。

• 高扩展性– 当系统的整体性能不能满足业务压力要求时，为了提高吞吐量，不需要做应用代码的更改，只要做系统横向或纵向的扩展，在集群中动态地添加新的server，部署相应的应用。这样可以充分利用现有设备时，并保证了系统良好的扩展性。
• 高可靠性– 同样的服务可以由集群中的多个server来提供。对会话信息等采用Server上备份的机制，这样当其中一个server发生故障时，另一个server可以接管发生故障的server继续工作。前端业务可以继续完成，确保了系统7×24高可靠服务。

   

• 在IT系统建设的时候，集群系统都在一个局域网内，来实现负载均衡和容错。但是当这一局域网系统有问题时，就无法提供服务了。在WebLogic Server9.0提供了更高层面的集群服务——跨域的容错服务，可以很好的应对这个问题。

   

整个系统结构见下图：

　　假定原有集群服务为集群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提供实时基于两个集群一级的同步会话内存复制，这样要求网络延时比较低，在集群响应时延范围之内。否则会出现超时错误。

处理过程如下：

• 客户端将请求发送给全局负载均衡器；
• 全局负载均衡器将请求根据会话情况，将请求发送给后端，图示为发送给局部负载均衡器1；
• 局部负载均衡器1接收到请求，根据策略，发给后面的Server实例，如S1；
• 当S1创建完会话后，会自动在另外的集群中选择一运行实例，复制会话信息，如S6；

　　跨集群容错的几种情况：

• 当集群1中的主实例 S1出现问题时，集群1中的S2或S3会从S6中取得备份的会话信息，充当主实例，S6继续从充当备份实例。
• 当S6出现问题，无法服务，则S1会自动在在Cluster2中再选择一个实例充当其备份实例，将会话信息复制过去。
• 当集群1中所有实例服务出现故障，如网络问题。这时，全局负载均衡器将把请求转发给集群2，集群2中的实例接收对应请求，进行处理。

　　对于跨WAN方式的集群，主要使用会话信息通过异步的JDBC持久化到远程的集群实例上来实现容错。对异步的JDBC持久化，即定期地，将会话状态会刷新到远程集群服务器实例上表中的存储器。因为到远程服务器实例的JDBC持久化是异步执行的，它比同步的JDBC复制性能更高，对于在同步JDBC复制情况，数据库写操作延时会影响响应的时间。

处理过程如下：

• 客户端将请求发送给全局负载均衡器;
• 全局负载均衡器将请求根据会话情况，将请求发送给后端，图示为发送给局部负载均衡器1;
• 局部负载均衡器1接收到请求，根据策略，发给后面的Server实例，如S1;
• 当S1创建完会话后，会采用异步的JDBC调用方式，将自动在另外的集群中选择一运行实例，复制会话信息，如S6;

　　跨集群容错的几种情况;

• 当集群1中的主实例 S1出现问题时，集群2中的S6充当主实例，会话信息会备份到第二个实例上。
• 当集群1中所有实例服务出现故障，如网络问题。这时，全局负载均衡器将把请求转发给集群2，集群2中的实例接收对应请求，进行处理。　　

　　上述只是WebLogic Server9.0的几个新特性的介绍，对WebLogic Server在Web Service，JMS,管理框架等方面还是非常值得关注，希望本文对我们今后的使用有所帮助。