weblogic部署和优化

  

 Weblogic是目前主流J2EE服务器之一，支持符合J2EE标准的各类应用程序（Application），Weblogic支持分布式异构体系，能利用多种数据库平台并支持运行于多种操作系统。

weblogic部署

一、     weblogic部署前准备工作

二、     检查weblogic是否已经安装（weblogic 10.3  JDK1.6 ）。

三、     如没有安装联系ICT进行安装。

四、     规划好（端口号、域路径、域名、console账号密码），建域的时候需用到这三个信息。

五、     建weblogic域

1）      运行命令并建域bea/wlserver_10.3/common/bin/config.sh

选择组件

设置域的用户/密码

选择运行模式, 建议使用production模式:

修改端口

设置域的存放路径:

设置域名:

在域的路径下新建boot.properties文件:

补充：到其他域拷贝start.sh webkill.sh

尝试用start.sh webkill.sh 进行域停启

cd 域路径

vi  boot.properties

mkdir  app

六、部署weblogic域

1）      修改config.xml部署

A、    数据库连接配置

jdbc—在/home/spsdev/weblogic/acc/acc/WEB-INF/classes目录下

修改jdbc.properteres、datasources.xml

jndi—在/home/weblogic/acc/accweb1/config/jdbc目录下

    增加getpass.sh  ***-jdbc.xml    trans3des.sh  transinput.sh

配置。上面的文件都可以在其他域的连接池进行拷贝，其中***-jdbc.xml文件要修改相应的数据库连接串和用户，用户密码可以通过执行transinput.sh修改用户密码。

B、     config.xml配置部署

下面是有JNDI连接池的配置方式，如是jdbc去掉相关连接池的配置。

  <configuration-version>10.3.0.0</configuration-version>

  <app-deployment>

    <name>acc</name>

    <target>AdminServer</target>

    <module-type>war</module-type>

    <source-path>/home/weblogic/acc/accweb1/acc</source-path>

    <security-dd-model>DDOnly</security-dd-model>

  </app-deployment>

  <admin-server-name>AdminServer</admin-server-name>

  <jdbc-system-resource>

    <name>jdbc/accdb1</name>

    <target>AdminServer</target>

    <descriptor-file-name>jdbc/jdbc2faccdb1-20120224-jdbc.xml</descriptor-file-name>

  </jdbc-system-resource>

  <jdbc-system-resource>

    <name>jdbc/accdb2</name>

    <target>AdminServer</target>

    <descriptor-file-name>jdbc/jdbc2faccdb2-20120224-jdbc.xml</descriptor-file-name>

  </jdbc-system-resource>

</domain>

2）      控制台console部署

A、登陆控制台http://IP:port/console,输入相应的IP、port和console账号密码。

B、点击“Lock&Edit” ----》再点击“Deployments”----》点击右边“Install”

选择工程代码，一路next 直到finsh。

C、点击”Release Configuration”---》选择新增加的工程，选择“start/Servicing all requests”----》操作完之后，工作的状态会为成Active，代表工程部署成功。

weblogic优化

vi  startWeblogic.sh

一、启动参数设置

1、根据域的情况合理设置域的启动参数，具体可以跟开发沟通设置

trap 'stopAll' 1 2 3 15

MEM_ARGS="-Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m"

JAVA_OPTIONS="-DPOSON_CLASS_PATH=/home/spsdev/weblogic/acc/acc/WEB-INF/classes/  -Ddomain=acc  -Dsys.run.environment=sps -Dfile.encoding=GBK -DspsDev=true -Dwtc.isDebug=FALSE -Dsps.home=/home/spsdev/weblogic/acc/myLog ${JAVA_OPTIONS} -DITOP_SM=OFF"

if [ "${PRODUCTION_MODE}" = "true" ] ; then

      2、部署成功时当出现前台登陆从CA域登陆的时候，需在启动参数加上

-DspsDev=true。

二、weblogic其他参数调整

