企业官网建设流程全解析

前阵子有个朋友从容器环境切回传统中间件部署一套老系统，电话里跟我吐槽："现在还有人用WebLogic吗？"我回他说："你不是正在用吗。"这句玩笑背后其实是个很现实的问题：WebLogic在国内的银行、证券、制造、物流这些行业里，存量系统的占比远比很多人想象中高。我这些年陆陆续续部署过几十套WebLogic环境，从10.3.6一路装到14c，中间踩过的坑攒下来确实不少。

这篇不打算复述官方文档，而是从一次相对完整的部署经历出发，把版本选择、环境准备、安装方式、Domain创建、应用部署、安全加固和故障排查这几个环节里，真正值得注意的事串起来。无论你是第一次接触WebLogic的新手，还是部署过几台但总在某个环节卡壳的运维，这篇应该都能让你少走点弯路。

1. 为什么还在用WebLogic：版本选型与真实生态

很多人不理解，都什么年代了还在用商业中间件。这个问题的答案其实很简单：不是想用，是不得不用。很多核心业务系统在十多年前选型时就绑定了WebLogic，这些年业务模型、事务逻辑、定制化API全都跑在这套容器上，迁移成本远高于购买许可的成本。

1.1 WebLogic在中间件市场的真实位置

Oracle WebLogic Server是Java EE规范层面的重型应用服务器，支持EJB、JMS、JTA、分布式事务、集群、Session复制等全套企业级能力。和Tomcat这种轻量级Servlet容器相比，它多了完整的事务管理、消息中间件、集群会话保持和运维控制台。对单机小应用来说Tomcat够用，但对需要强一致性事务、跨节点Session、集中式管理的系统来说，WebLogic依然是很多企业架构师的首选。

从版本分布看，目前生产环境里最常见的还是下面几个大版本：

1.2 版本选型时容易忽略的几件事

选版本不能只看WebLogic本身的版本号，要看三个方面：

第一，JDK版本。WebLogic和JDK的匹配关系是硬约束，装错了轻则启动报错，重则运行期出现各种莫名奇妙的类加载异常。比如10.3.6官方推荐JDK 1.6/1.7，硬让它跑在JDK 1.8上，某些并发场景下会出现线程池异常。

第二，应用的编译目标。很多老应用是用JDK 1.6编译的，强行放到高版本WebLogic上跑，虽然大部分情况没问题，但遇到反射、字节码增强这类操作时，很容易因为模块化限制或者类库变更出问题。

第三，补丁支持周期。10.3.6的官方补丁支持早已结束，如果系统必须跑在这个版本上，至少需要在前面加一层访问控制，不能裸奔在公网。

1.3 什么情况下真的需要用WebLogic

如果你在做技术选型，我的建议是：没有外部约束时，Spring Boot加内嵌Tomcat的方案开发效率更高，也更容易招人维护。但如果你遇到下面这些情况，WebLogic依然是合理选择：

• 系统原本就跑在WebLogic上，存在大量EJB或JMS调用
• 甲方技术规范里明确指定了WebLogic
• 业务需要强一致性的JTA分布式事务，且不希望引入额外中间件
• 项目要求集群部署、Session复制、多机热备，需要一个成熟的控制台统一管理

2. 安装前必须先对齐的三件事：JDK匹配、系统账号与目录规划

正式执行安装文件之前，有大量准备工作要做。省略这一步直接去敲命令，后面大概率要返工。我见过太多在安装过程中突然停下来查"为什么这里选不了JDK"的人，基本都是环境准备阶段偷了懒。

2.1 JDK版本匹配是硬指标

WebLogic的安装程序本身是用Java写的，所以安装机器上必须先有一个可用的JDK。这里有个关键细节：安装程序和目标运行环境可以共用同一个JDK，但版本必须落在WebLogic官方兼容矩阵里。

以12.2.1.4为例，官方支持Oracle JDK 8（update 171及以上）和JDK 11。我个人的建议是：生产环境用Oracle JDK 8，尽量选较新的update版本。不要图新鲜用JDK 11，除非你的应用已经完整验证过。虽然官方说支持，但不少老程序的字节码操作和ClassLoader行为在JDK 11上表现不一样。

验证JDK是否可用，就两行命令：

java -version javac -version

注意，输出里要看到的是厂商和版本号，比如java version "1.8.0_202"。如果你装的是OpenJDK，也没问题，但建议先在测试环境跑一遍应用，确认没有依赖Oracle JDK的私有接口。

