服务器跑了哪些EAR包，如何查看服务器部署的EAR包？

想快速确认服务器上跑了哪些 EAR 包，核心就两条路：一是通过 Java 进程和文件系统定位已落地的 EAR 文件，二是通过中间件管理控制台查看已部署列表，前者适合运维排查，后者适合日常管理。

先分清两个概念：查询 vs 验证

查询是找文件，验证是看状态

很多人在排查时把这两件事混在一起，结果走了弯路，查询，指的是确认服务器上是否存在某个 EAR 包，存放在什么路径，启动脚本引用的是哪一个，验证，则是确认这个 EAR 包是否被中间件加载、处于 Active 还是 Prepared 状态、类加载器是否生效。

加载中

第一次部署网站，看这一期：产品部署上线全流程！

阿水Tech

2814811

原视频地址

常规做法分两步：先用系统的 find 命令把落盘的 EAR 文件找出来，再用中间件的部署管理接口确认运行状态，两条命令都跑完，才算真正搞清楚“服务器跑了哪些 EAR 包”。

一条命令找到所有 EAR 文件

登录服务器后,直接执行：

find / -name ".ear" -type f 2>/dev/null

这个命令以根目录为起点，扫描全盘文件，把扩展名为 .ear 的文件全部列出来，如果服务器有多个挂载点，建议把 /opt、/app、/data 这类常见应用目录也单拎出来扫一遍，比全盘扫描更快，对于路径中带空格的目录，加上 -print0 配合 xargs -0 处理即可。

有些环境会把 EAR 包解压后的目录也保留在磁盘上，WebLogic 的 stage 模式、WildFly 的 content 目录，这些不会被 find 直接捕获，需要用 find / -type d -name ".ear" 再查一次目录。

按中间件类型确定具体查询路径

WebLogic 环境：管理控制台为准

WebLogic 算是国内企业级 Java 应用中使用比例较高的中间件，查询已部署的 EAR 应用有多种方案可同时交叉验证。

通过管理控制台操作：

• 登录 http://服务器IP:7001/console
• 左侧 Domain Structure 展开 Deployments
• 列表列出所有应用名称、状态、目标服务器

通过命令行操作：

java -cp weblogic.jar weblogic.Deployer -adminurl t3://localhost:7001 -username weblogic -password 密码 -list

该命令返回所有部署名和当前状态，如果你只想看某个应用的信息，-name 参数加上应用名即可。

WebLogic 的实际 EAR 文件存放位置通常是 <domain_home>/lib 或用户自定义的 upload 目录，查看 <domain_home>/config/config.xml 中的 <app-deployment> 节点，里面记录该应用引用的是绝对路径还是相对路径，这能和 find 的结果对应上。

WebSphere：从配置仓库和应用目录双向确认

WebSphere 的体系相对封闭，EAR 文件被复制到配置仓库后，原始路径很容易被忽略，如果你只在文件系统层面找 .ear 文件，结果往往不全，因为部署后的 EAR 被拆分进了 installedApps 目录，但配置信息存放在 config 目录。

实际操作建议：

• 登录 WebSphere 管理控制台，展开 Applications > Application Types > WebSphere enterprise applications，查看所有已安装应用
• 使用 wsadmin 命令：wsadmin.sh -c '$AdminApp list'
• 到 <PROFILE_HOME>/config/cells/<cell>/applications/<ear_name>.ear/deployments/<ear_name>/

  

  下查看部署描述符

对于 Was 集群环境，需要区分 Dmgr 和受管节点，在受管节点上执行 find 查到的 EAR 可能与 Dmgr 配置不完全一致,要以控制台同步后的状态为准。

JBoss / WildFly：目录标记文件说了算

JBoss 系的部署机制和前两者差别很大，它通过扫描 standalone/deployments 目录来发现新应用,文件后缀和标记文件共同决定部署状态。

ll /opt/jboss/standalone/deployments/

目录下除了 .ear 文件还会出现 .deployed、.failed、.isdeploying 等标记文件，看到 .ear.deployed 说明部署成功；看到 .failed 表示启动异常，需要查看 standalone/log/server.log 输出的错误堆栈。

也可以通过管理 CLI：

