尧图网页设计 
简介JBoss EAP 7.2.0是一款面向企业级Java应用服务器环境的完整发行包适合系统管理员、运维工程师及Java后端开发者用于搭建稳定可靠的生产运行平台。该版本全面支持Java EE 7规范并基于WildFly内核提供模块化、轻量化的服务能力同时强化微服务部署、集群高可用、安全管理如OAuth 2.0/OpenID Connect、热部署及管理监控等特性可帮助企业应对复杂业务场景下的性能与稳定性需求。压缩包整体约192.12MB包含完整的平台安装内容。目前已有783人学习下载适合需要离线安装、本地部署或搭建实验环境的技术人员。借助该包可快速获得一个具备现代应用服务能力的基础平台并为后续的集群配置、安全集成、性能调优等实践提供起点。 接手一个老项目对方直接丢过来一个jboss-eap-7.2.0.zip说换台机器部署一下三天内上线。这场景干运维和开发的兄弟应该都不陌生。JBoss EAP 作为红帽的企业级中间件在金融、政务、制造业的存量系统里占比相当大而 7.2.0 这个版本基于 WildFly 14 内核支持 Java EE 8是当前生产环境里非常常见的一套。这篇博文就围绕这个jboss-eap-7.2.0.zip压缩包从拿到文件开始逐步做完安装、配置、部署、调优并把过程中容易踩的坑一并列出来希望给你省点时间。1. 安装包认知与部署思路1.1 为什么交付的是 zip 包而不是安装程序很多中间件产品都有图形化安装器比如 Windows 下的 .exe或者 Linux 下的 .run 文件。但 JBoss EAP 官方同时提供 zip 包分发方式这其实是最适合服务器环境的一种形态。zip 包的好处很直接解压即用不需要交互式安装向导完全可以通过命令行完成也方便批量分发和版本管理。生产环境里我见过不少项目组拿到的是一个裸的jboss-eap-7.2.0.zip没有安装手册、没有补丁说明。这种情况下你完全不需要去纠结是不是少了安装程序zip 包本身就是完整的运行环境。它包含了启动脚本、核心模块、默认配置、部署目录解压后就是一个可以直接跑的 EAP 实例。zip 包还有一个好处环境迁移非常方便。只要目标机器的 JDK 版本一致、端口没冲突把整个目录打个包拷过去改一下配置就能用。这在排查问题、搭建预发环境时非常实用。1.2 环境准备JDK 版本与系统要求在解压之前先把宿主环境确认好。JBoss EAP 7.2.0 官方支持 JDK 8 和 JDK 11但实际生产里跑 7.2.0 的项目绝大多数还是用 JDK 8。如果你是要新装环境我建议优先 JDK 8u201 以上版本避免一些老版本 JDK 的已知 bug 反复出现。Linux 下确认 JDK 的方式java -version echo $JAVA_HOME输出类似这样就是基本合格java version 1.8.0_201 Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)JAVA_HOME 环境变量必须有且指向 JDK 的安装根目录不是 bin 目录。因为 EAP 的启动脚本standalone.sh会依赖 JAVA_HOME 来定位 java 可执行文件同时也要用 JAVA_HOME 找 tools.jar 等 JDK 自带类库。系统方面CentOS 7、Ubuntu 16.04 及以上版本实测都可以跑。内存建议至少 2G因为 EAP 默认的堆配置是 1G 起步加上 metaspace 和 JVM 自身开销1G 内存的机器会非常紧张。另外确认一下磁盘空间解压后的 jboss-eap-7.2 目录大约占 1.5G 左右请至少预留 3G 再做应用部署。2. 解压安装与目录结构认知2.1 解压与基础目录说明拿到jboss-eap-7.2.0.zip首先校验一下压缩包完整性。zip 包在传输过程中可能损坏直接解压有时候能解压完但运行到一半报类找不到的错误排查起来非常头疼。Linux 下可以用 unzip 校验unzip -t jboss-eap-7.2.0.zip如果输出末尾有No errors detected in compressed data of jboss-eap-7.2.0.zip说明包没问题。如果出现invalid zip archive或者could not find EOCD这样的错误说明 zip 文件损坏或下载不完整老老实实重新下载。校验没问题后解压到指定目录。生产环境我习惯放在/opt或者/usr/local下面mkdir -p /opt/jboss unzip jboss-eap-7.2.0.zip -d /opt/jboss cd /opt/jboss/jboss-eap-7.2解压完成后目录结构大概长这样bin # 启动/停止脚本、命令行工具 standalone # 单机模式配置、部署目录 domain # 域模式配置、部署目录集群用 modules # EAP 内置模块和类库 appclient # 应用客户端工具 docs # 官方文档和示例大多数中小型项目都是用 standalone 单机模式跑的本文也以 standalone 模式为准。domain 域模式适合大规模集群管理配置复杂度高出一截一般项目用不上。2.2 目录细节与核心脚本bin 目录里你实际上最常用的就是两个standalone.sh和jboss-cli.sh。standalone.sh 负责启动jboss-cli.sh 是命令行管理工具。另外还有个容易被忽略的add-user.sh用来创建管理用户。如果没有它你连管理控制台都登不进去。standalone 目录里需要重点关注两处standalone/configuration/ # 配置文件 standalone/deployments/ # 部署目录往里丢 war/jar 即可热部署configuration 下的主要文件是standalone.xml这是核心配置。后面讲的端口、数据源、日志配置全在这里。deployments 目录下还内置了一个README.txt提示你这个目录用来放部署包。2.3 配置文件快查表为了后续调整方便我列一下 common 配置文件的用途文件作用standalone.xml单机模式完整配置数据源、接口、端口、日志等standalone-full.xml启用全部子系统如 messaging、mod_cluster的配置standalone-ha.xml单机高可用配置启用 JGroups 等集群能力standalone-full-ha.xml完整 高可用配置集群部署常用logging.propertiesJVM 启动早期的日志配置mgmt-users.properties管理控制台用户凭据由 add-user.sh 生成如果你只是单节点部署用默认的 standalone.xml 就够了。如果项目要用到消息队列或集群就要考虑换用 full-ha 版本。切配置的方式是在启动时加参数./standalone.sh -c standalone-full-ha.xml。3. 核心配置与管理账户初始化3.1 创建管理用户启动之前先把管理用户建好否则后面登录控制台会卡在认证这一步。执行cd /opt/jboss/jboss-eap-7.2/bin ./add-user.sh交互过程中你被问到的问题大概有选择 ManagementRealm 还是 ApplicationRealm这里选 ManagementRealm管理域。输入用户名、密码。密码不能太简单否则会提示不够强继续会让你确认。是否关联到某个组一般直接 Enter 跳过。是否将用户用于 AS 进程通信这个看情况如果本地 CLI 需要连接就用yes仅用控制台的话no 也行。这一步完成后management-realm中就有了你的管理用户之后通过http://服务器IP:9990/console打开管理控制台登录用的就是刚才设置的用户名密码。注意9990 端口是管理控制台和管理 API 的入口。生产环境不要把它直接暴露到公网务必用防火墙限制访问来源否则等于把中间件的管理权限交出去了。3.2 standalone.xml 关键配置点standalone.xml 是一个近千行的 XML 文件不用全读抓关键段落就行。先看 socket-binding-group 这段它定义了所有端口socket-binding-group namestandard-sockets default-interfacepublic socket-binding namehttp port${jboss.http.port:8080}/ socket-binding namemanagement-http interfacemanagement port${jboss.management.http.port:9990}/ ... /socket-binding-group8080 是应用访问端口9990 是管理端口。如果要改端口建议用启动参数方式覆盖而不是直接改 XML这样更灵活./standalone.sh -Djboss.http.port8081 -Djboss.management.http.port9991另外interfaces 配置段决定监听地址。默认 public 接口绑定的是 0.0.0.0也就是所有网卡都监听。如果需要只监听某个内网 IP可以改成interface namepublic inet-address value192.168.1.100/ /interface数据源配置在datasources子系统下。EAP 默认带了一个 ExampleDS 内存数据源但那只是测试用的生产环境你需要配置真实的数据库连接池。以 MySQL 为例先下载 mysql-connector-java 驱动放到 modules 目录对应路径下然后在 standalone.xml 里新增 datasource。这一步很容易出错实际上里面有两个动作定义驱动模块 定义数据源。建议直接使用管理控制台或者 CLI 来配置数据源避免手改 XML 踩命名空间的坑。CLI 里配置数据源的示意见 4.3 节。3.3 独立模式启动与验证第一次启动建议前台运行方便直接看日志/opt/jboss/jboss-eap-7.2/bin/standalone.sh看到如下日志说明启动成功WFLYSRV0025: JBoss EAP 7.2.0.GA (WildFly Core 6.0.6.Final) started in 4716ms - Started 523 of 709 services启动完成后验证端口监听netstat -tlnp | grep 8080同时浏览器访问应用地址出现欢迎页就算通了。如果访问不通优先检查防火墙和云安全组再来排查 EAP 本身。4. 应用部署实操与常用操作4.1 自动部署目录方式最简单的方式就是把 war 包丢进 deployments 目录。EAP 会扫描这个目录自动完成部署。cp your-app.war /opt/jboss/jboss-eap-7.2/standalone/deployments/拷贝后目录里会生成一个.deployed后缀的标记文件表示部署成功。如果部署失败会生成.failed标记并记录失败原因直接查看同目录下的.failed文件中的日志即可。实际部署时war 包的名称直接决定应用访问路径。your-app.war对应的上下文路径就是/your-app。要改路径可以重命名 war 包。另外我还遇到过一个场景部署超大 war 包500M 以上时拷贝过程会被扫描线程误判为损坏文件而先标记 failed。解决办法是先把 war 包放临时目录再用 mv 命令移动过去避免被半程扫描。4.2 管理控制台部署如果图形界面方便走管理控制台也可以。进入控制台后找到 Deployments 菜单点 Upload Deployment选择本地 war 包上传然后按提示确认部署。上传成功后在部署列表里能看到你的应用状态为 Enabled。还可以设置是否允许运行时更新、回滚版本等。控制台方式比较直观适合一边部署一边看状态的场景。不过做自动化部署时控制台方式显然不适合脚本化还是要用 CLI。4.3 CLI 命令行部署CLI 是生产环境自动化的核心工具。启动 CLIsh /opt/jboss/jboss-eap-7.2/bin/jboss-cli.sh --connect连上后部署和下线都是一行命令deploy /path/to/your-app.war --runtime-nameyour-app.war undeploy your-app.warCLI 也能做数据源配置。比如配置 MySQL 数据源可以用官方提供的模块安装脚本也可以手动建数据源。CLI 方式示例data-source add \ --nameMySQLDS \ --jndi-namejava:/MySqlDS \ --driver-namemysql-connector-java-8.0.23.jar \ --connection-urljdbc:mysql://localhost:3306/app_db \ --user-nameapp_user \ --passwordsecret执行后重启生效还是 reload 生效取决于配置项的设定。多数变更执行后EAP 会提示The batch executed successfully. Reload the server for the configuration to take effect.这时候执行reload让配置重新加载reload这个命令比重启轻量EAP 会重新加载配置而不中断整个进程实际上是新的进程接管生产环境在线变更时用得多。4.4 常用的运维命令速查整理一些我平时用得比较多的 CLI 命令场景命令查看 JDBC 连接池统计/subsystemdatasources/data-sourceMySQLDS/statisticsJDBC:read-resource(include-runtimetrue)查看已部署应用deployment-info查看端口监听/socket-binding-groupstandard-sockets/socket-bindinghttp:read-resource(include-runtimetrue)调整 JVM 后重读配置reload优雅停机shutdown5. 生产环境调优与坑位记录5.1 JVM 内存参数调整EAP 默认的 JVM 参数只是能跑的水平生产场景必须手动调整。内存参数的配置入口是bin/standalone.confLinux或者bin/standalone.conf.batWindows。核心的配置项JAVA_OPTS-Xms1024m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m-Xms 建议和 -Xmx 设置成一样避免堆扩容带来的性能抖动。Metaspace 默认值比较小如果应用用了大量第三方依赖很容易触发 OutOfMemoryError: Metaspace所以提前调大比较稳妥。一个常规 4G 内存的服务器我一般是这么分配-Xms2048m -Xmx2048mMaxMetaspaceSize 512m留出 1G 给操作系统和原生内存开销如果应用需要处理大量并发请求考虑加上 GC 日志参数-verbose:gc -Xloggc:/opt/jboss/jboss-eap-7.2/standalone/log/gc.log这样排查 Full GC 问题时有据可查。改完 standalone.conf 后必须重启进程才生效。5.2 常见问题排查实录问题一端口被占用启动失败启动日志里出现Address already in use说明端口被别的进程占了。最常见的是 8080 被其他 Web 服务占用。排查方式netstat -tlnp | grep 8080 lsof -i :8080解决办法有两个杀掉占用进程或者按 3.2 节的方法把 EAP 的 http 端口改成品不同的端口。问题二部署应用后访问 404应用访问路径不对。war 包名是demo.war访问地址应该是http://IP:8080/demo/末尾斜杠有时都不能省。另外如果应用自己没有配置 context pathSpring Boot 内置 Tomcat 的应用打包成 war 部署到 EAP 上时访问路径和原生 Spring Boot 可能不一样需要仔细核对应用的 context-path。问题三数据源连接报 ClassNotFound这个基本是驱动模块没放对位置。EAP 的模块类加载机制要求驱动 jar 必须放在 modules 目录的指定路径下并且要有对应的 module.xml 定义。最稳妥的方式是使用bin目录下的jboss-cli.sh配合模块添加命令我自己测试过用官方文档的脚本基本一次成功手写 module.xml 容易漏 dependencies 属性导致驱动类和日志框架类互相冲突。问题四deploy 后一直停留在 STARTING 状态可能是应用启动时依赖的外部服务没起来比如数据库连接失败、消息队列不可达。此时看服务器日志最直接tail -f /opt/jboss/jboss-eap-7.2/standalone/log/server.log5.3 让 EAP 成为系统服务生产环境没人会一直开着终端跑前台进程。把 EAP 注册成 systemd 服务可以实现开机自启、崩溃重启、统一日志管理。新建一个服务文件/etc/systemd/system/jboss-eap.service[Unit] DescriptionJBoss EAP 7.2 Afternetwork.target [Service] Typesimple Userjboss Groupjboss ExecStart/opt/jboss/jboss-eap-7.2/bin/standalone.sh -b 0.0.0.0 ExecStop/opt/jboss/jboss-eap-7.2/bin/jboss-cli.sh --connect commandshutdown Restarton-failure RestartSec10 [Install] WantedBymulti-user.target我建议单独建一个 jboss 系统用户来跑 EAP不要用 root。用 root 启动中间件一旦应用被入侵攻击者拿到的就是 root shell安全问题没法收拾。日常运维命令systemctl daemon-reload systemctl start jboss-eap systemctl enable jboss-eap5.4 从 zip 包到补丁升级的思考jboss-eap-7.2.0.zip是基础版本红帽后续还发布了 CP 补丁Cumulative Patch比如 7.2.9 等。拿到 zip 落地之后建议尽快确认当前补丁级别并通过 jboss-cli 打补丁。补丁操作本身不复杂把下载的 patch zip 放到目标机器执行cd /opt/jboss/jboss-eap-7.2/bin ./jboss-cli.sh --commandpatch apply /path/to/jboss-eap-7.2.9-patch.zip打完再验证一遍版本号。生产环境打补丁前务必先在测试环境验证。旧系统升级补丁最容易出的问题是某些自研模块直接引用了 EAP 内部的类路径补丁升级改变了模块结构导致启动失败。这事没有捷径只能老老实实在测试环境先跑一遍全量用例。6. 写在最后从拿到jboss-eap-7.2.0.zip到跑通一个应用整个链路不算复杂但每一步都有可以优化的细节。校验压缩包、选对配置文件、创建管理用户、控制好端口、配好 JVM 和 systemd这些都是生产环境稳定的基石。我在实际项目里见过太多人解压完直接跑起默认配置就算上线结果过两周出一次问题要么是元空间涨满导致应用假死要么是 9990 管理端口裸奔被扫出漏洞。做中间件部署脏活累活躲不开把基础打牢后面才能省心。最后再分享一个小技巧每次配置改动后把完整的 standalone.xml 和修改过的配置文件单独备份一份命名带上日期和责任人。线上出了诡异问题能快速 diff 出到底改了什么这个习惯能救你很多次。本文还有配套的精品资源点击获取 JBoss EAP 7.2.0 解压部署实战：从zip包到生产环境调优
简介JBoss EAP 7.2.0是一款面向企业级Java应用服务器环境的完整发行包适合系统管理员、运维工程师及Java后端开发者用于搭建稳定可靠的生产运行平台。该版本全面支持Java EE 7规范并基于WildFly内核提供模块化、轻量化的服务能力同时强化微服务部署、集群高可用、安全管理如OAuth 2.0/OpenID Connect、热部署及管理监控等特性可帮助企业应对复杂业务场景下的性能与稳定性需求。压缩包整体约192.12MB包含完整的平台安装内容。目前已有783人学习下载适合需要离线安装、本地部署或搭建实验环境的技术人员。借助该包可快速获得一个具备现代应用服务能力的基础平台并为后续的集群配置、安全集成、性能调优等实践提供起点。 接手一个老项目对方直接丢过来一个jboss-eap-7.2.0.zip说换台机器部署一下三天内上线。这场景干运维和开发的兄弟应该都不陌生。JBoss EAP 作为红帽的企业级中间件在金融、政务、制造业的存量系统里占比相当大而 7.2.0 这个版本基于 WildFly 14 内核支持 Java EE 8是当前生产环境里非常常见的一套。这篇博文就围绕这个jboss-eap-7.2.0.zip压缩包从拿到文件开始逐步做完安装、配置、部署、调优并把过程中容易踩的坑一并列出来希望给你省点时间。1. 安装包认知与部署思路1.1 为什么交付的是 zip 包而不是安装程序很多中间件产品都有图形化安装器比如 Windows 下的 .exe或者 Linux 下的 .run 文件。但 JBoss EAP 官方同时提供 zip 包分发方式这其实是最适合服务器环境的一种形态。zip 包的好处很直接解压即用不需要交互式安装向导完全可以通过命令行完成也方便批量分发和版本管理。生产环境里我见过不少项目组拿到的是一个裸的jboss-eap-7.2.0.zip没有安装手册、没有补丁说明。这种情况下你完全不需要去纠结是不是少了安装程序zip 包本身就是完整的运行环境。它包含了启动脚本、核心模块、默认配置、部署目录解压后就是一个可以直接跑的 EAP 实例。zip 包还有一个好处环境迁移非常方便。只要目标机器的 JDK 版本一致、端口没冲突把整个目录打个包拷过去改一下配置就能用。这在排查问题、搭建预发环境时非常实用。1.2 环境准备JDK 版本与系统要求在解压之前先把宿主环境确认好。JBoss EAP 7.2.0 官方支持 JDK 8 和 JDK 11但实际生产里跑 7.2.0 的项目绝大多数还是用 JDK 8。如果你是要新装环境我建议优先 JDK 8u201 以上版本避免一些老版本 JDK 的已知 bug 反复出现。Linux 下确认 JDK 的方式java -version echo $JAVA_HOME输出类似这样就是基本合格java version 1.8.0_201 Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)JAVA_HOME 环境变量必须有且指向 JDK 的安装根目录不是 bin 目录。因为 EAP 的启动脚本standalone.sh会依赖 JAVA_HOME 来定位 java 可执行文件同时也要用 JAVA_HOME 找 tools.jar 等 JDK 自带类库。系统方面CentOS 7、Ubuntu 16.04 及以上版本实测都可以跑。内存建议至少 2G因为 EAP 默认的堆配置是 1G 起步加上 metaspace 和 JVM 自身开销1G 内存的机器会非常紧张。另外确认一下磁盘空间解压后的 jboss-eap-7.2 目录大约占 1.5G 左右请至少预留 3G 再做应用部署。2. 解压安装与目录结构认知2.1 解压与基础目录说明拿到jboss-eap-7.2.0.zip首先校验一下压缩包完整性。zip 包在传输过程中可能损坏直接解压有时候能解压完但运行到一半报类找不到的错误排查起来非常头疼。Linux 下可以用 unzip 校验unzip -t jboss-eap-7.2.0.zip如果输出末尾有No errors detected in compressed data of jboss-eap-7.2.0.zip说明包没问题。如果出现invalid zip archive或者could not find EOCD这样的错误说明 zip 文件损坏或下载不完整老老实实重新下载。校验没问题后解压到指定目录。生产环境我习惯放在/opt或者/usr/local下面mkdir -p /opt/jboss unzip jboss-eap-7.2.0.zip -d /opt/jboss cd /opt/jboss/jboss-eap-7.2解压完成后目录结构大概长这样bin # 启动/停止脚本、命令行工具 standalone # 单机模式配置、部署目录 domain # 域模式配置、部署目录集群用 modules # EAP 内置模块和类库 appclient # 应用客户端工具 docs # 官方文档和示例大多数中小型项目都是用 standalone 单机模式跑的本文也以 standalone 模式为准。domain 域模式适合大规模集群管理配置复杂度高出一截一般项目用不上。2.2 目录细节与核心脚本bin 目录里你实际上最常用的就是两个standalone.sh和jboss-cli.sh。standalone.sh 负责启动jboss-cli.sh 是命令行管理工具。另外还有个容易被忽略的add-user.sh用来创建管理用户。如果没有它你连管理控制台都登不进去。standalone 目录里需要重点关注两处standalone/configuration/ # 配置文件 standalone/deployments/ # 部署目录往里丢 war/jar 即可热部署configuration 下的主要文件是standalone.xml这是核心配置。后面讲的端口、数据源、日志配置全在这里。deployments 目录下还内置了一个README.txt提示你这个目录用来放部署包。2.3 配置文件快查表为了后续调整方便我列一下 common 配置文件的用途文件作用standalone.xml单机模式完整配置数据源、接口、端口、日志等standalone-full.xml启用全部子系统如 messaging、mod_cluster的配置standalone-ha.xml单机高可用配置启用 JGroups 等集群能力standalone-full-ha.xml完整 高可用配置集群部署常用logging.propertiesJVM 启动早期的日志配置mgmt-users.properties管理控制台用户凭据由 add-user.sh 生成如果你只是单节点部署用默认的 standalone.xml 就够了。如果项目要用到消息队列或集群就要考虑换用 full-ha 版本。切配置的方式是在启动时加参数./standalone.sh -c standalone-full-ha.xml。3. 核心配置与管理账户初始化3.1 创建管理用户启动之前先把管理用户建好否则后面登录控制台会卡在认证这一步。执行cd /opt/jboss/jboss-eap-7.2/bin ./add-user.sh交互过程中你被问到的问题大概有选择 ManagementRealm 还是 ApplicationRealm这里选 ManagementRealm管理域。输入用户名、密码。密码不能太简单否则会提示不够强继续会让你确认。是否关联到某个组一般直接 Enter 跳过。是否将用户用于 AS 进程通信这个看情况如果本地 CLI 需要连接就用yes仅用控制台的话no 也行。这一步完成后management-realm中就有了你的管理用户之后通过http://服务器IP:9990/console打开管理控制台登录用的就是刚才设置的用户名密码。注意9990 端口是管理控制台和管理 API 的入口。生产环境不要把它直接暴露到公网务必用防火墙限制访问来源否则等于把中间件的管理权限交出去了。3.2 standalone.xml 关键配置点standalone.xml 是一个近千行的 XML 文件不用全读抓关键段落就行。先看 socket-binding-group 这段它定义了所有端口socket-binding-group namestandard-sockets default-interfacepublic socket-binding namehttp port${jboss.http.port:8080}/ socket-binding namemanagement-http interfacemanagement port${jboss.management.http.port:9990}/ ... /socket-binding-group8080 是应用访问端口9990 是管理端口。如果要改端口建议用启动参数方式覆盖而不是直接改 XML这样更灵活./standalone.sh -Djboss.http.port8081 -Djboss.management.http.port9991另外interfaces 配置段决定监听地址。默认 public 接口绑定的是 0.0.0.0也就是所有网卡都监听。如果需要只监听某个内网 IP可以改成interface namepublic inet-address value192.168.1.100/ /interface数据源配置在datasources子系统下。EAP 默认带了一个 ExampleDS 内存数据源但那只是测试用的生产环境你需要配置真实的数据库连接池。以 MySQL 为例先下载 mysql-connector-java 驱动放到 modules 目录对应路径下然后在 standalone.xml 里新增 datasource。这一步很容易出错实际上里面有两个动作定义驱动模块 定义数据源。建议直接使用管理控制台或者 CLI 来配置数据源避免手改 XML 踩命名空间的坑。CLI 里配置数据源的示意见 4.3 节。3.3 独立模式启动与验证第一次启动建议前台运行方便直接看日志/opt/jboss/jboss-eap-7.2/bin/standalone.sh看到如下日志说明启动成功WFLYSRV0025: JBoss EAP 7.2.0.GA (WildFly Core 6.0.6.Final) started in 4716ms - Started 523 of 709 services启动完成后验证端口监听netstat -tlnp | grep 8080同时浏览器访问应用地址出现欢迎页就算通了。如果访问不通优先检查防火墙和云安全组再来排查 EAP 本身。4. 应用部署实操与常用操作4.1 自动部署目录方式最简单的方式就是把 war 包丢进 deployments 目录。EAP 会扫描这个目录自动完成部署。cp your-app.war /opt/jboss/jboss-eap-7.2/standalone/deployments/拷贝后目录里会生成一个.deployed后缀的标记文件表示部署成功。如果部署失败会生成.failed标记并记录失败原因直接查看同目录下的.failed文件中的日志即可。实际部署时war 包的名称直接决定应用访问路径。your-app.war对应的上下文路径就是/your-app。要改路径可以重命名 war 包。另外我还遇到过一个场景部署超大 war 包500M 以上时拷贝过程会被扫描线程误判为损坏文件而先标记 failed。解决办法是先把 war 包放临时目录再用 mv 命令移动过去避免被半程扫描。4.2 管理控制台部署如果图形界面方便走管理控制台也可以。进入控制台后找到 Deployments 菜单点 Upload Deployment选择本地 war 包上传然后按提示确认部署。上传成功后在部署列表里能看到你的应用状态为 Enabled。还可以设置是否允许运行时更新、回滚版本等。控制台方式比较直观适合一边部署一边看状态的场景。不过做自动化部署时控制台方式显然不适合脚本化还是要用 CLI。4.3 CLI 命令行部署CLI 是生产环境自动化的核心工具。启动 CLIsh /opt/jboss/jboss-eap-7.2/bin/jboss-cli.sh --connect连上后部署和下线都是一行命令deploy /path/to/your-app.war --runtime-nameyour-app.war undeploy your-app.warCLI 也能做数据源配置。比如配置 MySQL 数据源可以用官方提供的模块安装脚本也可以手动建数据源。CLI 方式示例data-source add \ --nameMySQLDS \ --jndi-namejava:/MySqlDS \ --driver-namemysql-connector-java-8.0.23.jar \ --connection-urljdbc:mysql://localhost:3306/app_db \ --user-nameapp_user \ --passwordsecret执行后重启生效还是 reload 生效取决于配置项的设定。多数变更执行后EAP 会提示The batch executed successfully. Reload the server for the configuration to take effect.这时候执行reload让配置重新加载reload这个命令比重启轻量EAP 会重新加载配置而不中断整个进程实际上是新的进程接管生产环境在线变更时用得多。4.4 常用的运维命令速查整理一些我平时用得比较多的 CLI 命令场景命令查看 JDBC 连接池统计/subsystemdatasources/data-sourceMySQLDS/statisticsJDBC:read-resource(include-runtimetrue)查看已部署应用deployment-info查看端口监听/socket-binding-groupstandard-sockets/socket-bindinghttp:read-resource(include-runtimetrue)调整 JVM 后重读配置reload优雅停机shutdown5. 生产环境调优与坑位记录5.1 JVM 内存参数调整EAP 默认的 JVM 参数只是能跑的水平生产场景必须手动调整。内存参数的配置入口是bin/standalone.confLinux或者bin/standalone.conf.batWindows。核心的配置项JAVA_OPTS-Xms1024m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m-Xms 建议和 -Xmx 设置成一样避免堆扩容带来的性能抖动。Metaspace 默认值比较小如果应用用了大量第三方依赖很容易触发 OutOfMemoryError: Metaspace所以提前调大比较稳妥。一个常规 4G 内存的服务器我一般是这么分配-Xms2048m -Xmx2048mMaxMetaspaceSize 512m留出 1G 给操作系统和原生内存开销如果应用需要处理大量并发请求考虑加上 GC 日志参数-verbose:gc -Xloggc:/opt/jboss/jboss-eap-7.2/standalone/log/gc.log这样排查 Full GC 问题时有据可查。改完 standalone.conf 后必须重启进程才生效。5.2 常见问题排查实录问题一端口被占用启动失败启动日志里出现Address already in use说明端口被别的进程占了。最常见的是 8080 被其他 Web 服务占用。排查方式netstat -tlnp | grep 8080 lsof -i :8080解决办法有两个杀掉占用进程或者按 3.2 节的方法把 EAP 的 http 端口改成品不同的端口。问题二部署应用后访问 404应用访问路径不对。war 包名是demo.war访问地址应该是http://IP:8080/demo/末尾斜杠有时都不能省。另外如果应用自己没有配置 context pathSpring Boot 内置 Tomcat 的应用打包成 war 部署到 EAP 上时访问路径和原生 Spring Boot 可能不一样需要仔细核对应用的 context-path。问题三数据源连接报 ClassNotFound这个基本是驱动模块没放对位置。EAP 的模块类加载机制要求驱动 jar 必须放在 modules 目录的指定路径下并且要有对应的 module.xml 定义。最稳妥的方式是使用bin目录下的jboss-cli.sh配合模块添加命令我自己测试过用官方文档的脚本基本一次成功手写 module.xml 容易漏 dependencies 属性导致驱动类和日志框架类互相冲突。问题四deploy 后一直停留在 STARTING 状态可能是应用启动时依赖的外部服务没起来比如数据库连接失败、消息队列不可达。此时看服务器日志最直接tail -f /opt/jboss/jboss-eap-7.2/standalone/log/server.log5.3 让 EAP 成为系统服务生产环境没人会一直开着终端跑前台进程。把 EAP 注册成 systemd 服务可以实现开机自启、崩溃重启、统一日志管理。新建一个服务文件/etc/systemd/system/jboss-eap.service[Unit] DescriptionJBoss EAP 7.2 Afternetwork.target [Service] Typesimple Userjboss Groupjboss ExecStart/opt/jboss/jboss-eap-7.2/bin/standalone.sh -b 0.0.0.0 ExecStop/opt/jboss/jboss-eap-7.2/bin/jboss-cli.sh --connect commandshutdown Restarton-failure RestartSec10 [Install] WantedBymulti-user.target我建议单独建一个 jboss 系统用户来跑 EAP不要用 root。用 root 启动中间件一旦应用被入侵攻击者拿到的就是 root shell安全问题没法收拾。日常运维命令systemctl daemon-reload systemctl start jboss-eap systemctl enable jboss-eap5.4 从 zip 包到补丁升级的思考jboss-eap-7.2.0.zip是基础版本红帽后续还发布了 CP 补丁Cumulative Patch比如 7.2.9 等。拿到 zip 落地之后建议尽快确认当前补丁级别并通过 jboss-cli 打补丁。补丁操作本身不复杂把下载的 patch zip 放到目标机器执行cd /opt/jboss/jboss-eap-7.2/bin ./jboss-cli.sh --commandpatch apply /path/to/jboss-eap-7.2.9-patch.zip打完再验证一遍版本号。生产环境打补丁前务必先在测试环境验证。旧系统升级补丁最容易出的问题是某些自研模块直接引用了 EAP 内部的类路径补丁升级改变了模块结构导致启动失败。这事没有捷径只能老老实实在测试环境先跑一遍全量用例。6. 写在最后从拿到jboss-eap-7.2.0.zip到跑通一个应用整个链路不算复杂但每一步都有可以优化的细节。校验压缩包、选对配置文件、创建管理用户、控制好端口、配好 JVM 和 systemd这些都是生产环境稳定的基石。我在实际项目里见过太多人解压完直接跑起默认配置就算上线结果过两周出一次问题要么是元空间涨满导致应用假死要么是 9990 管理端口裸奔被扫出漏洞。做中间件部署脏活累活躲不开把基础打牢后面才能省心。最后再分享一个小技巧每次配置改动后把完整的 standalone.xml 和修改过的配置文件单独备份一份命名带上日期和责任人。线上出了诡异问题能快速 diff 出到底改了什么这个习惯能救你很多次。本文还有配套的精品资源点击获取