
前阵子有个朋友问我Weblogic怎么装我下意识回了一句装倒是简单部署起来你会想骂人。后来想想这话不太客观Weblogic在你真正理清它的安装、建域、部署这套链路之后其实挺顺手的只是它跟Tomcat这类轻量中间件的思路差别太大很多人一上来就被绕晕了。这篇文章想把整个Weblogic安装与部署的流程从头到尾捋一遍从版本选型、静默安装、域管理到应用发布、安全加固和常见故障排查尽量把我在生产环境里踩过的坑和实际验证过的方案写清楚。不管你是第一次接触的运维新手还是被分配去接手老系统的开发按着这篇的思路走一遍应该能少走不少弯路。1. 安装前的准备工作与版本选型1.1 Weblogic到底是什么为什么还要单独装它很多从Spring Boot时代入行的朋友对Weblogic其实是有点陌生的毕竟现在开发环境里内嵌Tomcat、Undertow太常见了一个java -jar就能把服务跑起来。但企业级项目尤其是金融、政企、电信这些行业里的存量系统仍然大量跑在Weblogic上。它不是一个简单的Servlet容器而是完整的Java EE应用服务器提供EJB、JMS、JTA分布式事务、连接池、集群、统一管理控制台等一整套能力。我对它的定位一直很直接它是一个体重偏大、但功能极其齐全的Java运行容器。你要在它上面跑一个简单的Spring Boot应用也行但要发挥它的价值通常是承载老牌企业应用或者需要集群、高可用、统一运维管理的生产环境。所以“为什么还要单独装它”这个问题答案不是“它比Tomcat好”而是“项目要求、系统架构和历史包袱决定了你必须会用这一套”。安装Weblogic本身不复杂复杂的是安装后那一堆概念域、管理服务器、受管服务器、数据源、部署目标。这些如果没搞清楚就算装成功了也不知道下一步该干什么。这也是我写这篇文章时想重点讲透的部分。1.2 版本怎么选JDK怎么配对选版本这件事看起来简单实际上一开始选错后面全是泪。Weblogic目前的版本线大致有三类版本适用场景常见JDK10.3.6老系统维护、存量项目JDK 1.6 / 1.712.2.1.4新部署推荐最主流JDK 1.814.1.1.0需要较新规范支持的新项目JDK 11我个人的建议是如果是全新部署优先选12.2.1.4这个版本是目前生态最成熟、网上能查到的资料最多、各种兼容性问题最少的一个版本。14c虽然新但实际生产使用的比例还没上来很多第三方框架和自研组件的兼容性验证不够充分。10.3.6就别碰了除非你接手的就是老系统否则没必要给自己挖坑。JDK配对问题是我见过翻车最多的地方。有人把JDK 11配到12.2.1.4上启动直接报错各种莫名其妙的ClassNotFoundException。安装前一定先用java -version确认当前JDK版本再去对应选择Weblogic版本。12.2.1.4用JDK 8是最稳妥的组合14c才需要JDK 11。这一点写进你的部署文档里能省掉很多排查时间。1.3 安装介质下载与环境规划安装介质一般从Oracle官网下载Weblogic Server本体是fmw_12.2.1.4.0_wls.jar这个文件。如果还需要完整的基础设施组件比如Coherence、JRF等需要下载fmw_12.2.1.4.0_infrastructure.jar。普通场景我只装WLS本体就够了JRF这玩意儿体积大、安装慢装完还会给运维增加额外负担。环境规划这件事很多人忽略我吃过大亏。建议在安装之前就把目录结构定好比如/u01/app/oracle/product/fmw # 中间件安装目录 /u01/app/oracle/admin/base_domain # 域目录 /u01/app/oracle/logs # 日志统一目录目录规划有几个原则第一不要装到有空格或者中文的路径下后面写脚本时你会感谢自己第二安装目录和域目录分开升级、备份、迁移都方便第三日志单独挂一个目录或磁盘避免日志把根目录写满导致系统异常。另外Linux环境下记得把文件句柄数调大至少ulimit -n到65535否则并发一上来Weblogic就会报“too many open files”。2. 两种安装方式实操图形化与静默安装2.1 图形化安装流程详解图形化安装适合第一次接触Weblogic、想在本地环境快速验证的场景。在Linux有图形界面的桌面环境里直接运行或者本地Windows上装也都行。执行命令java -jar fmw_12.2.1.4.0_wls.jar安装向导会一步步引导你操作选择安装目录、选择安装组件、确认安装类型。这里有一个点我想特别提一下安装类型千万别手滑选了“完整安装”那个会附带很多你用不上的组件比如Coherence、WebLogic SCA等。除非你有明确需求否则就选“WebLogic Server”这个核心类型安装时间、占用的磁盘空间都会少很多。图形化安装本身没什么坑唯一麻烦的是在无图形界面的服务器上你得先配置X11转发或者用VNC连上去操作体验比较痛苦。而且生产环境里为了规范化和可重复也不建议在图形界面里手动点来点去。见过太多人图形界面装一套、命令行再装一套最后两边配置不一致排查问题的时候非常难受。2.2 静默安装方式生产环境首选生产环境我强烈推荐静默安装。理由很实在不需要图形界面、可以批量重复执行、安装参数全部固化在响应文件里谁来了装出来的结果都一样不会因为人为点错导致环境差异。静默安装需要一个响应文件我习惯命名为wls.rsp内容大致如下[ENGINE] Response File Version1.0.0.0.0 [GENERIC] ORACLE_HOME/u01/app/oracle/product/fmw INSTALL_TYPEWebLogic Server DECLINE_SECURITY_UPDATEStrue SECURITY_UPDATES_VIA_MYORACLESUPPORTfalse然后执行java -jar fmw_12.2.1.4.0_wls.jar -silent -responseFile /home/weblogic/wls.rsp -invPtrLoc /etc/oraInst.loc-invPtrLoc指定的是oraInst.loc的位置这个文件记录了Inventory目录一般系统里已经存在如果没有可以手动创建。安装过程会输出进度到oraInstall_*.log日志里观察日志确认是否成功。这里有个细节值得注意DECLINE_SECURITY_UPDATEStrue这个参数如果不设置安装程序可能会因为无法连接Oracle官网而卡住。离线环境下尤其明显。所以静默安装响应文件里这两行是一定要有的。2.3 安装后的目录结构与基础验证安装完成后别急着高兴先验证一下。Weblogic安装完的目录结构里有几个关键位置你要心里有数$ORACLE_HOME/wlserver # WebLogic Server核心代码 $ORACLE_HOME/oracle_common # 公共组件 $ORACLE_HOME/OPatch # 补丁工具 $ORACLE_HOME/domain-template # 域模板验证安装是否成功我一般做三件事。第一检查$ORACLE_HOME/wlserver目录是否存在且权限正确第二确认java -version输出正确和Weblogic版本匹配第三运行补丁工具检查$ORACLE_HOME/OPatch/opatch lsinventory如果这个命令能正常列出补丁信息说明安装本身没有大问题。顺便说一句Weblogic安装目录的属主和权限建议单独建一个weblogic系统用户来管理不要用root跑中间件进程这是安全底线。整个安装阶段我踩过最大的一个坑是JDK路径写错。有些人把JDK解压后顺手删了或者改了目录名后面启动Weblogic时怎么都起不来报错信息还特别误导人。所以安装完成后第一件事就是把用到的JDK路径固定下来写进启动脚本或者环境变量里。3. 域Domain创建与核心配置3.1 域是什么为什么Weblogic不能直接部署应用如果你以前只用Tomcat第一次接触Weblogic一定会困惑为什么装完还不能直接扔war包进去跑这里的关键就是“域”这个概念。域可以理解成一个独立的管理单元。每个域里至少有一个管理服务器AdminServer负责整个域的配置、监控、部署操作域名下还可以有多个受管服务器Managed Server真正跑业务应用的通常是这些受管服务器。从运维视角看域就是一群Weblogic服务器实例的集合体大家共用一套配置统一由管理服务器调度。这个设计比Tomcat这种单实例中间件重得多但它带来的是集中管理、集群扩展、统一部署这些能力。所以你在Weblogic上部署应用第一步不是找“webapps”目录而是先建一个域。域建好了相当于把服务的“骨架”立起来了后面的部署才有着落。3.2 交互式创建域的完整步骤建域的图形化工具是$ORACLE_HOME/wlserver/common/bin/config.sh这个工具会引导创建域核心步骤就是选择“创建新域”还是“基于现有模板扩展”我一般选“创建新域”模板用默认的Basic WebLogic Server Domain即可。然后设置管理员账号和密码这一步要记住后面启动管理服务器、登录控制台都要用到。接着配置域位置和管理服务器参数。默认管理服务器是AdminServer监听端口7001。这个端口如果你本机没被占保持默认即可如果部署在有多套中间件的机器上记得提前规划一个不和别人冲突的端口。创建完之后域目录下会生成一堆配置文件和脚本最重要的几个$DOMAIN_HOME/bin/startWebLogic.sh # 启动管理服务器 $DOMAIN_HOME/bin/stopWebLogic.sh # 停止管理服务器 $DOMAIN_HOME/config/config.xml # 核心配置文件 $DOMAIN_HOME/servers/AdminServer/logs # 管理服务器日志交互式建域适合偶尔手动搞一次。但如果你要批量部署多套环境或者希望把环境信息纳入版本管理那必须用下面这种方式。3.3 使用WLST脚本批量创建域WLST是WebLogic自己的脚本语言基于Jython可以让你用脚本完成建域、部署、配置等几乎所有操作。生产环境里我基本不用图形界面建域全走脚本。下面是一个最小可用的建域脚本createDomain.pyreadTemplate(/u01/app/oracle/product/fmw/wlserver/common/templates/wls/wls.jar) cd(/Security/base_domain/User/weblogic) cmo.setPassword(你的管理员密码) cd(/Servers/AdminServer) cmo.setListenAddress(0.0.0.0) cmo.setListenPort(7001) setOption(ServerStartMode, prod) setOption(OverwriteDomain, true) writeDomain(/u01/app/oracle/admin/base_domain) closeTemplate() exit()执行方式$ORACLE_HOME/oracle_common/common/bin/wlst.sh createDomain.py脚本里readTemplate用的模板路径要根据你的安装目录调整。setListenAddress(0.0.0.0)表示管理服务器监听所有网卡如果你只想内网访问写具体IP更安全。ServerStartMode我习惯设成prod避免开发模式下的类自动部署和热加载特性在生产环境引发意外行为。用脚本建域的好处是显而易见的环境变量、端口、账号密码全部代码化重复执行结果一致代码评审还能看到环境配置变没变。这套思路其实和现在讲究的“基础设施即代码”是一个意思只不过Weblogic的WLST比后来的很多工具老得多。3.4 数据源配置与连接池调优域建好之后接下来最常用的配置就是数据源。企业应用几乎离不开数据库数据源配置得好不好直接影响应用的稳定性和性能。在管理控制台里配置数据源的路径是服务 - 数据源 - 新建。需要填的内容包括数据库类型、驱动、JDBC URL、用户名、密码。核心的几项参数我一般这样配参数推荐值说明初始容量1启动时建立的连接数没必要一开始就建一堆最大容量50要根据应用并发量和数据库性能来定容量增量5连接不够时每次增加的数量连接测试语句select 1 from dual定时验证连接可用性Oracle必须用dual测试频率60秒太频繁会给数据库造成额外压力连接超时10秒等待数据库连接的最长时间连接池有一个非常关键的坑连接泄露。如果应用代码里获取了连接但没正确关闭连接池会被慢慢耗尽最终数据库连接全部被占满整个应用卡死日志里全是“Connection pool is exhausted”这样的错误。这时候最大容量设再大也没用只能从代码层面去排查。我建议数据源配置里打开“保留语句缓存”和“连接泄漏诊断”生产环境能帮你定位到具体是哪段代码出了问题。配置完数据源记得在控制台测试一下连接确认能连上数据库再继续。等到应用部署后发现数据源连不上再排查会浪费大量时间。4. 应用部署的完整流程与自动化4.1 部署应用前需要搞清楚的三件事Weblogic部署应用和Tomcat直接丢war包的体验差距很大。部署前我会先确认三件事。第一应用类型是什么。普通的Spring Boot应用打的是war包适合Weblogic部署如果是老式的EJB应用往往是ear包。war和ear在Weblogic上的部署方式略有区别ear包需要特别注意应用内模块的依赖关系war包相对简单。第二目标服务器选谁。我前面提过生产环境一般把应用部署到受管服务器上而不是管理服务器。原因很简单管理服务器是管配置的它承载控制台和配置管理如果还把业务应用压在它上面一旦应用内存溢出或者线程卡死整个域的配置管理也会跟着挂想修复都难。第三部署计划要不要单独配。像数据源引用、JVM参数、类加载顺序这些有时需要额外定义部署计划。大部分简单应用不需要手动配但如果涉及多环境切换提前了解部署计划是值得的。4.2 通过管理控制台部署应用控制台部署适合临时发布和第一次上线验证路径是部署 - 安装。点击“安装”上传war包文件或者从服务器本地路径选择文件。然后选择部署目标比如AdminServer或者某个受管服务器最后确认完成。部署完成后应用状态会显示为“已激活”Active这时候就能通过应用的访问地址测试了。控制台部署有一个体验不好的地方上传大war包时容易超时尤其是网络不好或者经过负载均衡转发控制台请求时经常传一半就断。我一般超过100MB的包就不走控制台上传了直接放到服务器上然后在控制台里填写服务器路径来安装这样最稳定。控制台里还有一个容易被忽略的选项部署阶段。它有两个值是STAGE和NOSTAGE。STAGE模式下Weblogic会把应用复制到每个目标服务器节点适合小规模和少数节点的环境NOSTAGE模式下它直接用共享目录里的文件适合多节点集群和集中发布。这个选择会影响文件同步策略用错了在集群环境里会遇到“部分节点更新了、部分节点还是旧包”的诡异问题。4.3 用WLST实现命令行一键部署手工控制台部署不适合频繁发布。构建服务器上通常要一键部署、一键回滚这时就得用WLST。下面是一个部署脚本示例deployApp.pyconnect(weblogic, 你的密码, t3://127.0.0.1:7001) deploy(myapp, /u01/app/apps/myapp.war, targetsAdminServer, stageModeSTAGE) startApplication(myapp) exit()执行$ORACLE_HOME/oracle_common/common/bin/wlst.sh deployApp.py这个脚本做两件事把myapp.war部署到AdminServer然后启动应用。实际生产环境中deploy前通常还要先undeploy旧版本或者stopApplication否则同名应用版本升级会提示冲突。我常用的发布脚本骨架大致长这样#!/bin/bash APP_NAMEmyapp WAR_FILEmyapp.war DOMAIN_HOME/u01/app/oracle/admin/base_domain APP_DEPLOY_DIR/u01/app/apps $DOMAIN_HOME/bin/stopManagedWebLogic.sh AppServer http://adminhost:7001 cp $APP_DEPLOY_DIR/$WAR_FILE $APP_DEPLOY_DIR/${WAR_FILE}.bak_$(date %Y%m%d%H%M%S) # 上传新war到 $APP_DEPLOY_DIR # scp new_war userbuildserver:$APP_DEPLOY_DIR/$WAR_FILE $DOMAIN_HOME/bin/startManagedWebLogic.sh AppServer http://adminhost:7001当然这只是一个大致流程真实环境里你还需要健康检查、确认应用启动成功、失败自动回滚这些环节。不过思路就是这个思路操作越标准化故障越少出了问题恢复也越快。4.4 版本更新与回滚策略说到回滚这是生产发布里最容易忽略、但最关键的部分。我见过太多团队部署失败后手忙脚乱找旧包最后不得不翻历史版本重新发的场景。其实Weblogic部署这个环节回滚策略只要提前规划好并不复杂。最朴素也最可靠的方案是发布前把当前运行的war包完整备份新包出问题就用备份包覆盖回去然后重启服务。这个方案虽然笨但是在绝大多数场景下是有效的。如果要做得更精细一点可以借助Weblogic的“版本化部署”功能每次部署保留一个版本号出问题时在控制台里快速切回上一版本。不过这个功能用起来有前提就是你得把旧版本一直保留在部署目录里别为了省磁盘空间随手删。我还建议在发布脚本里加一个启动后的健康检查环节比如用curl访问应用的健康检查接口连续失败几次就触发自动回滚。这样一来上半夜发版的人也不至于守到天亮。5. 安全加固与常见故障排查5.1 安装完成后第一件事改密码和密钥库Weblogic装完第一件事不是部署应用而是加固。很多生产环境被入侵不是应用代码的问题而是中间件本身的默认配置没改。先说最典型的内置演示密钥库。Weblogic默认自带一套身份密钥库和信任密钥库分别是demoidentity.jks和demotrust.jks它们用在SSL双向认证等场景。问题在于这套演示库的密钥库密码也就是常说的demoidentity.jks password是公开的、固定的默认值任何看过官方文档的人都知道。如果你不换掉它等于把服务器的重要密钥摆在明面上别人拿到密码后就可能伪装成合法节点接入你的域内通信。替换方案不复杂。你可以用keytool生成一对新的身份密钥库然后在Weblogic控制台的“环境 - 服务器 - 密钥库设置”里把演示库替换成你自己的库文件同时更新对应密码。如果应用本身没用到SSL也可以直接调整SSL配置把演示证书弃用。另一个更朴素的思路是如果你的业务域没有用到SSL双向认证可以简单关掉SSL监听端口或者只在防火墙上限制来源IP。这个动作一小步安全收益很大。此外还有几个默认项要处理管理后台初始账号weblogic的密码要改成强密码控制台访问尽量限制IP白名单禁用掉不需要的协议。Weblogic历史上出过很多反序列化漏洞和T3协议相关的攻击面关于这个我的原则是不用的功能一律关掉能限定来源的必须限定。有人觉得Weblogic安全漏洞多其实很多漏洞利用的前提是你从来没做过基础加固。5.2 启动与部署阶段常见报错处理即使安装部署步骤全对也难免遇到各种报错。我整理一份高频问题表都是自己踩过或者帮别人排查过的。错误现象可能原因解决办法启动时端口被占用AdminServer起不来7001端口被别的进程占用netstat -lntp查找占用进程修改监听端口或释放端口启动报错ClassNotFoundExceptionJDK版本和Weblogic不匹配确认JDK版本重装正确版本并固定JAVA_HOME内存溢出OutOfMemoryError启动内存设置过小修改setDomainEnv.sh中的Xmx参数控制台登录后页面异常浏览器缓存或老版本问题清理缓存换用Chrome/Firefox兼容模式部署后应用状态为Failed应用本身异常或依赖数据源连不上查看$DOMAIN_HOME/servers/AdminServer/logs和应用日志定位t3连接超时防火墙拦截或hosts解析有问题检查7001端口防火墙确认hosts文件有主机名映射排在最后那个t3连接超时经常出现在多节点环境里。Weblogic节点之间通信走的是T3协议如果socksProxyHost或者/etc/hosts解析不对节点之间就无法互相发现。之前有客户跨网段部署管理服务器和受管服务器在两套网段防火墙忘记放行T3端口结果受管服务器永远进不了“运行中”状态。排查这类问题的思路是从物理网络到系统配置逐层检查不要一上来就怀疑Weblogic本身出了问题。5.3 日志体系与定位问题的思路Weblogic的日志体系刚开始看会比较乱但理清之后排查效率很高。核心日志都在$DOMAIN_HOME/servers/服务器名/logs目录下AdminServer.log管理服务器的运行日志包含启动、部署、配置变更记录。服务器名.log受管服务器的业务运行日志。access.logHTTP访问日志。diagnostic_images诊断镜像目录服务器发生严重故障时会生成线程转储和堆转储文件。我的排查顺序是先看中间件日志确认是不是框架层面的问题再看应用日志定位业务异常最后如果还定位不了再考虑开Debug日志。不要一上来就开Debug那玩意儿输出量巨大很快就能把磁盘写满而且真正有用的信息反而被淹没在里面。其实Weblogic的日志有一个特点大量信息都记录在控制台输出和管理日志里。如果你启动时没重定向输出文件一旦服务被systemd托管或者后台启动日志很容易丢。这个坑我建议提前防住在启动脚本里显式把标准输出和标准错误重定向到日志文件否则出问题的时候真是一脸懵。最后再分享一个小技巧。我干活时会先花半小时把安装目录、域目录、日志目录、备份目录做好软链或者统一命名然后在本地保存一份标准的响应文件、建域脚本和部署脚本模板。换到新环境时直接改IP、端口、应用名一套流程跑下来基本不会出大岔子。Weblogic这套东西说到底是“笨重型”中间件但它稳定、成熟、企业基因深厚你越是用这种标准化流程去对待它它就越不会在关键时刻给你找麻烦。