2.2 创建专用系统账号，别用root跑

这是我在生产环境踩过最深刻的坑之一。用root安装WebLogic，安装过程一路畅通，但启动后的Managed Server进程可能会以root权限运行。一旦应用出问题被利用，整个机器就沦陷了。正确的做法是创建一个专用账号：

groupadd weblogic useradd -g weblogic -d /u01/weblogic weblogic

后续所有安装和部署都用这个账号操作。数据目录和日志目录单独建，例如：

mkdir -p /u01/weblogic mkdir -p /u01/weblogic/domain mkdir -p /u01/weblogic/applogs chown -R weblogic:weblogic /u01/weblogic

磁盘规划也要提前想好。WebLogic本身安装目录大概占用2-3GB，但Domain目录会随运行时间膨胀，因为日志、临时文件、部署的快照都会写进去。建议给Domain挂一个独立分区，或者至少预留50GB以上空间。

2.3 安装包的选择：通用jar包还是开发版

Oracle官方提供两种安装介质：一种是可以跨平台执行的jar包（如fmw_12.2.1.4.0_wls.jar），另一种是针对特定平台的二进制安装包。我个人建议用通用jar包，因为它在Linux和Windows上统一用java -jar触发安装，行为一致，也好做静默安装脚本。

下载时注意文件名里的版本标识，10.3.6时代的包名和12c以后的包名规则不一样。到了12.2.1.x以后，Oracle把WebLogic、Coherence等组件打包在Fusion Middleware介质里，安装时可以选择要装哪些组件。

提示：如果你所在的网络环境无法直接从Oracle官网下载，可以去Oracle Software Delivery Cloud找历史版本，但一定先确认版本与JDK的匹配关系再下载。

3. 两种安装路线：图形化向导与静默安装各踩过的坑

WebLogic安装程序有两种启动方式，对应两种使用场景。新手和图形界面环境可以走图形向导，生产环境或者虚拟机没有显示器的场景必须用静默安装。两条路线我都走过多遍，各自说点实用的。

3.1 图形化安装的完整流程

图形化安装适合本机有显示环境、只装一两台的场景。执行：

java -jar fmw_12.2.1.4.0_wls.jar

安装程序会弹出一个Java Swing界面，核心步骤就几步：选择安装目录、选择安装组件、填写Oracle Home位置、选JDK。有几个地方容易踩坑：

第一，组件选择。默认会勾选WebLogic Server和Oracle Coherence。如果系统用不到Coherence，可以不勾，减少安装面积和补丁范围。第二，Oracle Home目录和WebLogic Home目录是有区别的。Oracle Home是Fusion Middleware产品的顶层目录，WebLogic Home在其下。很多人搞混这两个路径，导致后面WLST脚本连接时报错。

安装完成后，默认会创建一个$ORACLE_HOME/wlserver目录，这就是WebLogic的Home。后续启动脚本、Deployer命令都会从这里找类库。

3.2 静默安装才是生产环境的正确姿势

生产环境往往没有图形界面，甚至在安全加固后连X11转发都禁了。这时候用响应文件做静默安装是最可靠的。响应文件是一个properties格式的文本，核心内容如下：

[ENGINE] Response File Version=1.0.0.0.0 [GENERIC] ORACLE_HOME=/u01/weblogic/install_home INSTALL_TYPE=WebLogic Server DECLINE_SECURITY_UPDATES=true SECURITY_UPDATES_VIA_MYORACLESUPPORT=false

几个参数说明一下：ORACLE_HOME是安装的绝对路径，INSTALL_TYPE可以指定完整安装或自定义安装，DECLINE_SECURITY_UPDATES和SECURITY_UPDATES_VIA_MYORACLESUPPORT是用于跳过Oracle在线注册流程的。不写这两个参数，安装程序会卡在更新设置那一步。

执行静默安装的命令是：

java -jar fmw_12.2.1.4.0_wls.jar -silent -responseFile /path/to/wls.rsp -invPtrLoc /path/to/oraInst.loc

-invPtrLoc指定无效列表文件位置，Linux下这个文件通常放在/etc/oraInst.loc，如果没有，可以手动生成，内容类似：

inventory_loc=/u01/weblogic/oraInventory inst_group=weblogic

静默安装的坑主要出在权限和路径。oraInventory目录如果没有写权限，安装程序会直接报错退出，日志里通常只有一句"Failed to create inventory"。所以安装前一定先确认的是，执行用户对/u01/weblogic全链路有读写权限。