1) 确保为产品模式

修改启动脚本XX_domain\bin\startWebLogic.sh
确保有如下行
if "%PRODUCTION_MODE%"=="true" (

修改config下的config.xml，确保如下内容
<production-mode-enabled>true</production-mode-enabled>

2)  AdminServer日志大小为500k, 修改Servlet Reload Check Seconds 为-1

3) 关闭debug日志。

三、日志级别设置

系统打印日志会不停进行IO访问，也会占用很多资源，把log4j.properties文件日志打印的级别设置为ERROR，屏蔽了调试的日志。

四、开发模式VS产品模式（搭建weblogic一般选择产品模式）

开发模式和产品模式的一些参数的默认值不同，可能会对性能造成影响。下面是对性能有影响的参数列表：

参数开发模式默认值                         产品模式默认值

Execute Queue: Thread Count 15 threads           25 threads

JDBC Connection Pool: MaxCapacity 15 connections  25 connections

五、IO参数调优

在IO频繁的系统，特别是开发环境，经常出现连接不上的时候，可以根据系统机器性能修改系统的IO参数：

具体方法如下

ulimit   -n  123440000

linux内核参数调整，修改最大文件数，用ulimit -n 修改open files 总是不能保持。

修改/etc/security/limits.conf 添加如下一行：

* - nofile 1006154

修改/etc/pam.d/login添加如下一行

session required /lib/security/pam_limits.so

ulimit  -a

core 参数

ulmit –c unlimt /4324234

六、weblogic线程数

WebLogic 9 / WebLogic 10 的线程池是自调优的，可以通过修改config.xml可以修改默认线程池的最小值、最大值。

如下为config.xml参数文件：

<server>

    <name>AdminServer</name>

    <execute-queue>

      <name>default</name>

      <thread-count>200</thread-count>

      <threads-maximum>200</threads-maximum>

    </execute-queue>

    <use81-style-execute-queues>true</use81-style-execute-queues>

     <listen-address></listen-address>

  </server>

也可以通过在启动脚本增加如下参数，可以指定默认线程池的最小值、最大值：

-Dweblogic.threadpool.MinPoolSize=100

-Dweblogic.threadpool.MaxPoolSize=500

附：

拷贝命令：