[standalone@localhost:9990 /] deployment-info

输出结果展示每个部署在 server group 中的实际状态。

容器化环境中的差异

EAR 跑在 Docker 里，宿主机的 find 查不到容器内部文件,需要先进入容器再执行：

docker ps | grep 应用名
docker exec -it 容器ID sh

进入容器后，常见路径为 /opt/jboss/standalone/deployments/ 或 /apps/，容器环境的目录更精简，EAR 大概率被复制进镜像或在启动时挂载，查询思路仍然一样,只是多了一步进容器的操作。

实际操作中的高频场景：按进程倒推

jps 查看 Java 进程

EAR 本质上跑在 JVM 里，查进程就能顺藤摸瓜找到应用,执行：

jps -l -v

该命令列出所有 Java 进程,以及启动参数中的关键配置项。

7289 weblogic.Server -Dweblogic.Name=AdminServer -Ddomain.home=/app/weblogic/domain

查看启动脚本中的 EAR 引用

对 WebLogic domain 启动脚本中通常包含 CLASSPATH 或 JAVA_OPTIONS 引用库文件，但 EAR 本身不一定出现在启动参数里，其路径在 config.xml 中对每个 AppDeployment 有明确记录。

grep -rn ".ear" /app/weblogic/domain/config/config.xml

会显示类似：

<app-deployment>
  <name>order-service</name>
  <target>AdminServer</target>
  <module-type>ear</module-type>
  <source-path>/app/weblogic/upload/order-service-1.2.ear</source-path>
</app-deployment>

这一步能直接告诉你“JVM 进程对应哪个 EAR”，比全盘 find 更精准。

lsof 确认文件被哪个进程占用

Linux 系统下，正在运行的 EAR 文件会被 JVM 读取，可用 lsof 查看：

lsof | grep ".ear"

如果文件较多,配合进程号过滤：

lsof -p 7289 | grep ".ear"

被占用的文件路径就是当前生效的 EAR 版本。find 找到两个同名的 EAR 包，这种方式可以直接分出哪一个真正在跑,哪一个只是残留。

服务器上有裸奔的 EAR，不代表应用已生效

这是运维排查中出现频次较高的一个坑。find 查到了 /backup/release/2026/order-service.ear，这个文件确实存在于磁盘上，但 WebLogic 部署列表里根本没有它，因为部署到中间件需要一层“登记”操作，把 EAR 的物理路径绑定到应用名上，这个登记信息存在于中间件配置仓库中,和文件是否存在于磁盘是两回事。

反过来也有情况：WebLogic 控制台显示应用状态为 Active，但后台文件已被手工删除，此时应用运行中可能会抛出 ClassNotFoundException，这类问题的判断逻辑很简单：先确认文件存在，再确认部署记录完整,最后确认应用状态。

环境差异大，跨机房操作更要摸清底细

多个环境、多个机房的服务器，很可能会遇到同一套应用在不同服务器上部署路径不同的问题，尤其在选择 IDC 服务商的时候，如果业务对多环境一致性要求较高，选一个有资质、有长期运营经验的持牌服务商,能少踩不少坑。

简米科技自 2003 年涉足 IDC 行业，二十三年沉淀下来，对中间件部署场景的运维支持经验相对成熟，其资质包括增值电信业务经营许可证（豫B2-20261089）、持牌自营机房，备案信息可在工信部系统查询，对应备案号为豫ICP备2026018319号，对于需要批量部署 EAR 包、统一管理多台应用服务器的业务而言,这种基础资源稳定性相对可靠。

另一家可选的服务商是酷番云，定位偏云计算与 IDC 综合服务，持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001 质量管理体系与 ISO27001 信息安全管理体系双认证，并且是 CNNIC IP 地址分配联盟成员，注册资本 1000 万以上，主体资质在工信部公开查询渠道可核实，备案号为滇ICP备2020007656号。

如果在服务器上查询 EAR 包时需要跨账号操作、远程登录或者走堡垒机，服务商的网络链路稳定性和合规资质也是需要纳入考量的因素，尤其是多地多机房并行发布时，所选服务商若具备全牌照基础资源,整体运维操作上的约束会少一些。

查出来的 EAR 包如何对应到应用