3.3 安装完成后的目录结构详解

装完后你会看到类似这样的目录结构：

/u01/weblogic/install_home/ ├── domain-registry.xml ├── logs ├── oracle_common ├── oraInst.loc ├── uninstall ├── wlserver │ ├── common │ ├── integration │ ├── modules │ ├── server │ └── uninstall └── wlsdeploy

真正关键的是wlserver目录。这里藏着全套WebLogic运行时，包括startWebLogic.sh、WLST脚本库、默认模板文件。startWebLogic.sh是启动Domain的入口脚本，但注意它不在安装目录根下，而是在每个具体Domain的bin目录里。

安装包本身没有提供任何可运行的Server实例，装完只是搭好了"引擎"，必须进入下一步——创建Domain。

4. 创建Domain：比安装本身更容易出错的关键环节

WebLogic和Tomcat一个很大的区别是，它引入了Domain（域）的概念。简单理解，Domain就是一个独立的管理单元，包含一个AdminServer（管理服务器）和若干个ManagedServer（受管服务器）。所有配置都由AdminServer集中管理，应用可以部署到任意ManagedServer上。这个概念搞不清楚，后面集群配置、部署目标选择都会一头雾水。

4.1 用配置向导创建Domain

WebLogic安装包里自带Configuration Wizard。在图形环境里直接执行：

$ORACLE_HOME/oracle_common/common/bin/config.sh

向导会引导你选择或创建模板，填写管理员账号密码、Domain名称、端口号等信息。默认生成的AdminServer监听地址是0.0.0.0，端口7001。生产环境建议把监听地址改成具体IP，端口也改掉，减少被扫描到的概率。

有一点特别容易忽略：向导里会问你要不要创建"管理服务器启动后自动启动受管服务器"。在很多企业环境里，为了统一启停管理，会把这个选项设成"视情况手动启动"。如果你选中了自动启动，每次重启AdminServer时它会尝试拉起所有受管服务器，在资源不足的机器上反而会导致启动风暴。

4.2 用WLST脚本创建Domain，一劳永逸

如果让我选一种方式，我会选WLST（WebLogic Scripting Tool）。它支持脚本化创建Domain，一次编写，多套环境复现。对于要部署多套环境的项目来说，这不只是省事，更关键的是保证每套环境的配置完全一致。

下面这个脚本是我常用的，保存成create_domain.py执行：

# create_domain.py readTemplate('/u01/weblogic/install_home/wlserver/common/templates/wls/wls.jar') # 修改域名 set('Name', 'MyDomain') # 修改 AdminServer 监听地址和端口 cd('/Servers/AdminServer') set('ListenAddress', '0.0.0.0') set('ListenPort', 7001) # 修改 JVM 参数 cd('/Servers/AdminServer/ServerStart/MyDomain') set('Arguments', '-Xms2048m -Xmx2048m -XX:MaxPermSize=512m') # 设置管理员账号 cd('/Security/base_domain/User/weblogic') cmo.setPassword('YourStrongPassw0rd') # 写回并关闭模板 setOption('CreateStartMenu', 'false') setOption('ServerStartMode', 'prod') writeDomain('/u01/weblogic/domain/MyDomain') closeTemplate() exit()

执行命令：

$ORACLE_HOME/oracle_common/common/bin/wlst.sh create_domain.py

脚本里的ServerStartMode我建议设成prod。Developer模式下某些安全检查会放宽，生产环境必须用prod模式。

4.3 Domain目录结构：知道文件放哪才能准确排错

创建完成后，Domain目录是这个样子的：

启动Domain只需要执行：

cd /u01/weblogic/domain/MyDomain/bin ./startWebLogic.sh

启动成功后在浏览器访问http://IP:7001/console，就能看到WebLogic控制台登录页。

4.4 JVM参数配置不当会埋下定时炸弹

Domain创建时就要把JVM参数想清楚。AdminServer本身承担管理职责，内存给1-2GB足够；ManagedServer要跑业务应用，堆内存得根据应用实际负载来定。常见的一个配置误区是所有人都在setDomainEnv.sh里改USER_MEM_ARGS，但改完后又发现ManagedServer和AdminServer的JVM参数被一视同仁了。

我的做法是分别定义变量：

