
1. 为什么 12.2.1.4 这个版本还值得单独搭一次做中间件运维或者 Java 应用交付的人迟早会碰上一套跑在WebLogic Server 12.2.1.4上的老系统。它不像新版本那样下载完点两下就起来了从 JDK 版本到目录权限再到域模板每一步都埋着几个小机关。这篇内容就是我在 Windows 和 Linux 两个平台上把WebLogic Server 12.2.1.4 环境搭建全流程走完之后整理出来的实操记录包含安装、建域、启动验证、Node Manager 配置以及服务化开机自启的完整链路适合刚接手这套中间件的新人也适合需要快速在测试机上复现一套干净环境的老手。先把这个版本的定位说清楚。12.2.1.4 属于 12c Release 2 这条线里的第四个小版本它前面是 12.2.1.3后面是 14.1.1 这一代。很多行业应用银行、电信、大型企业内部系统的开发框架被锁定在 12.2.1.x 的 API 上直接跳到 14.1.1 会出现兼容性问题所以 12.2.1.4 至今仍然是大量存量系统的驻留版本。你要做的往往不是选哪个版本而是怎么把这个指定版本搭稳。1.1 它处在这条产品线的什么位置WebLogic 的版本号里12.2.1 是主版本最后的.4是补丁集编号。这意味着 12.2.1.4 的安装介质本身就是一个完整可用的分发而不是先装 12.2.1 再打补丁。安装包通常是一个名为fmw_12.2.1.4.0_wls.jar的可执行 JAR通用版体积在 3GB 上下安装展开之后占用 4~5GB 磁盘空间。它和 12.1.x 那代最大的区别在于目录结构变了不再有独立的 MW_HOME 概念ORACLE_HOME本身就是中间件根目录域Domain被强制放在ORACLE_HOME之外。这个设计当年被很多人吐槽但它带来的好处是补丁升级时域配置不会被覆盖运维上反而更干净。注意千万不要把域建在ORACLE_HOME内部。虽然安装向导允许你这么做但后续打 PSU 补丁或者做updateDomain时域目录和产品目录混在一起会让回滚变得极其麻烦。还有一个容易被忽略的点12.2.1.4 的安装包分通用安装器和精简安装器两种。精简版体积小、装得快但它裁掉了一部分组件比如 Coherence 相关的部分内容如果你的应用用到了分布式缓存或者集群特性装上精简版再回头补组件是件很折腾的事。我的建议是测试环境用哪个都行生产环境一律用通用安装器一次到位。1.2 JDK 版本是第一个卡点这是整个搭建过程中最容易翻车的地方。12.2.1.4 官方认证的主流 JDK 是Oracle JDK 8建议使用 1.8.0_2xx 以后的版本。你要是图省事随手抓一个 JDK 11 或者 JDK 17 去跑安装器大概率会在解压阶段直接报错退出或者在启动域时抛出类加载异常。我见过的典型翻车现场是这样的$ $JAVA_HOME/bin/java -jar fmw_12.2.1.4.0_wls.jar Exception in thread main java.lang.UnsupportedClassVersionError或者更隐蔽一点安装能过但启动域的时候报BEA-000386 Server subsystem failed. Reason: java.lang.NoClassDefFoundError查半天代码最后发现是 JDK 版本不对。所以动手之前先确认$ java -version java version 1.8.0_231 Java(TM) SE Runtime Environment (build 1.8.0_231-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)看到1.8.0_xxx就对了。顺带提一句12.2.1.4 在后期通过补丁集开始逐步认证 JDK 11但这个认证是跟具体 PSU 版本绑定的如果没有明确的书面要求别自己给自己找麻烦老老实实用 JDK 8。1.3 搭之前先明确你要搭成什么样在敲第一条命令之前我习惯先在纸上写清楚三件事装在哪个用户下、装在哪个路径下、要建几个域。生产环境的标准答案是非 root 用户通常叫oracle、/u01/app/oracle作为基础路径、一个 AdminServer 加多个受管服务器的单域架构。测试环境可以宽松一些直接用当前登录用户装路径放家目录下也没问题。但有一点是通用的——不要在同一个 ORACLE_HOME 下反复装。Oracle 的安装器会在系统里维护一份清单文件inventory重复安装同一个版本到同一个路径轻则报错重则把 inventory 弄脏导致后面打补丁时opatch lsinventory输出错乱。Windows 上还有个额外的心理准备整个安装过程走图形向导的话大概需要 20 到 40 分钟取决于磁盘 IO。中间会有一步安全检查更新Security Updates会自动连网查询如果网络不通会卡在那儿很久。所以静默安装其实在 Windows 上也是更省事的选择后面会详细讲。2. 装之前把目录、用户和主机名想清楚安装本身不难难的是前置条件。我统计过自己踩过的坑至少有六成不是出在 WebLogic 本身而是出在操作系统层面权限不对、路径带空格、主机名解析不了、防火墙没放行。这一节把这些前置动作一次说完照着做完再动手装能省下大量来回折腾的时间。2.1 Linux 侧账号、组、目录权限Linux 上标准的做法是创建一个专用账号配上对应的组groupadd -g 1000 oinstall useradd -u 1000 -g oinstall -m -s /bin/bash oracle passwd oracle然后用 root 建目录并授权。目录规划可以参考下面这套用惯了 Oracle 体系的人应该很熟用途路径说明产品安装目录/u01/app/oracle/product/wls12214对应 ORACLE_HOME清单目录/u01/app/oraInventory安装器记录组件信息域目录/u01/app/oracle/domains/base_domain与产品目录分开应用部署目录/u01/app/oracle/applications后续放 war/ear日志/备份/u01/app/oracle/backup域备份与日志归档mkdir -p /u01/app/oracle/product/wls12214 mkdir -p /u01/app/oracle/domains mkdir -p /u01/app/oraInventory chown -R oracle:oinstall /u01/app chmod -R 775 /u01/app这里有个实操心得Oracle 的图形安装器不允许以 root 身份运行。你如果习惯性地su -切到 root 再执行会直接收到一个必须先切换为非 root 用户的提示。静默安装虽然没有这个校验那么严格但装出来的文件属主会变成 root后续启动域时又会碰到写日志权限不足的问题。所以从头到尾都用oracle用户操作是唯一省心的做法。SELinux 和防火墙也顺手处理一下。测试环境可以直接把 SELinux 设成permissivesetenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config防火墙要放行的端口至少要包括 7001AdminServer 非 SSL 端口、7002SSL 端口和 5556Node Manager 通信端口firewall-cmd --permanent --add-port7001/tcp firewall-cmd --permanent --add-port7002/tcp firewall-cmd --permanent --add-port5556/tcp firewall-cmd --reload2.2 Windows 侧路径里不要有空格和中文Windows 上最大的坑是路径中的空格。默认安装位置是C:\Program Files\...系列而 WebLogic 的启动脚本.cmd文件在处理带空格的JAVA_HOME时经常出现引号解析问题表现为启动时报系统找不到指定的路径或者类路径莫名其妙被截断。我的做法是一律换到盘符根目录下的短路径D:\Oracle\jdk1.8.0_231 D:\Oracle\Middleware\wls12214 D:\Oracle\domains\base_domain同理中文路径、包含或括号的路径都要避开。Windows 还有 260 字符的路径长度限制域目录里本身层级就很深servers\AdminServer\logs\...再叠加长域名和长应用名很容易撞线。另外记得用管理员权限打开 CMD。安装器要写注册表、要往系统目录放清单文件权限不够会在最后一步失败而且失败信息通常写得很含糊只说安装未完成让人一头雾水。Windows 上的 JDK 安装同样要设JAVA_HOMEsetx JAVA_HOME D:\Oracle\jdk1.8.0_231 /M setx PATH %JAVA_HOME%\bin;%PATH% /Msetx的/M表示写系统变量而不是当前用户变量。设完要重新开一个 CMD 窗口才生效这一点新手特别容易漏在同一个窗口里反复执行echo %JAVA_HOME%看它没变然后开始怀疑人生。2.3 磁盘与系统层的前置检查Linux 上有个不起眼但很致命的问题主机名没有做本地解析。WebLogic 启动时会尝试把主机名解析成 IP如果/etc/hosts里没有对应记录且 DNS 查询又超时启动过程会卡住几十秒甚至几分钟。现象是日志停在某一行不动了让人以为进程死了。# 查看主机名 hostname # 写入 hosts echo 127.0.0.1 $(hostname) /etc/hosts同时确认一下ulimit -n文件描述符上限不要太小建议至少 65536。WebLogic 在高并发下会打开大量文件句柄默认的 1024 在生产环境根本不够用ulimit -n 65536 echo oracle soft nofile 65536 /etc/security/limits.conf echo oracle hard nofile 65536 /etc/security/limits.conf磁盘空间的话Linux 上/tmp至少留 2GB安装器会在里面解压临时文件Windows 上系统盘至少留 5GB 空闲。这些数字看起来保守但真的遇到过/tmp只有 1GB 导致解压失败、安装器报一个完全看不懂的 IO 异常的情况。3. Windows 下的安装图形向导与静默安装怎么选Windows 平台上的安装有两条路。图形向导适合第一次接触、想看清楚每一步在做什么的人静默安装适合批量部署和反复重建。我的建议是第一次用图形向导走一遍熟悉流程之后所有环境都用静默安装因为它的输出可复现、可写进部署脚本不会因为某一步点错而前功尽弃。3.1 图形向导的实际操作路径把 JDK 和安装包都准备好之后打开管理员 CMDcd /d D:\install %JAVA_HOME%\bin\java -jar fmw_12.2.1.4.0_wls.jar安装器启动后会先解压自身这一步耗时和磁盘性能强相关。之后是标准的 Oracle 安装向导流程几个关键节点的选择如下第一屏是跳过自动更新Skip Auto Updates建议勾上。执行自动更新的前提是配置代理或者目标环境能访问外部网络在内网环境里这一步必然卡住跳过它最省事。第二屏是选择安装位置Oracle Home填D:\Oracle\Middleware\wls12214清单目录保持默认的C:\Program Files\Oracle\Inventory即可。注意这里填的路径会被写进脚本所以一定要避免空格。第三屏是安装类型选WebLogic Server完整版不要选Coherence或者精简选项。第四屏是安全检查更新那个需要联网的复选框取消勾选然后点下一步。最后是安装进度条走完之后会显示安装摘要。看到摘要页就算成功了但我建议先别关窗口把摘要里的路径信息截个图里面包含了确切的 ORACLE_HOME 和 inventory 位置后面排查问题会用到。3.2 静默安装的响应文件写法静默安装的精髓在于响应文件。在 Windows 上准备一个wls.rsp[ENGINE] Response File Version1.0.0.0.0 [GENERIC] ORACLE_HOMED:\Oracle\Middleware\wls12214 INSTALL_TYPEWebLogic Server DECLINE_SECURITY_UPDATEStrue SECURITY_UPDATES_VIA_MYORACLESUPPORTfalse这里面有两个字段必须特别注意。DECLINE_SECURITY_UPDATEStrue是必须的如果你把它写成false安装器会尝试去连网做安全检查更新在内网环境下会报INSTALL_FAILED并中断整个安装。很多网上抄来的老响应文件样例里这一行是false直接抄必然失败。另一个是INSTALL_TYPE值必须是WebLogic Server写错成小写或者写成别的名称会导致校验失败。执行安装%JAVA_HOME%\bin\java -jar fmw_12.2.1.4.0_wls.jar ^ -silent ^ -responseFile D:\install\wls.rsp ^ -logLevel info ^ -log D:\install\wls_install.log静默安装期间命令行只输出几行进度细节都在日志里。装完之后我做的第一件事不是启动而是检查日志末尾findstr /C:Installation completed successfully D:\install\wls_install.log看到这行才算真成功。如果日志里出现SEVERE或者Error先解决它再往下走。3.3 安装完别急着点下一步先做版本自检安装完成后ORACLE_HOME下会有wlserver、oracle_common、oui等目录。最直接的自检方式是看版本信息%JAVA_HOME%\bin\java -cp D:\Oracle\Middleware\wls12214\wlserver\server\lib\weblogic.jar ^ weblogic.version -verbose正常输出会包含类似WebLogic Server 12.2.1.4.0的字样以及具体的补丁集编号。这一步的价值在于它能同时验证三件事——产品文件完整、JDK 版本可用、类路径拼接正确。如果 Java 版本不对这条命令会立刻抛出异常比启动整个域之后再排查要快得多。顺带把环境变量也理清楚。Windows 上至少有这几个概念要区分开ORACLE_HOME指向产品目录...\wls12214WL_HOME指向ORACLE_HOME\wlserverDOMAIN_HOME指向域目录。12.2.1.x 里MW_HOME这个概念已经被废弃了老教程里让你设MW_HOME的直接忽略。4. Linux 下的安装静默模式是唯一靠谱的生产做法Linux 上我从来不用图形向导原因很现实服务器通常没有图形环境为了装一次中间件去配 X11 转发或者装 VNC 不值得。静默安装只要两个文本文件加一条命令而且这两个文件可以纳入版本管理每次重建环境直接复用。4.1 oraInst.loc 和 wls.rsp 两个文件的细节先准备清单文件oraInst.locinventory_loc/u01/app/oraInventory inst_groupoinstall这个文件告诉安装器去哪里记录组件清单以及用哪个组作为清单文件的属组。inventory_loc指向的目录必须提前建好并且对oracle用户可写否则安装器会尝试在ORACLE_HOME里自己创建一个最后权限一团乱。再准备响应文件wls.rsp[ENGINE] Response File Version1.0.0.0.0 [GENERIC] ORACLE_HOME/u01/app/oracle/product/wls12214 INSTALL_TYPEWebLogic Server DECLINE_SECURITY_UPDATEStrue SECURITY_UPDATES_VIA_MYORACLESUPPORTfalse和 Windows 版本唯一的区别就是路径。这里我还想强调一个细节ORACLE_HOME结尾不要带斜杠。带斜杠有时候能过有时候会在后续脚本里拼出双斜杠的路径虽然大多时候无害但在某些路径解析场景下会引发奇怪的失败。改权限让文件只对 oracle 用户可读chown oracle:oinstall /home/oracle/oraInst.loc /home/oracle/wls.rsp chmod 660 /home/oracle/oraInst.loc /home/oracle/wls.rsp4.2 执行安装与日志判读切换到 oracle 用户设置好 JAVA_HOME然后执行su - oracle export JAVA_HOME/usr/java/jdk1.8.0_231 export PATH$JAVA_HOME/bin:$PATH cd /home/oracle $JAVA_HOME/bin/java -jar fmw_12.2.1.4.0_wls.jar \ -silent \ -responseFile /home/oracle/wls.rsp \ -invPtrLoc /home/oracle/oraInst.loc \ -logLevel info \ -log /home/oracle/wls_install.log安装过程在终端里显示得很简略大部分信息在日志文件里。-logLevel info是必须的如果省略或者设成severe日志里只有错误成功路径上的信息全丢排查问题时等于瞎猜。安装完成后检查日志grep -i completed successfully /home/oracle/wls_install.log grep -i error\|severe /home/oracle/wls_install.log第一个命令应该有输出第二个命令最好没有输出或者只有一些无害的警告。这里有个经验日志里出现WARNING通常可以忽略比如某个可选组件未安装之类出现SEVERE就要认真看尤其是涉及inventory和permission的。安装耗时看机器性能SSD 加 8 核的机器大约 5 到 8 分钟机械盘可能要 20 分钟以上。这段时间别闲着可以去检查一下oracle用户的.bash_profile需不需要补充环境变量。4.3 环境变量与权限收尾安装完成后推荐把这套环境变量写进~/.bash_profileexport JAVA_HOME/usr/java/jdk1.8.0_231 export ORACLE_HOME/u01/app/oracle/product/wls12214 export WL_HOME$ORACLE_HOME/wlserver export DOMAIN_HOME/u01/app/oracle/domains/base_domain export PATH$JAVA_HOME/bin:$ORACLE_HOME/oracle_common/common/bin:$WL_HOME/server/bin:$DOMAIN_HOME/bin:$PATH export CLASSPATH$WL_HOME/server/lib/weblogic.jar:$CLASSPATH这里PATH的顺序是有讲究的。把$ORACLE_HOME/oracle_common/common/bin放在前面是为了让wlst.sh、config.sh这类工具直接可用而不用敲全路径。$DOMAIN_HOME/bin放进去之后startWebLogic.sh、stopWebLogic.sh也能直接调用运维的时候省不少事。顺手检查一下安装目录的属主和权限ls -ld /u01/app/oracle/product/wls12214 # 期望看到 oracle oinstall 的属主权限 750 或 775如果属主不是 oracle说明安装过程中用错了用户这种环境后续启动域时必然在写日志的环节失败。与其事后加权限不如重装一遍更干净。5. 建域WLST 离线脚本比图形向导更适合反复重建域Domain是 WebLogic 的运行单元包含管理服务器、受管服务器、数据源、JMS 队列等所有配置。图形化的配置向导config.sh/config.cmd在 Windows 上能用但在 Linux 上没有图形环境就跑不起来。更重要的是图形向导生成的配置依赖你的点击顺序第二次重建很难和第一次完全一致。所以从长期看WLST 离线脚本建域是更值得投入的做法。5.1 模板选择与开发/生产模式的取舍建域之前先想清楚两件事用哪个模板以及用开发模式还是生产模式。模板方面最基础的是wls.jar对应Basic WebLogic Server Domain。如果你的应用依赖 JAX-RS、JMS 等特性可以选择带对应服务的模板但大多数场景下基础模板就够缺什么后面再通过控制台加。模板路径在$ORACLE_HOME/wlserver/common/templates/wls/下可以自己列一下有哪些可选ls -lh $ORACLE_HOME/wlserver/common/templates/wls/开发模式和生产模式的差别说人话就是开发模式下AdminServer 可以自己跑应用部署是自动的改完配置不用重启生产模式下AdminServer 只做管理应用必须部署到受管服务器上启动时强制要账号密码配置修改必须显式激活。测试环境为了省事很多人用开发模式。但这里有个坑开发模式下的自动部署目录autodeploy会把里面所有 artifact 自动部署上去如果你不小心把一个不完整的 EAR 丢进去服务器启动时就会报部署失败甚至影响启动。生产环境没得选必须生产模式。对比项开发模式生产模式启动是否要密码可通过 boot.properties 免交互同样支持 boot.properties自动部署支持不支持AdminServer 跑应用可以不推荐配置修改立即生效需要激活适用场景开发、测试测试、生产5.2 一份可以直接抄的 WLST 建域脚本WLST 离线建域的脚本我用得最多下面这份是常用的骨架改改路径就能用# create_domain.py readTemplate(/u01/app/oracle/product/wls12214/wlserver/common/templates/wls/wls.jar) cd(/) cmo.setName(base_domain) cmo.setProductionModeEnabled(false) cd(/Servers/AdminServer) set(ListenAddress, ) set(ListenPort, 7001) cd(/Security/base_domain/User/weblogic) cmo.setPassword(Welcome1_2024) setOption(OverwriteDomain, true) setOption(JavaHome, /usr/java/jdk1.8.0_231) writeDomain(/u01/app/oracle/domains/base_domain) closeTemplate() exit()执行$ORACLE_HOME/oracle_common/common/bin/wlst.sh /home/oracle/create_domain.py几个细节值得展开。ListenAddress设成空字符串表示监听所有网卡地址如果你只想让它在某个内网 IP 上监听就填具体 IP。OverwriteDomain设成true是让脚本可以覆盖已有域重建环境时非常方便但生产环境慎用手抖一下配置就没了。JavaHome显式指定 JDK 路径避免域脚本去猜一个不确定的 JDK。密码设置这里要注意cmo.setPassword()写的是明文脚本文件本身要控制权限。更好的做法是把密码放到一个单独的、权限为 600 的文件里脚本运行时读进来。如果你的环境有密码复杂度要求Welcome1_2024这种写法比纯字母数字更容易过校验。脚本跑完之后检查目录ls -l $DOMAIN_HOME # 应该看到 bin、config、servers、init-info 等目录5.3 boot.properties 与第一次启动的验证动作第一次启动域之前建议先把boot.properties建好否则启动脚本会停在交互式提示那里等输入用户名密码mkdir -p $DOMAIN_HOME/servers/AdminServer/security cat $DOMAIN_HOME/servers/AdminServer/security/boot.properties EOF usernameweblogic passwordWelcome1_2024 EOF chmod 600 $DOMAIN_HOME/servers/AdminServer/security/boot.properties这个文件第一次启动后会被自动加密重写变成{AES}...开头的密文。这是正常现象不用担心。加密是跟域绑定的如果把域整个复制到另一台机器密文会解不开需要删掉让它重新生成。启动cd $DOMAIN_HOME/bin nohup ./startWebLogic.sh /dev/null 21 用nohup加后台运行是为了断开 SSH 之后进程不被杀掉。想看输出就直接不加nohup前台跑观察日志滚动情况。启动成功的标志是在另一台机器上能打开控制台http://服务器IP:7001/console命令行验证ss -lntp | grep 7001 tail -f $DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log日志里看到Server state changed to RUNNING就算起来了。我第一次搭的时候盯着日志看了十几分钟其实启动只要一分半慢是因为主机名解析的问题那部分后面会讲。6. 起不来的时候按这条链路查域建完启动失败几乎是必经环节。我总结出一个固定的排查顺序先看日志的最后一个异常再看端口占用然后检查 JDK 和内存参数最后才怀疑配置本身。这个顺序的逻辑是从最具体的信息开始逐层往外扩避免一上来就重装重来。6.1 先看日志再看端口最后看 JDK日志位置要记牢排查效率完全取决于你能不能第一时间找到正确的那一个日志类型位置内容域日志$DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log服务器事件、部署、报错标准输出$DOMAIN_HOME/servers/AdminServer/logs/AdminServer.outJVM 启动过程、脚本输出域配置日志$DOMAIN_HOME/servers/AdminServer/logs/*.log配置变更历史Node Manager 日志$DOMAIN_HOME/nodemanager/nodemanager.log节点管理器通信如果服务器根本没启动到写日志的阶段那要看的是控制台输出或者.out文件。我碰到过一次启动脚本只打印了两行就退出了最后在.out里看到是JAVA_HOME指向了一个不存在的路径——setDomainEnv.sh在找不到 JDK 时不会给你一个特别清楚的提示只会抛一个找不到主类的异常。端口检查ss -lntp | grep -E 7001|7002|5556 # Windows netstat -ano | findstr 7001端口被占用的报错通常很直白日志里会有Address already in use或者BEA-000386配合java.net.BindException。这种情况找到占用进程杀掉或者改域的端口配置就行。6.2 几个高频报错与对应处理下面这张表是我几年下来整理的高频问题清单基本上覆盖了八成以上的启动失败报错关键字根因处理方式Unrecognized VM option MaxPermSizeJDK 8 移除了永久代参数但域脚本里还带着在setUserOverrides.sh里重设USER_MEM_ARGSAddress already in use端口被其他进程占用查占用进程杀进程或改端口NoClassDefFoundError/UnsupportedClassVersionErrorJDK 版本不匹配换成 JDK 8确认JAVA_HOME生效BEA-090783或管理服务器连不上主机名解析失败把主机名写入/etc/hostsPermission denied: .../logs/AdminServer.log域目录属主错误用chown -R修正属主启动卡在Starting WebLogic Server...不动随机数熵池不足加-Djava.security.egdfile:/dev/./urandomMaxPermSize那个问题值得多说两句。它在 12.2.1.x 配 JDK 8 的环境里出现的频率特别高原因是域脚本模板里保留了为老 JDK 准备的参数。日志里你会看到一个很吓人的堆栈但解决方式非常简单在域目录的bin/下新建setUserOverrides.shWindows 上是setUserOverrides.cmd加上USER_MEM_ARGS-Xms1024m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m export USER_MEM_ARGS这个文件的优先级高于setDomainEnv.sh而且打补丁时不会被覆盖是官方推荐的用户自定义入口。不要直接改setDomainEnv.sh那是个坑下次打补丁你的修改就没了而且会引发一堆难以解释的启动差异。6.3 Linux 上启动慢得离谱的情况如果启动过程能成功但耗时七八分钟甚至更久八成是这两个原因之一。第一个是随机数熵池。JVM 在初始化安全相关的组件时要读/dev/random而这个设备在熵不足时会阻塞。Linux 服务器尤其是刚开机不久的虚拟机熵池经常不够。解决办法就是在启动参数里换成非阻塞设备JAVA_OPTIONS${JAVA_OPTIONS} -Djava.security.egdfile:/dev/./urandom export JAVA_OPTIONS注意路径里的/dev/./urandom这个写法中间的./不是笔误是历史遗留的一个技巧某些 JDK 版本会把/dev/urandom当成/dev/random处理加上./可以绕开这个判断。第二个是主机名解析。前面提过服务器启动时会做反向 DNS 查询。如果/etc/hosts里没有记录每次查询都要等 DNS 超时。用time hostname或者getent hosts $(hostname)确认一下解析速度如果能感觉到明显延迟就把记录补上。这个问题的隐蔽之处在于日志里不会有任何报错只是慢所以特别容易被人归结为机器性能不行。还有个小概率情况是 JDK 装在了网络存储NFS上。WebLogic 启动时要加载几千个类文件NFS 的随机读延迟会让这个过程变得极其漫长。生产环境的 JDK 和ORACLE_HOME一律放本地盘这是硬性要求。7. 域跑通之后的收尾内存、Node Manager、服务化与补丁域能起来只是第一步。要让它真正能用于日常开发和测试还得把内存参数、节点管理器、开机自启这几件事做完。这一节的内容偏运维但都是迟早要面对的。7.1 用 setUserOverrides 管内存和编码别改 setDomainEnv前面提到了setUserOverrides.sh这里把完整配置说一下。除了内存参数通常还要加上字符编码和时区相关的设置尤其是应用里有中文数据的时候# $DOMAIN_HOME/bin/setUserOverrides.sh USER_MEM_ARGS-Xms1024m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m export USER_MEM_ARGS JAVA_OPTIONS${JAVA_OPTIONS} -Dfile.encodingUTF-8 JAVA_OPTIONS${JAVA_OPTIONS} -Duser.languagezh -Duser.countryCN JAVA_OPTIONS${JAVA_OPTIONS} -Djava.security.egdfile:/dev/./urandom JAVA_OPTIONS${JAVA_OPTIONS} -Dweblogic.StdoutDebugEnabledfalse export JAVA_OPTIONS内存参数怎么定我的经验值是测试环境 AdminServer 的堆内存 1 到 2GB 够用生产环境如果 AdminServer 只做管理1GB 就够了受管服务器再按应用规模单独配置。堆开太大反而不好尤其是做 dump 分析和 GC 调优的时候一个小配置错误就要等几分钟才能看到结果。-Dfile.encodingUTF-8这个参数在中文环境里几乎是必需的。不设的话JVM 会跟随操作系统的默认编码中文 Linux 环境下经常是UTF-8没问题但某些精简版系统默认是ANSI_X3.4-1968日志里的中文就变成问号严重的时候会导致应用读写文件出现乱码。Monospace 表格之外再提醒一点改完这些参数要重启域才生效热生效只有部分参数支持。改之前备份一下文件setUserOverrides.sh写错一个引号就会导致启动脚本直接失败。7.2 Node Manager 与受管服务器的联通Node Manager 是 WebLogic 用来管理服务器进程生命周期的组件负责启动、停止、重启受管服务器。如果你只用 AdminServer 做测试可以不配但只要涉及受管服务器或者集群Node Manager 就是必需的。配置入口在域目录下cat $DOMAIN_HOME/nodemanager/nodemanager.properties需要关注的几个属性NodeManagerHome/u01/app/oracle/domains/base_domain/nodemanager DomainsFile/u01/app/oracle/domains/base_domain/nodemanager/nodemanager.domains ListenAddress0.0.0.0 ListenPort5556 LogFile/u01/app/oracle/domains/base_domain/nodemanager/nodemanager.log AuthenticationEnabledtrue启动 Node Manager$WL_HOME/server/bin/startNodeManager.sh然后到控制台里环境 - 计算机 节点下新建一台机器把 Node Manager 的监听地址和端口填进去再给这台机器分配受管服务器。配置好了之后点启动受管服务器的日志会出现在$DOMAIN_HOME/servers/serverName/logs/下。这里有个已知的坑Node Manager 默认使用明文还是加密通信取决于SecureListener这个属性。12.2.1.x 里控制台和 Node Manager 的通信协议如果不匹配会让你看到无法连接到节点管理器的错误而且错误信息里不会说明是协议问题。稳妥的做法是在控制台里建机器的时候把协议显式选成和 Node Manager 配置一致的那个别依赖默认值。7.3 Windows 服务注册与 Linux 自启生产环境的服务器要跟操作系统一起起来不能靠人工登录敲命令。Windows 上有一个现成的脚本set WL_HOMED:\Oracle\Middleware\wls12214\wlserver set DOMAIN_HOMED:\Oracle\domains\base_domain set NODEMGR_HOMED:\Oracle\domains\base_domain\nodemanager set JAVA_HOMED:\Oracle\jdk1.8.0_231 %WL_HOME%\server\bin\installSvc.cmd执行完之后Windows 服务列表里会多一个以域命名的服务。卸载用对应的uninstallSvc.cmd。需要注意的是注册服务前必须先把域启动过至少一次因为脚本会读取域里的配置生成服务参数从没启动过的域注册出来的服务往往是坏的。Linux 上方案更多我习惯用 systemd比老的 init 脚本好维护[Unit] DescriptionWebLogic AdminServer base_domain Afternetwork.target [Service] Typeforking Useroracle Groupoinstall EnvironmentJAVA_HOME/usr/java/jdk1.8.0_231 EnvironmentDOMAIN_HOME/u01/app/oracle/domains/base_domain ExecStart/u01/app/oracle/domains/base_domain/bin/startWebLogic.sh ExecStop/u01/app/oracle/domains/base_domain/bin/stopWebLogic.sh Restarton-failure RestartSec30 [Install] WantedBymulti-user.target这里有个细节要留意startWebLogic.sh本身不返回它会一直占用前台所以配Typeforking实际上不完全准确更稳的写法是Typesimple并把 standardOutput 重定向到文件。我两种都试过在自己的测试环境里Typesimple配合Restarton-failure表现更符合预期。stop 脚本在服务未启动时返回非零退出码可能会让 systemd 判定服务异常可以在ExecStop前面加个-前缀忽略退出码。7.4 补丁与 updateDomain 的关系最后说补丁因为这是维护期绕不开的事。12.2.1.4 的补丁分两类一类是产品目录的补丁通过 OPatch 打一类是域配置的同步脚本。打产品补丁的标准流程是先更新 OPatch 工具本身再应用补丁cd $ORACLE_HOME/OPatch ./opatch version ./opatch lsinventory ./opatch apply /path/to/patch_directorylsinventory的输出会列出当前 ORACLE_HOME 里已经打过的所有补丁打之前先看一眼避免重复打或者漏打前置补丁。打完之后关键的一步是同步域配置$ORACLE_HOME/oracle_common/bin/updateDomain.sh -oracle_home $ORACLE_HOME -domain_home $DOMAIN_HOME -domain_type WLS这个脚本会读取域里的配置模板版本把产品新版本带来的配置变更应用到域里。跳过这一步的话域还是用旧版本的配置模板启动某些补丁带来的新参数不会生效可能引发诡异的问题。执行前一定要备份整个域目录用tar czf打一个包几十秒的事但在这类操作里它就是救命稻草。我在实际操作中的体会是每次打补丁都当它是生产变更来对待哪怕是在测试环境。先在测试环境完整走一遍备份 - 打补丁 - updateDomain - 重启验证确认应用功能正常再去动生产。WebLogic 的补丁大多数时候很平滑但偶尔会出现某个 JDK 参数不再被识别、或者某个数据源驱动的行为变化这类问题只在重启之后才暴露出来。如果你只是想快速搭一套能跑起来的环境第 2 到第 5 节的内容照做就够如果你要给团队交付一套长期维护的环境第 6 和第 7 节的排查思路和收尾动作才是真正省时间的地方。