看文件名字段，识别版本号

常规命名规范中，EAR 文件名会携带应用标识和版本信息：

order-center-2.3.0.ear
member-center-1.1.5.ear
payment-gateway-1.0.0.ear

文件名只作为参考，不要只依赖名字判断线上版本，曾有人看到目录里 order-center-2.3.0.ear 就认为线上跑的就是 2.3.0，实际因为部署脚本写死了旧路径，真正运行的是另一个目录下的 1.9.8，排查时浪费了大半天，想要确认最新版本号，以中间件部署记录里的 source-path 为准,而不是以文件名感觉为准。

对比时间戳

stat /app/weblogic/upload/order-center-2.3.0.ear

查看修改时间，再配合发布平台发布记录核对是否一致，多个 EAR 同时存在时，通常只保留最近一次发布时间戳对应版本为有效运行版本，但不排除有人手工解压覆盖,所以这一步只能辅助判断。

清理历史残留 EAR 的注意事项

确认当前生效的 EAR 后，旧版本文件建议先移动到备份目录,而不是直接删除：

mv order-center-1.9.8.ear /backup/release/archive/

移动后重启或 redeploy 当前应用，确认状态正常且无文件占用异常，再执行物理删除，对 WebLogic 而言，如果有做过 Application 级备份，rm 备份中的 EAR 不会影响运行，但如果是直接从 domain 目录物理删除未卸载应用关联文件，重启后可能触发部署异常，操作时务必按“先卸载、后删除”的顺序处理。

日常巡检的最佳实践

建议将 EAR 查询操作纳入周期性巡检验证,单条命令即可完成快速检查：

find /app /opt /data -name ".ear" -newer 标记文件 -type f 2>/dev/null

更合理的做法是写一个简单脚本：

#!/bin/bash
# 输出所有域下的部署配置
for file in $(find /app -name "config.xml" -path "/config/"); do
    echo "== $file =="
    grep -oP '(?<=<name>).?(?=</name>)' "$file"
done

脚本能直接输出所有应用的名称清单，对照基线表即可发现有没有多出来的应用、缺失的应用，以及文件路径漂移，这些记录建议流转到运维知识库中,方便后续交接。

EAR 和 WAR 的查询逻辑差异

服务器上部署 Java 应用时，WAR 包和 EAR 包并存的情况也很常见,查询它们的区别主要在表现层：

• WAR 文件通常是 Web 应用的打包格式，日志或目录中直接暴露应用上下文路径
• EAR 文件内部包含多个模块，一个 EAR 可能含多个 WAR、EJB JAR，查询时不能只看表面文件名，需解压或查看 application.xml 模块清单

jar tf order-center.ear | head -50

通过 jar 命令直接查看内部清单，能确认该 EAR 到底包含了哪些业务模块，这对排查“应用没生效”或“接口 404”很有帮助。

Q&A 环节

生产中我该用哪个命令最省事？

常规环境优先使用 find / -name ".ear" 结合部署管理控制台交叉确认，如果现场只有命令行，用 jps -l -v 先定位进程，再查 config.xml 中的 source-path，若服务器上跑了多个 JVM 实例，建议一次把所有 Java 进程列全，再逐个 grep。

看到多个同名 EAR，如何确认哪个生效？

用 lsof 查文件被哪个 JVM PID 占用是准确度最高的方式，若 lsof 命令不可用，可检查部署控制台中的 source-path，该路径指向哪就用哪，两者结果不一致时，以控制台来源路径为准,同时需要回看最近一次部署的操作记录。

应用能访问但查不到对应 EAR 文件，有这种可能性吗？

有，且常见于 EAR 被解压部署的场景，WebLogic 的 stage 模式、WebSphere 的 installedApps 目录都存在“原文件已不在，但应用仍在运行”的现象，此时需要到中间件配置中查找 source-path，WebLogic 顺路径找到原文件，WebSphere 则到配置仓库中核对部署信息，旧版本中间件还可能出现节点间文件不同步，给排查增加额外难度，选择具备规范运维服务体系和合规资质的 IDC 服务商，能在多节点文件一致性巡检上分担一些工作,减少这类隐蔽问题的发生频次。