# setDomainEnv.sh 末尾追加 if [ "${SERVER_NAME}" = "AdminServer" ]; then USER_MEM_ARGS="-Xms1024m -Xmx1024m -XX:MaxMetaspaceSize=512m" elif [ "${SERVER_NAME}" = "ManagedServer_1" ]; then USER_MEM_ARGS="-Xms4096m -Xmx4096m -XX:MaxMetaspaceSize=1024m" fi export USER_MEM_ARGS

注意，12.2.1之后的版本默认使用JDK 8和元空间，MaxPermSize已经不再适用，设置无效还可能造成误导。10.3.6及更老的版本才需要MaxPermSize参数。

5. 应用部署的三种方式：控制台、Deployer命令行与WLST脚本

Domain创建好、AdminServer跑起来，接下来就是部署应用。很多教程只讲控制台点几下，但实际项目里自动化部署才是刚需。我把三种方式都走一遍，对比一下各自适合的场景和坑。

5.1 控制台部署：最直观但最不适合批量操作

登录控制台后，导航到"部署"页面，点击"安装"，选择WAR包或EAR包，然后按向导一步步完成。整个操作很简单，但有几个点容易出错：

第一，部署目标的选择。如果选了AdministrationServer，应用就只在AdminServer上跑，一般不建议这样。正确做法是选中业务项目的ManagedServer。第二，部署阶段选择。可以选择"将部署上载到管理服务器"或"将此部署作为生产模式暂存"。如果不理解这两个选项的差异，建议选择默认值，等跑熟了再改。第三，应用名称不能和已有部署冲突，否则控制台会让你强制覆盖，容易误操作。

控制台部署适合单机调试和临时上线，一旦涉及几十套环境，这种方式效率太低。

5.2 Deployer命令行：批量部署的利器

WebLogic自带了一个完善的部署工具：weblogic.Deployer。通过命令行调用，可以完成部署、更新、卸载、重部署等操作。基本用法如下：

java -cp $ORACLE_HOME/wlserver/server/lib/weblogic.jar weblogic.Deployer \ -adminurl t3://10.0.0.10:7001 \ -username weblogic \ -password 'YourPassword' \ -deploy \ -name order-service \ -targets ManagedServer_1 \ /u01/apps/order-service.war

各参数含义：-deploy表示执行部署操作，-name指定应用名，-targets指定目标服务器。执行成功后，命令行会返回Deployment completed successfully。

部署完成后再上线新的WAR包，不需要先undeploy再redeploy，直接用-redeploy即可：

java -cp $ORACLE_HOME/wlserver/server/lib/weblogic.jar weblogic.Deployer \ -adminurl t3://10.0.0.10:7001 \ -username weblogic \ -password 'YourPassword' \ -redeploy \ -name order-service \ -source /u01/apps/order-service.war

这里有个常见坑：直接使用-deploy部署一个同名应用会报"already exists"错误。所以自动化脚本里要先判断应用是否已存在，存在就-redeploy，不存在才-deploy。

5.3 WLST脚本化部署：把它嵌进CI/CD流程

比Deployer更进一步的是用WLST脚本做部署，好处是可以把连接、部署、健康检查、日志收集串成一个完整流程。下面是我常用的一段：

# deploy_app.py username = 'weblogic' password = 'YourPassword' url = 't3://10.0.0.10:7001' connect(username, password, url) deployment = 'order-service' app_path = '/u01/apps/order-service.war' targets = 'ManagedServer_1' if deploymentExists(deployment): print('Deployment exists, redeploying...') deploy(appName=deployment, path=app_path, targets=targets, stageMode='stage') else: print('Creating new deployment...') deploy(appName=deployment, path=app_path, targets=targets, stageMode='stage') disconnect() exit()

执行：

$ORACLE_HOME/oracle_common/common/bin/wlst.sh deploy_app.py

WLST里deploy函数如果检测到同名的应用不会直接覆盖，所以before执行时用deploymentExists做判断。stageMode='stage'表示将部署包复制到每个目标服务器的指定暂存目录，这种方式在网络传输上有一定开销，但能保证各节点文件一致性。还有一种external_stage模式，适用于从共享存储批量部署的场景，多节点集群下更省带宽。

5.4 部署完成后的健康检查清单

无论用哪种方式部署，完成后我都建议做一次系统验证：

• 查看部署状态，确认应用处于"活动"状态，而不是"准备就绪"或"失败"
• 使用curl -I http://IP:7001/order-service或访问一个真实的业务接口，确认HTTP返回200
• 查看ManagedServer的日志，确认没有类加载异常或者数据源连接失败的报错
• 如果应用有JMX暴露，顺手查一下内存和线程池指标

