
1. 动手之前WebLogic Server 12.2.1.4 的选型与整体规划WebLogic Server 12.2.1.4 的环境搭建说白了就是把一套 Java 中间件从零装到能跑起来、能进控制台、能部署应用为止。这件事在 Windows 和 Linux 上都能做但两边的操作路径、容易踩的坑、事后维护的成本完全不是一回事。这篇内容面向的是第一次接触这套中间件、或者从别人手里接过一套老系统需要自己重建环境的人也会把几年下来反复验证过的参数、脚本和排查思路一并放出来让你少走几遍弯路。先把结论摆前面12.2.1.4 这个版本本身并不难装难的是装完之后“能稳定跑”。安装过程大约占整个工作量的三成剩下七成在 JDK 匹配、目录规划、内存参数、主机名解析这些看起来不起眼的地方。很多人卡在启动脚本上转圈最后发现问题出在/etc/hosts里少写了一行这种事我见过不止一次。下面的内容会按“先判断、再准备、后动手、最后排查”的顺序展开Windows 和 Linux 两条线各自独立成章你可以按自己手上的机器直接跳着看。1.1 为什么这个版本到现在还有一堆人在用12.2.1.4 属于 12c Release 2 系列里的一个补丁集版本落在这个版本上的系统大多是几年前立项、现在还在稳定运行的老项目。这类项目的特点很鲜明应用本身写得比较重依赖 EJB、JMS、JTA 这些传统 Java EE 组件迁移到更新的容器成本高、风险大于是运维团队宁愿把中间件版本钉死也不愿意动。你接到“搭一套 12.2.1.4”的需求时先别急着怀疑为什么不用更新的版本先问清楚是配合已有系统的版本一致性还是全新项目。判断依据其实很简单如果周边已经有同版本的节点在跑或者有厂商提供的补丁包、认证矩阵那就跟着走别自作主张升级如果是全新环境、团队也没有历史包袱那就要评估是不是有必要花时间在这套相对传统的中间件上。这个判断决定了你后面所有工作的方向包括 JDK 选哪个、安装包从哪来、要不要配集群等。1.2 Windows 和 Linux 两套环境的定位差异同样是搭建Windows 和 Linux 承担的角色通常不一样。Windows 上更多是开发自测、本地调试、demo 演示好处是图形界面齐全安装向导点几下就完事管理控制台在浏览器里也能直接打开代价是路径里有空格、服务注册麻烦、脚本能力弱跑长时间任务容易受系统休眠、自动更新这些因素干扰。Linux 上则是测试和生产的主场安装过程要过权限、目录、系统参数这几关但一旦装好静默安装加脚本建域的组合可以做到完全可复现换一台机器把脚本抄过去就能重来一遍。所以我的习惯是Windows 用来快速验证版本和跑通流程Linux 用来做真正长期运行的那一套两边的目录结构尽量保持一致方便后面把配置直接搬过去。1.3 一次完整搭建包含的环节把整件事拆开大概是这么几步确认 JDK 与系统环境、准备安装包、执行安装程序、创建域Domain、调整启动参数、启动并验证、最后做一轮基础加固。这里面“创建域”是最容易被低估的一步因为向导里那几个选项——启动模式选开发还是生产、管理端口用多少、管理员账号密码策略——选错了后面改起来很别扭尤其是启动模式生产模式下会默认收紧不少策略开发时觉得“怎么什么都访问不了”往往就是这里设成了生产模式。我在实际项目里通常的做法是先按生产模式的规范去规划路径和参数但在搭建阶段用开发模式把流程跑通确认应用能部署、能访问再切换成生产模式做一次回归验证。这样既不会因为策略限制卡住调试也不会在最后上线时才发现生产模式下的行为差异。2. 通用前置准备JDK、目录与安装包不管最终落在哪个系统上JDK、目录规划、安装包这三件事是共用的。这一节先把它们处理干净后面两条线就只剩下操作方式的区别了。很多“装到一半报错”的情况追根溯源都在这一节。2.1 JDK 版本选错后面全是坑12.2.1.4 对 JDK 的要求比较明确主流搭配是 JDK 8 的较新更新版本。版本太低比如早期的 8u 小版本会碰到安装器直接拒绝运行或者启动时报类加载错误版本太高比如直接上 JDK 11 及以上则可能遇到部分内部 API 不兼容。稳妥起见先查官方认证矩阵确认支持的 JDK 小版本区间再下载对应的安装包这一步花十分钟能省掉后面好几个小时的排查。装 JDK 的时候有两个细节要注意。第一Windows 上尽量装在纯英文、无空格的路径下比如C:\Java\jdk8不要放在Program Files里因为中间件的一些脚本对带空格的路径处理得并不好。第二Linux 上如果系统自带 OpenJDK建议单独装一份 JDK 8 到独立目录不要依赖系统包管理器那份避免中间件启动时拿到的 JAVA_HOME 和你预期的不一致。装完用java -version和javac -version各确认一次两个命令的输出要指向同一份。提示JDK 的具体版本号请以官方认证矩阵为准不要凭印象选。我见过因为差了几个小版本导致安装器直接退出的情况。2.2 目录规划和磁盘空间怎么留目录规划这件事Windows 上很多人随手就装在默认路径Linux 上则习惯照着规范来。我的建议是两边都统一成一套结构方便记忆和迁移。Linux 上常用的方案是分成三块中间件安装目录、域目录、安装清单目录分别放在不同的父目录下权限归属同一个专用用户。这样做的好处是后面做备份、做迁移、做版本共存的时候目录边界非常清楚。磁盘空间方面安装程序本身加上解压出来的文件占用不小再算上域目录里后续产生的日志、临时文件、部署包建议至少预留出宽裕的空间。经验值是安装目录给几十 GB 的量级域目录按你实际部署应用的规模另算。别把这两个目录挤在同一个分区里尤其 Linux 上如果日志目录被写满整个实例会直接卡死。用途建议路径示例说明安装目录/u01/app/oracle/product/fmw12214中间件主体权限归专用用户域目录/u01/app/oracle/domains/base_domain每个域独立一份便于备份安装清单/u01/app/oraInventory记录装了哪些组件重装时要用安装包与日志/u01/soft临时存放装完可清理Windows 上对应把盘符换掉即可比如D:\oracle\product\fmw12214、D:\oracle\domains\base_domain同样避开中文和空格。2.3 安装包选型与完整性校验安装包一般分两种形态一种是带图形界面的通用安装器另一种是精简版安装器。通用版体积大一些好处是图形向导完整Windows 上很省事精简版体积小适合在 Linux 服务器上跑静默安装参数上的区别主要是安装类型和组件选择范围。选哪个取决于你的场景本地调试用通用版批量部署用精简版两者产出的安装目录结构基本一致。下载完之后务必核对文件的大小和校验值这一步别省。我遇到过因为下载中断导致包不完整安装器跑到一半报“解压失败”排查半天才发现是包的问题。校验通过之后Windows 上直接双击或者用命令行运行安装器Linux 上先用专用用户把包解压到临时目录再执行安装命令。安装过程中会先生成一份安装清单这份清单存在的意义是让系统知道“装过什么”后续要打补丁或者卸载都靠它所以别随便删。3. Windows 上的搭建实操Windows 这条线的核心是图形化向导操作门槛低但有几个默认选项需要手动改。下面按安装、建域、启动验证的顺序走一遍每一步都说明为什么这么选。3.1 图形化安装的每一步安装前先把 JDK 装好配好JAVA_HOME在命令行里执行java -version确认能正常输出。然后打开命令提示符切换到安装包所在目录用java -jar 安装包文件名启动安装器。图形界面出来后第一屏是简介第二屏通常会问是否接收更新通知本地调试环境直接跳过即可只有正式环境才需要考虑注册支持账号。接下来是最关键的两屏一是安装位置把默认路径改成你规划好的纯英文路径二是安装类型选择“完整安装”还是“精简安装”。本地开发选完整安装图省事如果只是跑一个简单应用精简安装就够了能少装不少用不到的组件。安装过程大概几分钟到十几分钟取决于磁盘速度。结束后它会提示你记下安装目录和域创建的快捷入口别急着关这两个信息后面要用。注意如果安装器界面出现文字显示不全或者乱码多半是系统区域设置或者字体问题改成英文界面重跑一次通常就能解决不需要重装。3.2 建域向导里几个容易选错的选项域是运行的实际载体一个安装目录可以创建多个域每个域有自己独立的配置和日志。Windows 上创建域有两条路一条是图形化配置向导一条是命令行脚本。第一次搭环境建议用图形向导看得到每一个选项后面熟悉了再用脚本效率高。向导里第一个要选的是模板类型默认的基础模板就够用除非你要做集群或者特定组件组合才需要选带扩展的模板。第二个是管理员账号和密码密码策略会随后面选的模式变化开发模式宽松一些生产模式要求更严建议一开始就按生产模式的要求设省得后面再改。第三个是监听端口默认的管理端口是 7001如果这台机器上已经有别的服务占了这个端口提前换掉别等启动报错再回来改。第四个是启动模式前面提过搭建阶段可以先选开发模式打通流程。3.3 启动验证与常用脚本改造域建好之后进入域目录下的bin子目录运行启动脚本比如startWebLogic.cmd。第一次启动会提示输入管理员账号密码输入后窗口里会滚动大量日志等到出现类似“服务器状态变更为 RUNNING”的字样说明启动成功。然后打开浏览器访问http://localhost:7001/console能进管理控制台就算通了。Windows 上有个常见需求是把启动脚本改成不弹窗的后台运行方式方便挂着跑。做法是写一个批处理用start命令配合重定向把输出写到日志文件里这样即使命令行窗口关了服务也能继续跑。但要注意这种方式下停止服务得用另一个脚本或者直接调管理控制台里的关闭功能别直接杀进程容易留下锁文件。echo off set DOMAIN_HOMED:\oracle\domains\base_domain call %DOMAIN_HOME%\bin\startWebLogic.cmd %DOMAIN_HOME%\logs\console.log 21把这段存成.bat文件双击就能在后台起服务。日志里如果出现内存相关的告警先别慌接着往下看内存参数那节。4. Linux 上的搭建实操Linux 这条线是重头戏因为真正长期运行的环境基本都在这里。核心思路是所有操作都用专用用户所有参数都写成可复现的配置文件所有步骤都能脚本化。下面按系统准备、静默安装、脚本建域、启停管理四块展开。4.1 系统层面的准备清单第一件事是建专用用户和用户组。不要把中间件跑在 root 下一是权限太大风险高二是很多脚本会检测当前用户用 root 跑可能触发额外的告警。建好用户后把规划好的目录一次性创建出来所有权统一交给这个用户。第二件事是检查文件描述符限制用ulimit -n查看当前值如果太小比如 1024后续实例跑起来连接一多就会报“打开文件过多”的错。建议在系统的限制配置里把软硬限制都提到一个较大的值比如几万级别。第三件事是主机名解析这是 Linux 上最容易被忽略、后果又最严重的一项。中间件启动时会拿本机主机名去做反向解析如果/etc/hosts里没有对应的映射解析会超时表现就是启动特别慢慢到你以为卡死了。解决方法很简单在/etc/hosts里加一行把本机主机名指到本机地址。# 查看当前主机名 hostname # 追加映射假设主机名为 wls-node01 echo 127.0.0.1 wls-node01 /etc/hosts第四件事是系统参数。12c 系列起中间件改用内存映射文件而非早期那种系统级共享内存段所以传统上要调的那几个信号量和共享内存参数不再是硬性门槛但文件描述符、进程数这类限制依然要关注。把这几项确认完系统层面就算干净了。检查项命令期望值文件描述符ulimit -n数万级别最大进程数ulimit -u数万级别主机名解析ping $(hostname)能立刻返回JDK 可用性java -version输出目标版本4.2 静默安装response file 怎么写Linux 服务器通常没有图形界面就算有也不建议开所以静默安装是标准做法。静默安装需要两个文件一个安装清单定位文件一个应答文件。安装清单文件告诉安装器把记录写到哪里、属于哪个组应答文件告诉它装到哪个目录、装哪些组件、要不要注册支持账号。清单文件的内容很简单两行就够inventory_loc/u01/app/oraInventory inst_groupoinstall应答文件稍微讲究一点关键是把安装根目录写对、安装类型写对、更新通知关掉[ENGINE] Response File Version1.0.0.0.0 [GENERIC] ORACLE_HOME/u01/app/oracle/product/fmw12214 INSTALL_TYPEWebLogic Server DECLINE_SECURITY_UPDATEStrue SECURITY_UPDATES_VIA_MYORACLESUPPORTfalse两个文件准备好之后用专用用户执行静默安装把日志重定向出来方便排查cd /u01/soft java -jar fmw_12.2.1.4.0_wls.jar -silent \ -responseFile /u01/soft/wls.rsp \ -invPtrLoc /u01/soft/oraInst.loc \ -log /u01/soft/install.log命令跑完之后别只看退出码去日志末尾确认有没有“安装成功”的字样同时检查安装目录下是否生成了预期的子目录。这一步确认无误安装阶段就算过了。4.3 用 WLST 脚本建域图形化建域在 Linux 上不方便脚本建域才是正路。中间件自带一套脚本工具可以读模板、改配置、写域整个过程写在一个脚本文件里反复执行都能得到一致结果。核心动作是四步读模板、改管理服务器的监听地址和端口、设管理员密码、写出域。下面是一份可以直接改用的脚本注意路径和密码要换成你自己的readTemplate(/u01/app/oracle/product/fmw12214/wlserver/common/templates/wls/wls.jar) cd(/Servers/AdminServer) set(ListenAddress, ) set(ListenPort, 7001) cd(/Security/base_domain/User/weblogic) cmo.setPassword(YourPassword123) setOption(OverwriteDomain, true) setOption(ServerStartMode, prod) writeDomain(/u01/app/oracle/domains/base_domain) closeTemplate() exit()保存成domain.py然后用脚本工具执行/u01/app/oracle/product/fmw12214/oracle_common/common/bin/wlst.sh /u01/soft/domain.py执行过程中会打印每一步的进度最后出现写域完成的提示就成功了。这里的ServerStartMode设成了prod如果你还在调试阶段可以先改成dev等应用跑通再切回来。切回来的时候不需要重建域改一下配置里的模式参数重启即可但要注意生产模式下默认的安全策略更严之前能访问的某些资源可能会被拦。提示管理员密码别直接明文写在脚本里长期留存正式环境可以考虑先用一个占位密码建域再改掉。4.4 启动、开机自启与日常启停脚本启动脚本在域目录的bin下叫startWebLogic.sh。直接前台运行会把日志刷在屏幕上适合第一次验证cd /u01/app/oracle/domains/base_domain/bin ./startWebLogic.sh等看到状态变成运行中另开一个终端用curl或者浏览器访问管理控制台端口能返回页面就说明成功。确认没问题后改成后台运行nohup ./startWebLogic.sh /u01/app/oracle/domains/base_domain/logs/console.log 21 日常维护里我习惯再包一层启停脚本把启动、停止、查看状态三个动作封装起来用起来省心也方便交给其他人接手。停止的时候优先用中间件自带的停止脚本它会走正常的关闭流程把缓存和连接都释放掉直接杀进程虽然快但偶尔会留下需要手工清理的锁定文件。#!/bin/bash DOMAIN_HOME/u01/app/oracle/domains/base_domain case $1 in start) nohup $DOMAIN_HOME/bin/startWebLogic.sh $DOMAIN_HOME/logs/console.log 21 ;; stop) $DOMAIN_HOME/bin/stopWebLogic.sh ;; status) ps -ef | grep weblogic | grep -v grep ;; esac如果要求开机自启可以把它注册成系统服务但要注意服务单元里得显式指定用户和工作目录否则启动时会拿不到正确的环境变量。5. 踩坑记录常见故障排查与参数调优前面流程走完环境基本能跑起来了。真正耗时间的从来不是搭建而是跑起来之后冒出来的各种毛病。这一节把高频问题和参数调优集中讲一遍都是我实际碰到过并且有明确解法的。5.1 启动失败类问题速查表下面这张表是长期积累下来的遇到问题先在这里对一遍能省掉大量翻日志的时间。现象可能原因处理方式启动瞬间报类版本错误JDK 版本与中间件不匹配换成认证矩阵里的 JDK 版本启动极慢几分钟没动静主机名无法解析在 hosts 文件里补映射提示地址已被占用端口冲突换端口或停掉占用进程日志报打开文件过多文件描述符限制过低提高系统限制后重启内存溢出堆参数给得太小调整启动内存参数控制台能开但应用访问 404应用未部署或部署失败检查部署日志和上下文根拿“启动极慢”这条举个例子现场表现是执行启动脚本后终端里长时间没有任何新日志输出看着像卡死。这时候别急着杀进程先在另一个终端执行hostname拿到主机名再看/etc/hosts里有没有这一行。十有八九是缺了映射补上之后重启启动时间会从几分钟缩到几十秒。这个问题的隐蔽之处在于日志里往往不会直接告诉你“解析失败”只会在最后打出一段超时相关的记录不熟悉的人很容易误判成内存不够。再比如“地址已被占用”Windows 上用netstat -ano | findstr 端口号找到占用进程Linux 上用lsof -i:端口号或者ss -lntp查确认不是自己之前启动的实例没退干净。我碰到过最无语的一种情况是之前启动的实例其实还活着只是终端窗口关了看不见重新启动自然就冲突了。5.2 内存与连接参数怎么给内存参数是影响稳定性的头号因素。默认配置通常给得比较保守只够跑起来稍微上点负载就吃紧。调整的思路是先看机器总内存再按实例数量分配。单实例情况下堆内存可以给到机器内存的三分之一左右剩下的留给系统和其他进程。堆的初始值和最大值设成一样避免运行期反复扩张带来的停顿。Linux 上调整的方式是在启动前导出内存参数环境变量或者直接改域目录下的环境配置脚本里对应的变量。改完之后一定要重启验证并且用监控命令确认生效。别只在脚本里改了却忘了重启然后对着旧参数排查半天。export USER_MEM_ARGS-Xms1024m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512mWindows 上对应的做法是在启动脚本里用set设置同样的变量位置放在调用启动逻辑之前。除了堆内存还要关注线程数和连接数这两个参数跟应用的类型强相关长连接多的应用要放宽连接池计算密集型的应用要控制线程数盲目调大反而会因为上下文切换拖慢整体。5.3 几个容易被忽略的生产细节第一个是日志管理。默认情况下日志会一直写时间长了能把磁盘撑满。要提前规划日志的轮转策略按大小或者按天切分并且定期清理历史文件。我见过因为日志占满分区导致实例直接停止响应的案例恢复起来很麻烦。第二个是时间同步。集群环境下各节点时间差太多会引发一系列诡异问题比如会话莫名其妙失效、日志时间线对不上。部署前确认所有节点都接到了统一的时间源。第三个是备份。域目录里的配置文件和部署的应用包要定期备份尤其是手工改过配置之后。重建一个域虽然不难但把之前所有定制化的配置重新调一遍很费时间。注意任何参数调整都建议一次只改一项改完验证确认没问题再动下一项。一次性改一堆参数出问题的时候根本不知道是哪一个引起的。第四个是账号和权限。管理控制台的账号密码不要用弱口令也不要在团队里共用一个账号出了问题没法追溯。正式环境建议把默认的管理员账号保留但限制使用日常操作走单独的账号。第五个是版本一致性。如果后续要做集群节点之间的中间件版本、JDK 版本、补丁级别必须完全一致差一个小版本都可能出现节点之间无法通信的情况。搭建阶段就把版本信息记录归档后面加节点时直接对照。最后分享一个我自己常用的笨办法整个搭建过程用文本记录下来每执行一条命令就记一行包括当时的输出。这套记录在后续排查和重建环境时价值极高比事后凭记忆复盘靠谱得多。环境搭建这件事做一次是体力活做两次是经验做三次就该有一套完全属于自己的脚本和文档了。