简介一份面向WebLogic服务器运维与中间件管理人员的补丁集更新资源包对应WebLogic 12.2.1.4.240704版本补丁标识为36805124用于修复该版本运行中暴露的已知缺陷适合在生产环境升级前进行缺陷评估和补丁验证。压缩包内共两千个文件主要包含编译后的class类文件、java源文件、xml与properties配置、jar依赖库以及html说明文档、jsp页面、sql脚本、cmd命令等辅助内容整体大小约为一百二十七点四八兆字节目录按补丁模块组织便于快速定位与提取。该资源已有二百零一人学习下载。补丁包不仅列出本次更新修复的错误还汇总了自二零二一年九月三十日至二零二四年三月二十五日多个历史补丁集更新解决的问题覆盖安全管理、核心域、部署工具、集群类型等WebLogic常用组件帮助使用者了解各版本的缺陷修复轨迹评估升级影响范围制定更稳妥的实施与回退方案。 WebLogic 这个东西很多年纪轻一点的开发可能都没怎么碰过了但它在企业级 Java 应用里头的地位扛过了二十年现在依然是不少银行、保险、电信系统的底座。我最近刚给一套 12.2.1.4 的生产环境打了最新的 2024 年 7 月季度补丁就是标题里这个WLS PATCH SET UPDATE 36805124。整个过程踩了几个不算深但很烦的坑顺手整理成一篇实操笔记希望能帮到正在准备动补丁或者被安全合规追着整改的同行。这篇笔记的重点不是把命令贴一遍完事而是把补丁安装的思路、为什么这么做、哪些步骤最好别省、出了问题怎么退回去全部讲清楚。后面要装的这个补丁Oracle 官网的补丁号是36805124对应的 WebLogic 版本标识是12.2.1.4.240704属于季度性的大补丁包PSU。它能修掉一批安全漏洞和稳定性问题同时也会更新 WebLogic Server 里 WLS Core、JRockit、Coherence 等若干组件的版本信息。1. 先搞清楚要装的是什么PSU 和普通补丁的差别1.1 版本号到底怎么读官方给出的完整版本写法是12.2.1.4.240704。拆开看12.2.1.4是 WebLogic 的主版本表示这是 12c R2 这个大版本线的第四个补丁维护版本。后面的240704是日期标识意思是这个补丁集对应的是2024 年 7 月 4 日发布的季度更新。Oracle 对 WebLogic 的补丁发布频率是固定的每年 1 月、4 月、7 月、10 月都会出一个大的 PSU 补丁包同时也会发单独的 CPUCritical Patch Update公告。像24代表 2024 年07代表 7 月04代表公告发布日的第 4 天。这套日期规则基本通用看到任何类似的四段式版本号都能按这个思路解码。1.2 CPU、PSU、SPU 到底有什么区别很多刚接触 WebLogic 的人会被 CPU、PSU、SPU 这些缩写绕晕。我用最简单的话总结一下CPUCritical Patch UpdateOracle 每个季度发布的紧急安全补丁集合重点修安全漏洞不包含非安全性的功能修复。PSUPatch Set Update在 CPU 基础上增加了部分经过充分验证的稳定性和功能性修复属于“安全加稳定”的合订本。一般建议生产环境优先选择 PSU。SPUSecurity Patch Update早期叫法某种程度上和 CPU 类似现在已经逐渐被 CPU 的叫法取代。One-off Patch单点补丁针对某个具体 Bug 打的小补丁应用范围窄不能替代 PSU。这次要装的 36805124 就是一个PSU意味着里面既包含了当季的安全漏洞修复也附带了一些已修复的稳定性问题。对运维来说打一个 PSU 比挨个安装多个单点补丁更省事也不会因为补丁之间互相覆盖而产生冲突。1.3 为什么不能跳过低版本补丁直接装最新的曾有同事问我既然 2024 年 7 月有 PSU那我直接从没打过补丁的原版 12.2.1.4 跳到最新不行吗理论上 Oracle 允许你直接应用最新的 PSU因为补丁包本身是累积的——也就是最新 PSU 已经包含了之前所有 PSU 的内容。但实际操作里我不建议生产环境这么做。原因是中间长时间没打补丁意味着 WebLogic 版本跨度大升级过程中可能连带触发一些本来可以通过中间版本平滑过渡的兼容性问题。很多组件比如 JDK、Coherence的 patch bundle 会随着 PSU 更新跳过中间版本可能会导致某些应用的自定义证书、加密配置出现意外不兼容。遇到问题时Oracle Support 大概率会要求你先验证中间版本的日志记录排查链条会特别长。所以我的建议是生产环境至少保持每季度跟一次补丁别拖太久。如果确实已经落后很多版本至少先在测试环境完整走一遍应用兼容性验证再带着充分的心理准备和回滚方案上生产。2. 打补丁之前的准备工作比执行补丁本身更重要2.1 先确认当前环境版本、架构、补丁现状开始之前用下面这组命令快速体检环境# 查看当前 WebLogic 版本 cd $MW_HOME cat registry.xml | grep -i WebLogic Server # 查看已经安装的补丁 $MW_HOME/OPatch/opatch lsinventory重点关注输出里的Patch Level和Installed Top-level Patches列表。如果这里已经存在某条带234449、32922663之类编号的补丁记录说明环境之前维护得还算及时如果显示一大串 One-off Patch或者干脆是空列表就要格外留意后续的冲突检查。另外看清楚当前用的是 JRockit 还是 HotSpot JDKWebLogic 12.2.1.4 对 JDK 版本有明确要求。新 PSU 一般要求 JDK 8u 至少到某个小版本顺序错了会导致补丁应用后启动直接报UnsupportedClassVersionError。2.2 补丁兼容性检查清单去 Oracle Support 下载补丁时页面会提供一份Readme文件建议下载后先读再动手。Readme 里最关键的信息包括补丁对应的最低 OPatch 版本要求。是否要求必须安装某个前置补丁比如某个特定的 Coherence 补丁。补丁安装后是否要求重新编译 stubrm -rf $DOMAIN_HOME/servers/*/tmp。补丁是否影响 WLST 脚本、数据源、JMS 等常用功能。我习惯把 Readme 里提到的要求整理成一张清单挨个核对。这里分享一个比较通用的检查表检查项操作命令 / 判断标准是否达标当前 WebLogic 版本cat $MW_HOME/registry.xml12.2.1.4.xOPatch 版本opatch version不低于 13.9.4.2.xJDK 版本java -version1.8.0_xxx按 Readme 要求已装补丁列表opatch lsinventory记录当前状态空间检查df -h /u01或系统盘至少预留 5GB 以上域目录备份tar czf完整备份 1 份中间件安装目录备份tar czf有条件就备份配置库config.xml备份使用 WLST 导出保留 1 份提示不要忽略 OPatch 版本要求。很多次补丁安装失败的原因就是 OPatch 版本太低opatch apply会直接报错并中止。如果 Readme 要求 OPatch 13.9.4.2 以上而系统还是 13.8先单独升级 OPatch再跑补丁。2.3 备份的粒度要细后悔药要备足很多运维打补丁最怕的就是出了问题没退路所以备份这一步千万别省。我个人推荐的备份方案是中间件安装目录MW_HOME整体备份如果环境允许直接把整个 WebLogic 安装目录打包虽然大但最稳。Domain 目录完整备份包括config、bin、lib、servers、security这些关键子目录。Domain 是业务核心必须单独备份。配置导出用 WLST 连接 AdminServer执行export命令把当前配置导出为 XML 文件。这样就算回滚后配置异常也能快速对比找回。实际生产里大部分企业会采用“介质备份 虚拟化快照”双保险。打完补丁再重启域万一启动失败虚拟化快照可以直接回滚到补丁前的状态比解压缩 tar 包快得多。2.4 停机窗口和变更步骤的评估PSU 补丁的核心步骤是替换中间件安装目录下的 jar 包、注册表、组件配置所以打完补丁后整个域的实例都必须重启。特别要注意的是如果环境里有多个 AdminServer比如集群 多机部署所有机器上的 WebLogic 安装目录都要打同样的补丁且必须保证所有 AdminServer 和 ManagedServer 的补丁版本一致否则集群节点之间可能因为二进制版本不一致出现异常。所以打补丁前一定要和业务方确认好停机窗口。一般来说先打一个非核心测试机、把完整流程和启动验证做完再造一个灰度环境最后才是生产环境。这个顺序我建议固定下来别嫌麻烦。3. 补丁安装实操流程从停服到验证3.1 停掉服务和所有实例这一步听着简单但实际操作中有几个坑不要只停 AdminServerManagedServer 也要全部停掉。如果使用了 NodeManager 守护进程建议先把 NodeManager 也停掉避免它自动拉起实例。停服务前先记录一下当前 WLS 版本方便之后核对是否变更成功。停服务的方式推荐用域目录下的stopWebLogic.shLinux或stopWebLogic.cmdWindows不要直接 kill 进程除非已经出现无法正常停止的情况。直接 kill 会留下持久化文件和配置锁后续启动时容易出现“Invalid state”之类的问题。# 示例进入域目录停止 AdminServer cd $DOMAIN_HOME/bin ./stopWebLogic.sh # 等 AdminServer 完全停止后可以再确认进程是否存在 ps -ef | grep weblogic注意如果当前环境是集群建议逐个节点停止并确认每个节点的ServerState变为SHUTDOWN再继续下一步。3.2 解压补丁包并执行 opatch apply补丁包下载好之后通常是一个 zip 文件如下unzip p36805124_122140_Generic.zip -d /u01/patch_dir cd /u01/patch_dir/36805124开始执行前再次确认 OPatch 版本满足要求。然后执行$MW_HOME/OPatch/opatch apply这个命令会检查当前环境、比对补丁兼容性如果一切正常会打印出待应用的补丁列表并要求你输入y确认。看到Applying patch...之后系统会花几分钟到十几分钟时间做文件替换和注册表更新。期间千万不要中断否则容易造成补丁目录信息不一致。可以同时看日志文件比如tail -f $MW_HOME/cfgtoollogs/opatch/opatch2024-07-04_XXX.log安装完成后如果输出包含OPatch succeeded.说明 apply 成功。如果中途报错别慌看错误类型多数是 OPatch 版本不支持或者缺前置补丁按 Readme 的要求补齐再重新跑即可。3.3 确认补丁登记状态打完补丁后用opatch lsinventory再查一遍确认补丁编号 36805124 已经出现在已安装列表里。$MW_HOME/OPatch/opatch lsinventory | grep 36805124同时也得确认版本号变成12.2.1.4.240704cat $MW_HOME/registry.xml | grep 12.2.1.4如果这里能看到12.2.1.4.240704说明补丁已经成功写入了注册表。注意这一步只能说明补丁装上了不代表服务能正常启动。3.4 启动 AdminServer 和 ManagedServer 并验证业务启动顺序一定是先 AdminServer再 ManagedServer。别问为什么问就是 WebLogic 的启动依赖集群配置和域配置AdminServer 没起来ManagedServer 即使起来了也是待定状态。cd $DOMAIN_HOME/bin nohup ./startWebLogic.sh /tmp/wls_admin.log 21 等 AdminServer 日志输出类似Server state changed to RUNNING时再启动 ManagedServer。启动完成后重点检查以下几点数据源是否能正常连接数据库尤其是使用了 JDBC 数据源的应用补丁更新后有时 JDBC 驱动会变。JMS 消息队列是否正常持久化消息有没有丢失。应用部署状态是不是Active。登录 Web Console确认各服务器的健康状态是OK。如果这些都没问题基本可以宣布补丁安装成功。4. 补丁验证的细节和回滚的正确姿势4.1 验证不只是看版本号很多运维在补丁打完看到版本号对了就认为任务完成。但补丁影响的是运行时行为版本号只能说明文件被替换了不代表应用还是好的。我习惯做一轮“业务冒烟测试”包括使用测试账号走一遍核心业务接口登录、查询、提交。检查关键日志确认没有新增的 ERROR 或 WARN。特别是和 Coherence、事务、数据源相关的报错。对比补丁前的日志基线看看有没有新增异常堆栈。如果是安全补丁可以顺便确认一下公告里提到的 CVE 编号是否在环境里已经消失比如某些校验逻辑不再触发。安全团队如果催得紧可以在验证完功能后按 Oracle 公告里的漏洞列表对照一遍系统输出的启动日志和扫描结果。不过要注意不是所有 CVE 修复都能在运行日志里直接体现很多是静态扫描或版本识别层面的变化判“已修复”最直接的证据是补丁安装记录和版本号变了。4.2 回滚补丁的正确打开方式补丁出问题后回滚的关键是找到正确的回滚顺序。假设你在这次变更中只打了一个 PSU那么回滚命令很简单$MW_HOME/OPatch/opatch rollback -id 36805124但如果环境之前装过多个补丁且存在依赖关系回滚顺序就需要反过来。例如先装了 A 补丁再装了 B 补丁此时回滚要先回滚 B再回滚 A不能直接回滚 A否则 B 的文件可能已经不完整。回滚完成后同样要执行$MW_HOME/OPatch/opatch lsinventory确认 36805124 已经从列表中移除。接着重启服务做一遍和打补丁时一样的冒烟验证。这里我的实战经验是回滚后的验证至少要做到重启一次域并且跑通关键业务而不是只确认版本号变了就完事。因为回滚后文件版本降回去了某些新配置可能没有跟着消失容易造成“半新半旧”的混合状态。4.3 回滚后出现异常怎么兜底回滚后最常见的异常是启动失败报错通常是某个类找不到或者 ClassCastException。这种问题的根因一般是回滚时只替换了 jar 包但配置缓存或部署临时文件里还残留新版本的内容。解决方式清理 Domain 下servers/*/tmp和servers/*/cache目录。用备份的 Domain 目录覆盖回滚后的状态。如果还不行用引入的虚拟化快照恢复。我自己遇到过一次特别蹊跷的情况回滚之后opatch lsinventory显示补丁已经移除但应用启动时依然调用新补丁里的某个类。查了半天发现是 OSGi 缓存和部署计划缓存没有被清掉。把servers/*/data/nodemanager下的缓存文件也删掉之后问题解决。5. 实战问题排查与安全合规建议5.1 OPatch 版本过低导致的 apply 失败现象执行opatch apply报错OPatch version is lower than required。原因PSU 补丁要求至少某个 OPatch 版本老环境的 OPatch 一般都不达标。解决去 Oracle Support 下载最新 OPatch先升级 OPatch再重新执行 apply。cd /u01/opatch_upgrade unzip p6880880_*.zip cp -r OPatch/* $MW_HOME/OPatch/这里额外提醒一句升级 OPatch 前最好备份旧 OPatch因为部分小版本可能存在兼容性差异升级后某些老补丁的 rollback 可能受影响。5.2 补丁冲突Conflict现象opatch apply提示Patch ... conflicts with another patch然后中止。原因当前环境里已有一个 One-off Patch 和 PSU 修改了同一个文件或者你之前手动替换过某个 jar。解决先用opatch lsinventory -detail查看冲突补丁的编号和内容再决定是先把旧补丁回滚掉还是升级到覆盖冲突的补丁版本。遇到这种情形我建议先对照 Readme 确认冲突补丁是否是本 PSU 的前置补丁如果是直接回滚掉旧的即可。5.3 域模式下启动卡住或节点同步失败补丁更新后如果集群有多台机器且节点同步开启了“自动同步”AdminServer 会把二进制变更下发到 ManagedServer 节点。但有些机器的bin/startManagedWebLogic.sh里写死了启动路径导致同步失败。排查查看 ManagedServer 日志如果出现Downloading new binary...后面跟着SocketException或IOException多半是网络或权限问题。这台机器上的中间件安装目录需要手动打同一个补丁或者检查mw_home路径配置。一般业务环境不建议依赖自动同步来批量推送补丁手动逐台打稳得多。5.4 安全加固检查与审计项打完补丁后安全团队的审计通常需要你提供这样几项材料补丁编号和日期描述368051242024-07-04。补丁应用前后的版本截图。补丁回滚预案的文档。所有节点的补丁状态确认最好导出opatch lsinventory的结果存档。如果单位有定期例行的安全扫描建议扫描前先在测试环境验证补丁确实覆盖了扫描器认为存在的 CVE。这里容易踩的坑是扫描器靠的是版本识别和端口响应指纹而不是文件比对所以哪怕打上了最新 PSU扫描报告里可能依然显示旧指纹。这种情况得和扫描团队解释版本号需要以应用层的输出为准或者由扫描工具进行深度匹配。最后分享一点我的个人体会WebLogic 补丁安装技术本身并不复杂但真正让人头疼的是变更管理和环境差异。我从一开始觉得“打个补丁就是把命令敲一遍”到后来养成“每次变更前都写一份带验证步骤和回滚步骤的执行方案”心态和效率都提高了很多。经验一把 OPatch 和补丁包备份成本地离线源。很多企业生产环境不能直连外网临时下载补丁往往要等审批。我在服务器上保留了一个patch_repo目录每次下载完补丁和解压工具都会归档标注日期和版本。这样下个季度再打补丁时不需要重新找文件也方便追溯。经验二记录每个环境的具体变更时间、操作人和结果。别小看这个动作。出了问题时能快速判断某次补丁变更是否是故障源头。我习惯用一张表格记录环境、日期、补丁号、打补丁前后的版本、执行人、验证结果。将来做隐患回溯时这张表价值巨大。经验三对生产环境永远不要用“试试看”的心态来打补丁。每一条命令每一个参数都应该先在测试环境验证过。我在这次 36805124 的升级里先在测试机完整跑了一遍确认无异常后才在生产执行。整个过程耗时 40 分钟但面对生产时心里有底得多。如果后续你也在准备给 WebLogic 打 PSU我的建议很简单把这篇笔记里的准备清单、执行步骤和验证方法当成模板套到你的环境里跑一遍大多数常规问题都能提前规避。补丁这种东西只要流程规范、备份到位、验证充分它就只是一个普通的日常变更反过来流程草率再小的补丁也能让你熬夜到天亮。本文还有配套的精品资源点击获取