6. WebLogic安全加固：关于漏洞、默认账号和jks那点事

聊WebLogic绕不开安全问题。WebLogic历史上爆过的高危漏洞不少，被列为重点排查对象也不算冤。对这一块，我认为正确的态度不是回避，而是搞清楚它为什么会成为目标，然后踏踏实实做加固。

6.1 为什么WebLogic经常成为攻击目标

原因有两点：第一，WebLogic通常承载核心业务系统，价值高；第二，它的攻击面确实不小，既有基于HTTP的Web服务，也有基于T3和IIOP协议的远程调用入口。T3协议是WebLogic集群和各节点间通信的协议，但历史上多个反序列化漏洞都出在这个协议上。网上那些针对WebLogic的攻击工具，大多瞄准的是T3协议处理流程里的过滤缺陷。

攻击者要利用这些漏洞，在大多数场景下需要能直接访问7001端口或者T3端口。所以安全加固的核心思路就是：减少暴露面、升级修补漏洞、降低端口可访问性。

6.2 安全基线配置清单

结合这么多年的实操经验，下面这几项是我认为每个WebLogic服务器都必须落实的：

6.3 demoidentity.jks这个高频检查项

这些年WebLogic被扫出问题的记录里，demoidentity.jks出现频率非常高。这是WebLogic默认生成的一个身份密钥库，用于SSL握手和节点间通信。问题在于它的密码是公开的，默认密码是DemoIdentityKeyStore，很多系统上线后压根没改过。安全扫描工具一探测到这个文件的存在和默认密码，就直接判成高风险。

处理方法是用keytool重新生成一个密钥库，并把路径和密码更新到Domain配置里。大概流程如下：

keytool -genkeypair -alias demoidentity -keyalg RSA -keysize 2048 \ -dname "CN=weblogic-node, OU=IT, O=Company, L=City, ST=State, C=CN" \ -validity 3650 \ -keystore /u01/weblogic/domain/MyDomain/security/demoidentity.jks \ -storepass YourNewStrongPassword

生成后还需要在WebLogic控制台里更新SSL配置中的私钥别名和密码，否则重启后SSL相关操作会报错。做完这一步，再跑安全扫描就不会在这个点上被卡住。

6.4 补丁更新是最容易拖后腿的一环

安全加固方案定了，但真正落地的难点在补丁。Oracle的季度补丁更新需要企业账号才能下载，但即使拿到补丁，往生产环境上打也需要停机窗口。我见过不少团队把补丁更新一拖再拖，最后拖成了"上了新闻"的事件。

如果短期无法停机打补丁，至少在访问控制层面做好补救：在服务器前面加WAF或安全组白名单，限制T3协议来源IP，对WebLogic管理端口做强访问控制。这些措施不能根治漏洞，但能把实际风险降到可控范围。

注意：不要在WebLogic配置里留-Dcom.sun.management.jmxremote等远程管理参数，尤其不要监听非本地端口，否则等于开放了一个不需要认证的监控入口。

7. 运行时故障排查：我从实际项目里总结的排错清单

部署这件事，最花时间的环节往往不是安装和部署本身，而是部署完后的各种运行时问题。我把自己在项目里排查过的WebLogic故障做了个分类，挑了几个高频、有代表性的场景说下排查思路。

7.1 内存溢出：两种表现，两种对策

WebLogic的Java进程内存溢出分两种：堆内存溢出和元空间溢出。

堆内存溢出（OutOfMemoryError: Java heap space）的典型表现是应用响应越来越慢，最后直接无法处理请求，日志里频繁出现OutOfMemoryError。排查时先用jmap或jstat看堆使用曲线，如果发现GC频繁且回收不掉，再考虑是内存泄漏还是堆开小了。我遇到最多的情况其实是连接池缓存导致的对象无法回收，处理方式是，先压测定位泄漏点，然后增加堆内存，同时调大Xms和Xmx到一致，避免运行期动态扩缩带来的停顿。

元空间溢出在JDK 8及以后主要表现是OutOfMemoryError: Metaspace。排查时先看-XX:MaxMetaspaceSize是否给了足够空间。如果应用用了大量动态代理或者反射，元空间增长会很快。建议初始设置512MB以上，再通过监控曲线做调整。

7.2 启动失败：日志文件才是最好的线索