SCP  –R  路径/*  用户名@目的IP：目的路径

查看端口：

netstat –an|grep 端口

netstat –an|grep 端口|wc  -l

查看日志：

tail –f  nohup.out

前台访问应用看nohup打日志

weblogic日志

webLog

第二篇：WebLogic应用优化解决方案

BEA WebLogic 平台应用优化解决方案

1. BEA WebLogic系统应用及面临的挑战

随着互联网的迅速普及和电子商务的迅猛发展，应用服务器市场的发展呈现出百花争艳的景象，而以Java技术为基础平台的应用服务器架构，更由于其独特的优势成为应用服务器领域中的中坚力量，并占据了绝大多数的应用服务器市场。

在现今的应用服务器系统平台中，虽然软件实现平台各有不同，但各应用平台的架构基本一致，最终实现目标均为满足一个具有稳定、高效、高可扩展性和高可管理性等特性的业务应用，并且无论是否提供关键性任务的服务，都需要一个持续运行，并提供高可用性的网络/主机环境，以提供不间断的高品质服务。

WebLogic Server是美国BEA公司开发的一个业界领先的应用服务器。是SUN J2EE的纯Java实现。WebLogic长期以来一直被认为是市场上最好的J2EE工具之一。BEA WebLogic 是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器，在很多行业中均有着广泛的应用。在各行业的应用中，占有重要的地位，发挥着重要的作用。BEA WebLogic Workshop是一个统一、简化、可扩展的开发环境，使所有的开发人员都能在 BEA WebLogic Enterprise Platform之上构建基于标准的企业级应用，从而提高了开发部门的生产力水平，加快了价值的实现。

像数据库或邮件服务器一样，WebLogic Server对于客户是不可见的，旦为连接在它上面的客户提供服务。WebLogic最常用的使用方式是为在internet或intranet上的Web服务提供安全、数据驱动的应用程序。

WebLogic对J2EE架构的支持：WebLogic Server提供了对SUN J2EE架构的支持。SUN公司的J2EE架构是为企业级提供的一种支持分布式应用的整体框架。为集成后端系统，如ERP系统，CRM系统，以及为实现企业级计算提供了一个简易的，开放的标准。

在WebLogic应用平台中，如正常运行的应用的各个系统，仅通过单台主机/服务器，或采用备份服务器通过冷备的方式避免单点故障，期望完成稳定、可扩展的功能，将会在实际应用中面临以下问题和挑战:

1.1. WebLogic服务器之间自动切换所面临的问题

在WebLogic应用系统中，可以通过创建实例（Instance），在一台主机上模拟多个应用前端来响应用户的访问请求。每一个应用前端可有不同的IP地址和端口，在最终用户看来就像有多台服务器在同时提供应用服务。这种方式可以在应用层较好的达到持续提供服务的目的。

1

然而在实际应用中，多个实例的实现方式给访问者造成了很多不便，用户必须记住多个实例的域名，同时无法了解每个域名所代表的实例的运行状况。更严重的时，由于所有实例均在一台主机上运行，当主机出现故障时所有的实际均将停止提供服务，将面临整个系统平台停止工作的风险。

1.2. 处理能力有限且扩容能力有限

随着应用负载的增大，各个实例上所要处理的数据量将增大，从而影响了对用户的响应效率，造成对访问者的请求回应越来越慢等严重影响服务质量的现象。在主机方面和WebLogic系统上则直接表现为可容纳的连接数越来越小，系统性能严重下降等现象。

此时，将需要考虑增加应用实例和主机的数量来满足不断增大的应用负载需求。当仅通过主机集群（Cluster）的方式实现扩容时，将存在成本较高，严重影响正常服务的提供等问题，且扩容能力有限，无法满足不断增长的应用的需要。

1.3. WebLogic服务器主机“多米诺”现象

使用单台主机设备来满足应用时，受各种条件的影响，不可避免的将出现主机故障等问题，而任何单点故障都将直接影响到业务的正常提供，造成极大的损失。考虑到主机的冗余备份，需要有主机冗余设置来处理和接管出现故障主机的工作。传统方式是通过一台或多台主机，采用冷备份方式来实现，当正在工作的主机出现故障时，进行人工切换到备份主机上。

这样做，除了会产生时效性的问题外，还将无法同时利用所有硬件平台的资源，应用投资得不到充分保护。特别是，当出现超过单台主机的负载情况时，所得到的将是“多米诺效应”，即包括冷备份主机在内的服务器组将依次被过高的负载压垮，直至无主机设备可用。

1.4. WebLogic系统发展与网络扩容的不平衡性

随着新功能的加入和用户数的增多，WebLogic系统拓扑结构需要变化的情况将随时有可能发生，如何使应用平台适合今后发展扩容的需要，完全依靠专业技术队伍通过更改服务器配置或网络拓扑等方式进行网络调整的方式，将存在大风险、非实时性、缺乏灵活性等缺陷。如何能够在业务正常运行的情况下进行按需增长的、动态的、且对最终用户是透明的网络调整和更新扩容，已经成为WebLogic系统应用中迫切需要解决的问题。

1.5. 系统维护升级等问题将给相关人员造成极大的压力

离不开应用系统的日常维护，而在线系统的维护操作，WebLogic应用平台的稳定运行，

将会给正常应用中的WebLogic平台带来了安全隐患。在主机操作系统和应用程序的调整和升级过程中，将会由于需要重新启动正在提供服务的应用程序，甚至重新启动操作系统而使此类工作很难进行下去。有限的维护、升级时间，将对应用造成很大风险的同时，给各个方面的相关人员造成很大的压力。

2

2. Array Networks WebLogic系统平台优化解决方案

在WebLogic应用平台中，通过Array AppVelocity系列产品的应用，从处理能力、扩展能力、安全性、应用的便利性等方面提供了负载管理和性能增强功能，能够满足WebLogic

应用平台对持续性和稳定性的需求。如图：

（Array AppVelocity WebLogic应用优化解决方案拓扑结构实现流程图）

2.1. 通过Array AppVelocity的服务器负载均衡功能提高系统的高可用性

Array AppVelocity产品解决方案中所指的高可用性，同时也是实施和维护WebLogic系统平台时所需考虑的，主要指以下几点：

1. 使数据始终以一个稳定、安全的方式处理，即便存在单台设备不能提供服务时，仍

能保持数据的完整性。通过智能识别检查，使整体服务持续稳定运行，即便发生单点或多点故障仍然能够保证正常提供服务。

2. 使整个网络环境能够更好的被管理，提供AppVelocity设备本身容灾集群（cluster）

功能、服务器集群共享、应用和后台服务器方便维护等特点。

3

3. 使投入有更好的效益和最佳的扩充能力，即在保证数据完整性的同时，提供系统持

续运行的能力，并实现当用户量的增大的情况下，在不影响应用的情况下，通过增

加主机的方式，响应用户负载的增加，保证了用户投资具有很高回报。

4. 即便在应用软件不够完善，如经常出现故障不能提供服务的情况下，仍然能够持续

保证应用系统持续在线能力。

首先在WebLogic应用服务器故障切换方面，通过多台WebLogic服务器主机与Array AppVelocity产品的负载分担功能和性能增强功能相结合，实现稳定可靠的应用提供。（如下图所示）

根据上图示拓扑结构，在常见的三层架构实现方式中，通过Web Server, WebLogic APPServer和数据库服务器，三步分来实现不同的应用功能，处理用户的访问请求。

在所有服务访问中，最终用户始终仅通过向AppVelocity上配置的一个Virtual IP及提供服务的端口进行通信交流，并感觉不到切换所发生的任何变化和延迟。在两台

AppVelocity产品以Active-Active方式同时工作的同时，其中任何一台AppVelocity出现故障，所有应用请求将自动被另一台正常工作的AppVelocity处理。

当AppVelocity接收到针对应用的访问请求时，将根据预先配置，将访问请求发送到后台最合适的服务器或实例上进行处理。从而实现了对后台WebLogic平台服务器的负载均衡功能，当某台服务器（Web Server/App Server）出现故障，不能实现相应功能时，AppVelocity系列产品能够自动发现故障设备，并将接下来的访问请求发送给其它能够正常提供服务的实例或服务器上进行处理，避免了由于某台服务器或实例的故障而影响了整体的业务的提供，保证了整个WebLogic应用平台的高可用性。

完全可信赖的服务器(实例)状态检测和智能负载分担：AppVelocity可以实现动态分配每一个流量请求到后台的服务器，并即时按需动态检查各个服务器的状态，将下一个请求分配给最有效率的服务器，当任何服务器或应用程序不能正常提供服务时，AppVelocity能够检测到，并将会把接下来的访问请求分配给其它服务器，从而避免了由于后台某个服务器或应用的问题而影响了整个业务的提供。Array AppVelocity支持多种服务器负载均衡算法（持续性的和非持续性的），包括轮循算法、最少连接算法、响应时间算法、散列算法、最少连接失误算法，链路带宽算法等等。保持性算法包括，Http Header 、hash IP、cookiet、URL等，保证应用的连续性。此外实际服务器可以被分配不同的加权值来调整被分配的流量。可以使性能高的大型服务器支持更多的负载。为了避免服务器因过载而崩溃，可为实际服务器指定最大连接阈值来避免该服务器过载。

2.2. Array解决方案为WebLogic应用平台提供应用性能增强

具有基于服务器负载分担的多种性能增强功能：采用AppVelocity负载均衡功能后，AppVelocity可以智能寻找最佳服务器从而保证客户得到响应最快服务器所提供的最佳服务。同时结合AppVelocity产品中性能增强功能的应用，如Cache技术、压缩技术、连接复用技术，在减小对后台服务器的负载的同时减小和后台服务器遭受应用攻击的可能。

4

2.1.1. Array Networks基于SpeedStack核心技术

ArrayOS通过SpeedStack技术构建其产品的。Array的SpeedStack技术由三部分组成：一个TCP/IP栈、HTTP分析器和一个代理引擎。这种独特的架构让Array及第三方的开发人员可以在数据流的多个环节来实现垂直应用程序与SpeedStack的关联。TCP/IP栈在数据包进入系统时首先对其进行处理。TCP/IP栈通过高效的包处理来实现高性能，在处理流程的初期及时检测出有害或已损坏的数据包并将它们丢弃。TCP/IP栈的工作完成后，数据包就被交给了HTTP分析器，它以独特的方式对HTTP包头进行分解，使其它组件不必再重复相同的工作。分析引擎本身已经进行了优化，能够完成精确的HTTP处理，性能出色。

2.1.2. Cache 缓存功能提升应用相应能力

基于内存的反向代理Cache功能。通过Cache功能的应用，AppVelocity系列产品能够在内存中以数据包的形式Cache住网站页面中所有可以被Cache住的内容。当用户访问请求发送到AppVelocity时，如果Cache中的内容能够匹配用户的访问请求则直接由AppVelocity来响应用户的访问，从而避免了对后台服务器的负载压力，在减小了后台服务器负载的同时，提高了对用户的响应速度和整体网站的处理能力。

在提高Weblogic应用相应能力同时，降低服务器的负载，这样也可以节省用户关于服务器的软硬件投资。通过为每个应用进行Cache设置，对于某些页面可以达到提高80％的HTTP响应能力，极大提高单台服务器的响应连接数量。

2.1.3. Connection Multiplexing（连接复用）技术降低服务器负载

主要作用是为了改善现有系统的总体性能，其技术原理是自动实现HTTP 1.0到HTTP

1.1的转换；TCP/IP协议栈在处理长连接时具有更好的性能；将Web流量的多个短连接合并为一个长连接。同时结合Array 的Connection Pooling（连接池）技术，其优点在于：

? 加快了与后台服务器之间的TCP/UDP连接处理速度

a) Array AppVelocity预先与后台服务器之间建立多个连接，并保持住它们(每

个服务器最多预先建立20个连接)；

b) 如果有客户端的请求，根据负载分担算法被分配到某个后台服务器上，

Array AppVelocity从预先建立的该服务器的连接池中选择一个连接，在此

连接上发送客户端的请求，一个连接可以被用来传送多个请求(每个连接最

多可以同时处理90个请求)；

c) 显著的减少了后台服务器需要处理的用户端连接数(减少量可能达90%)

? 改善了服务器的性能.

a) 服务器不需要花费更多的时间处理TCP/UDP连接建立和拆除的工作

b) 服务器不需要耗费更多的资源保持多个客户端连接

5

2.1.4. Http 压缩功能提高线路带宽利用率

窄带访问应用的访问速度和服务质量的保证一直是网站推广和扩大用户访问所急待解决的问题。通过AppVelocity系列产品中HTTP压缩功能的应用，能够提高网站访问的通信质量，在向窄带宽用户提供很高的通信质量的同时，还能够极大的节约网站互联网接入带宽消耗。

采用Array HTTP压缩的优势：节省带宽；缩短用户下载内容的时间；在Web Server上不需要压缩功能，减轻了Web Server的负担。

2.3. 通过Array的设备提升Weblogic系统的安全防护能力

Array提供状态检测防火墙和入侵防护功能： AppVelocity产品支持地址翻译技术和安全地址映射功能，通过默认情况下此技术的实现，访问客户不可能知道真正提供的服务器的IP地址与端口，同时通过AppVelocity产品中Webwall防护墙和入侵防护功能（此功能通过美国ISS X-Forced入侵防护功能认证）的应用，能够按需实现对AppVelocity产品及应用的安全防护，另外，AppVelocity的管理全部采用SSH和SSL over Http技术，可以防止来自内部或互联网上的攻击。

2.4. 方便后台应用和产品自身的扩展：

AppVelocity产品可以支持动态增减或删除其负载服务器群组的任何数量的服务器，而不需要对客户端或后台做任何改变，从而使系统能够轻松实现扩展。同时，在最初仅实现服务器负载均衡功能，或其它功能的同时，根据用户的实际应用及性能增强功能的需要，按需进行AppVelocity产品功能激活，真正实现无需增加网路设备和更改网络架构的前提下实现相应功能，轻松方便且在相对用户透明的情况下实现扩展。

用户部署Weblogic应用更加容易，只需简单的配置AppVelocity设备即可增加服务器器或相应线程。

2.5. 需求总结 关键的挑战和需求

多台Web服务器或多线

程的负载分担

应用加速 解决方案描述 通过Array 的SLB功能提供多台服务器的负载均衡功能。通过智能识别检查服务，使整体应用持续稳定运行，即便发生单点或多点故障仍然能够保证正常提供服务。 通过Array 的多种加速技术，连接复用、共享池、Cache、压缩

等提高主页访问质量，将服务器的运算卸载到Array的

AppVelocity设备上，降低高校对于服务器的投资。同时能够极

大地节省专线费用。

Array OS的Full Proxy技术、WebWall防火墙功能、防DOSWeblogic应用系统安全

6

提升

应用部署方便扩展 攻击等 AppVelocity产品可以支持动态增减或删除其负载服务器群组的

任何数量的服务器，而不需要对客户端或后台做任何改变，从而

使系统能够轻松实现扩展。

3. WebLogic应用优化解决方案为用户带来的益处

通过Array的解决方案满足WebLogic应用的优化需求具有以下优点：

? 消除WebLogic系统平台的隐患：

传统WebLogic系统平台应用过程中存在单台主机设备发生故障时，整个

WebLogic系统平台不能正常工作等问题。通过Array解决方案的应用，能够消除此类隐患，使WebLogic系统平台具有智能判断和处理的功能，即便某些设备发生故障，整个WebLogic系统平台应用仍能够正常运行，保证了应用的高可靠性。

? 提高WebLogic系统平台的处理能力：

传统WebLogic系统平台因采用的是热备份的方式，同一时刻只有一台应用服

务器工作，而备份设备不进行应用处理，使得处理能力很难得到提高，无法同时发挥所有设备的处理能力。通过Array解决方案的应用，能够最大化的利用后台主机的资源，使多台应用服务器、主机在互为备份的情况下还可以同时工作。结合Array的性能优化功能如Cache、连接复用、压缩等模块，极大的提高了整个WebLogic系统平台的处理能力。

? 方便WebLogic系统平台的扩展：

传统WebLogic系统平台应用处理能力受限于应用服务器主机的性能，很难根

据应用的需求进行透明扩容，通过Array解决方案的应用，能够随着应用负载的需求进行按需透明扩容，最大化的保证了WebLogic系统平台的可扩展性。

? 降低系统维护难度和成本：

WebLogic系统平台上运行的通常为关键业务或生产系统。作为在线系统，需

要持续对WebLogic系统平台进行维护和管理，对应用系统的维护将极大的增大设备运行风险，并对应用平台维护人员造成极大的压力。通过Array解决方案的应用，在充分发挥Array产品智能特性的基础上，可以按需随意的下线和上线应用系统，在不影响应用的基础上对设备进行充分全面的维护和处理，降低了运行风险，减小了维护的难度。

7