WebLogic启动失败时，第一反应不应该是去猜，而是看日志。AdminServer的启动日志在Domain/servers/AdminServer/logs下，关注三个文件：

一条典型的启动失败报错长这样：

JDK is incompatible with this version of WebLogic Server or the JVM mode is incorrect

看到这句话基本可以锁定JDK版本不匹配。还有一类报错是端口被占用：

BEA-000365: Server failed to listen on port 7001

排查方法是netstat或lsof看7001被谁占了，大概率是上一个Server进程没彻底杀死。WebLogic的进程是一组Java进程，杀的时候用kill -9之前先确认父进程和子进程都退出，否则会留下一堆僵死进程。

7.3 类加载冲突：NoSuchMethodError的元凶

WebLogic部署和Tomcat有一个明显的不同点：WebLogic的类加载体系更严格，父子委派的层级关系更复杂。应用里如果依赖了和WebLogic自带的第三方库（比如Log4j、Saxon、JAXP实现等）版本不一致的类，往往会出现NoSuchMethodError或者ClassCastException，而且报错位置千奇百怪。

排查思路是：在Domain的lib目录下检查是否有冲突的jar包，或者在应用的WEB-INF/lib里搜一下重复类。也可以用-Dweblogic.debug.DebugClassLoading=true开启类加载调试日志，启动时从日志里定位实际加载的jar来源。

我遇到过最典型的一个案例：应用里带了老版本的xercesImpl.jar，WebLogic自带的XML解析器版本更新，结果程序一跑就报XML解析错误。最后排除掉应用里的老jar，才恢复正常。这个经验让我养成了一个习惯：部署应用前先对比一下应用依赖和WebLogic自带模块的版本清单。

7.4 时区与编码问题：看似不起眼，影响很直接

WebLogic部署在Linux上时，时区默认跟随系统。如果系统的/etc/localtime没有配置成业务需要的时区，日志时间戳、数据库写入时间都可能偏差8小时。检查命令：

date -R

如果时区不对，要么改系统时区，要么在setDomainEnv.sh里给JVM加参数：

JAVA_OPTIONS="${JAVA_OPTIONS} -Duser.timezone=Asia/Shanghai" export JAVA_OPTIONS

编码问题同样隐蔽。WebLogic默认文件编码依赖操作系统的locale，如果系统locale是en_US.UTF-8而业务数据是GBK，控制台和日志里看到的中文就会变成乱码。建议启动参数里显式设置：

JAVA_OPTIONS="${JAVA_OPTIONS} -Dfile.encoding=UTF-8" export JAVA_OPTIONS

不要小看这两行参数，遇到过一次系统间乱码导致的对账不平，排查了两天才定位到是时区加编码的双重问题。

7.5 一个完整的排查过程示例

最后分享一个真实的排查案例。当时有个同事反馈，应用部署后首次访问很慢，大概要等30秒才有响应。查了一圈，数据库没问题，网络没问题，最后打开AdminServer日志，发现启动时有一条警告：

WARNING: Low Memory. The server will enter low memory state...

再一看，AdminServer和ManagedServer在同一台机器上，AdminServer把4GB堆用掉了2GB，ManagedServer启动时堆也只给了2GB，机器总内存8GB，OS还要留一部分，内存压力自然大。

解决方式是：给机器加到16GB，AdminServer堆降到1GB，ManagedServer堆调到4GB，并且在启动顺序上先启动ManagedServer。调整后首次访问慢的问题彻底消失。

这个案例很有代表性：很多WebLogic性能问题不是应用代码的问题，而是资源分配不合理导致的。

写在最后：关于WebLogic部署的几个长期习惯

部署WebLogic这件事，装一遍不算会，能在出了问题后快速定位才算真正掌握。我个人的经验是，从第一次部署开始就坚持做运维文档，把每套环境的版本、JDK路径、JVM参数、部署包清单、安全加固记录都写清楚。出问题时这份文档的价值无法估量。

平时做巡检时，也建议多关注这几个指标：堆内存使用率、GC频率、连接池活跃连接数、日志里WARN和ERROR的数量。WebLogic的控制台和JMX都能提供这些指标，不用额外装监控组件，先把基本功用起来。

如果这篇内容对你有些帮助，或者你部署时遇到了不一样的问题，欢迎在评论区聊聊具体报错现象。毕竟中间件这套东西，很多时候就是靠一条一条踩坑记录堆起来的经验。