简介JBoss EAP 7.1.0是一套由Red Hat维护的企业级Java应用服务器基于WildFly提供Java EE 7规范支持面向需要构建、部署与管理复杂企业应用的后端开发、架构及运维人员。该版本内置模块化类加载机制、RBAC安全控制、SSL/TLS、SOAP/REST Web服务、JPA/JTA数据访问、HornetQ消息中间件、集群负载均衡与故障转移等能力并提供了图形化管理控制台与CLI工具便于配置部署、监控与热更新也适合作为微服务和DevOps流水线的底层运行平台。资源以zip压缩包形式提供整体约175.28MB页面未提供具体文件总数和类型明细实际内容应包含JBoss EAP 7.1.0发行包及相关部署素材。目前已有897人学习下载适合希望离线搭建企业级中间件环境、快速掌握EAP配置思路或完成本地开发环境准备的Java技术人群。1. 项目概述EAP 7.1.0 到底是什么1.1 版本背景与关键组件如果你在公司里做过 Java 后端开发一定对 JBoss 这个老牌应用服务器不陌生。EAP 是 Red Hat 企业级产品线里的应用服务器全称 Enterprise Application Platform7.1.0 是 7.x 系列里一个相当关键的迭代版本。很多刚接触这个版本的人会把它和 WildFly 混为一谈这里先厘清一个基本事实JBoss EAP 7.1.0 基于 WildFly 11Red Hat 在 WildFly 的基础上做了大量裁剪、加固和兼容性验证去掉了很多实验性功能换来了生产环境可用的稳定性。这一版最核心的技术变化有三个方向Java EE 8 规范支持虽然 7.1.0 没有把 Java EE 8 全部规范都落地但 Servlet 4.0、JAX-RS 2.1、CDI 2.0、Bean Validation 2.0 这些主流规范都已经支持对大多数企业应用来说够用了。Eclipse MicroProfile 1.2 技术预览这是 EAP 7.1 在微服务方向上的一次尝试把配置、健康检查、容错、指标等 API 集成到应用服务器内部。Elytron 安全框架技术预览Elytron 是 Red Hat 后续版本主推的安全架构7.1.0 里算第一次正式露面虽然默认还是走传统安全域但可以开始接触了。除了这些底层组件也有明显升级Hibernate 5.1.x 做持久层、Infinispan 8.2 做缓存、ActiveMQ Artemis 做消息中间件。如果你用过 EAP 6会明显感觉 7.1.0 的启动速度快了一大截内存占用也下降不少这主要归功于 Undertow 替代了原来的 Web 容器以及模块化类加载机制的优化。1.2 为什么 2025 年了还要聊这个版本有人会问EAP 都出到 8.x 了7.1.0 已经是很老的版本聊它还有什么意义这里得说句实话国内很多银行、保险、政企、制造业的核心系统至今还在 EAP 7.1.0 上跑着。原因无非几个系统稳定不想动、迁移成本高、内部技术栈绑定太深。所以如果你想接手这些老系统或者参与中间件运维工作EAP 7.1.0 是你躲不开的一个坎。另外EAP 7.1.0 的很多配置思路、CLI 命令、部署方式在 7.2、7.3、7.4 里面依然沿用甚至到了 EAP 8 也没有根本性变化。学好这个版本等于掌握了 JBoss 这条产品线的基本功后面升级版本只是增量学习的问题。这篇文章主要面向三类人刚接手 EAP 7.1.0 的运维/开发人员、准备从 WebLogic/WebSphere 迁移过来的团队以及想搞懂应用服务器内部工作原理的后端工程师。2. 环境准备与安装要点2.1 下载安装与目录结构EAP 7.1.0 的安装过程并不复杂Red Hat 官方提供两种方式一种是 ZIP 包解压安装另一种是 RPM 或安装程序安装。实际生产环境我推荐 ZIP 方式理由有两点第一解压即用目录结构透明方便排查问题第二可控性强方便做多版本并存和快速回滚。我一般把压缩包解压到/opt/jboss-eap-7.1然后设置环境变量export JBOSS_HOME/opt/jboss-eap-7.1 export PATH$PATH:$JBOSS_HOME/bin解压完成后的目录结构里有几个核心目录需要先认识目录作用备注standalone/单机模式配置、部署、日志目录生产环境最常见domain/域模式配置、部署、日志目录多机管理时使用bin/启动脚本、CLI 脚本、工具脚本日常操作都在这里modules/模块化类加载目录所有依赖组件都在这里docs/官方文档和样例配置排查配置问题时值得翻坦白说我对第一次接触 EAP 的同学有个建议先别急着看 domain 模式把你的精力集中在 standalone 模式上。绝大多数中大型项目一台机器一个实例作为独立节点就够了domain 模式虽然听起来可以统一管理多台机器但配置复杂度和排障难度直接上升一个量级没有专业运维团队撑着很容易踩坑。2.2 启动方式standalone 与 domain 如何取舍启动单机模式很简单bin/standalone.sh默认后台运行方式会带一个-b 0.0.0.0参数表示监听所有网卡生产环境千万别这么干最好通过配置文件或者启动参数显式指定内网 IPbin/standalone.sh -Djboss.bind.address192.168.1.10 -Djboss.bind.address.management192.168.1.10这里两个地址要区分开jboss.bind.address是业务端口监听地址jboss.bind.address.management是管理控制台和原生管理接口的监听地址。常规做法是管理地址只监听内网或跳板机不直接暴露到业务网络。启动完成后默认端口是 8080HTTP、9990管理控制台/管理接口、8443HTTPS 如果有配置。默认配置是standalone.xml另外还有standalone-full.xml带全部子系统和standalone-ha.xml带高可用和集群功能做集群测试可以直接指定bin/standalone.sh --server-configstandalone-ha.xml3. 核心配置与实操细节3.1 管理 CLI 的高频操作EAP 的管理方式主要有三种Web 管理控制台、原生管理接口 CLI、配置文件手工修改。我个人强烈推荐 CLI因为脚本化、可审计、能复现Web 控制台更适合快速查看状态或者在图形界面里做一些临时调整。CLI 的启动和连接方式bin/jboss-cli.sh --connect连接成功后你可以执行很多日常操作。比如查看当前运行状态:read-attribute(nameserver-state)结果会返回running表示服务器正常。查看所有部署的应用deployment-info查看端口是否正常占用这个在用脚本做健康检查时很管用/socket-binding-groupstandard-sockets/socket-bindinghttp/:read-attribute(namebound-address)CLI 的一个好处是支持 tab 补全命令写一半按 tab 就能自动补全不用去死记硬背所有路径。另一个好处是支持batch模式比如批量创建数据源和子系统配置可以把所有命令写在一个 batch 里最后统一执行这一步在生产环境变更时特别重要能减少中间状态产生的不一致风险。3.2 数据源配置的完整流程数据源配置是 EAP 生产环境里最常见的操作几乎每个业务系统都要连数据库。EAP 7.1.0 里数据源的配置逻辑是先装驱动再建数据源最后测试连接。以连接 MySQL 为例第一步需要安装 MySQL 驱动。EAP 的类加载是模块化的不能随手把 jar 丢到 classpath 里必须把驱动做成一个 module或者用 deploy 方式部署一个 driver 包。我习惯用 module 方式因为这样驱动和应用解耦也方便多应用共享cd $JBOSS_HOME/modules/system/layers/base/com/mysql/main/ cp mysql-connector-java-5.1.49.jar ./ vi module.xmlmodule.xml 内容示例如下?xml version1.0 encodingUTF-8? module xmlnsurn:jboss:module:1.5 namecom.mysql resources resource-root pathmysql-connector-java-5.1.49.jar/ /resources dependencies module namejavax.api/ module namejavax.transaction.api/ /dependencies /module创建完 module 之后通过 CLI 注册驱动并创建数据源driver add --namemysql --driver-module-namecom.mysql --driver-class-namecom.mysql.jdbc.Driver >tail -f standalone/log/server.logEAP 的日志默认按天滚动开发测试时可以直接看 server.log生产环境建议把server.log的 level 设置为 INFO 以上避免日志量过大。日志文件路径默认在standalone/log/下这个目录也是排查问题第一时间要看的。4. 生产环境常见问题与排查4.1 诡异报错实录先记录一次我实际踩过的坑。某业务系统在 EAP 7.1.0 上部署正常但一调用某个接口就报错错误信息类似ClassNotFoundException: com.example.common.util.JsonUtil。一开始我以为只是简单的缺 jar 包但检查了应用的lib目录类明明在里面。问题出在 EAP 的模块化类加载机制上。EAP 默认每个部署单元是独立 classloader虽然能看到应用自己的类但跨部署或者和容器自带类库之间有冲突时行为会变得很隐蔽。最后定位发现是应用里引入了 Hadoop 的客户端 jar里面带了老版本的javax.xml.bind类和 EAP 7.1.0 自带的 Jakarta XML Binding 实现产生了冲突。这种类冲突问题在 EAP 上很常见排查思路一般分三步看具体报错的类在哪个 jar 里用jar tvf xxx.jar | grep ClassName查看。看应用里是否包含多个相同package路径的 jar或者同一个 jar 的多个旧版本。用-Djboss.modules.system.pkgsorg.jboss.logmanager这类参数调试类加载或者干脆用 jboss-deployment-structure.xml 把冲突的依赖排除掉。4.2 性能与内存排查技巧EAP 7.1.0 在默认参数下并不适合生产高并发场景需要根据业务量调 JVM。我一般通过bin/standalone.conf修改 JVM 参数Linux 下实际生效的是JAVA_OPTS变量。我常用的初始配置如下JAVA_OPTS-Xms4g -Xmx4g -XX:MetaspaceSize512m -XX:MaxMetaspaceSize512m -XX:UseG1GC -XX:MaxGCPauseMillis200这里特别注意-Xms和-Xmx建议设成相同值避免 JVM 动态扩容带来的性能抖动。Metaspace 大小也别给太小EAP 模块化加载类很多如果MaxMetaspaceSize不够会出现OutOfMemoryError: Metaspace而且这种错误经常在频繁重部署应用时才暴露出来。还有一个容易被忽略的问题线程池配置。EAP 的 Undertow 默认 worker 线程数会按 CPU 核心数计算但实际业务里如果涉及大量阻塞 IO比如远程调用第三方接口默认线程池容易被占满。可以在 CLI 里调整/subsystemundertow/serverdefault-server/http-listenerdefault:write-attribute(namemax-post-size, value104857600)这个max-post-size是限制请求体重上限的默认约 10MB如果业务要上传大文件不调大会直接报 413。类似这样的参数很多动手前先翻一下文档或者用:read-resource-description看看有哪些属性可以设置。症状可能原因排查方向接口响应慢线程池满、数据库连接池打满看jstack、数据源统计定时任务不执行EJB 定时器持久化后状态异常检查standalone/data/timer-service-data应用启动报端口冲突8080 或 9990 被占用lsof -i:8080改端口或杀进程偶发 503Undertow 线程池耗尽调大 worker 线程数优化阻塞代码内存持续上涨本地缓存未过期、Session 未回收用 JConsole 连接查看堆占用检查 Infinispan 缓存配置4.3 高可用与集群配置的经验如果你要做集群EAP 7.1.0 的配置核心在于standalone-ha.xml和domain.xml里的ha配置。集群模式下应用 Session 默认没有开启分布式缓存需要显式配置web子系统的分布式 Session 管理和 Infinispan 缓存容器。一个典型配置是通过 CLI 启用 Session 复制/subsysteminfinispan/cache-containerweb:add() /subsysteminfinispan/cache-containerweb/distributed-cachedist:add()然后还要配置 JGroups 的协议栈EAP 默认是udp组播方式不过很多云环境下组播不通必须改成 TCP Gossip 或 KUBE_PING 这类协议。这块我自己的经验是如果你在 Kubernetes 里跑 EAP 集群提前研究下KUBE_PING别上来就配组播否则在云环境里会折腾到怀疑人生。5. 从迁移视角看 EAP 7.1.05.1 从 EAP 6 / WildFly 8-10 迁移EAP 6 到 EAP 7 是一个大的架构调整不只是升级版本号那么简单。核心变化包括Web 容器从 JBoss Web 换成了 Undertow事务子系统从 Bitronix 换成了 Narayana消息中间件从 HornetQ 换成了 ActiveMQ Artemis。这意味着很多在 EAP 6 上配置过的 JMS 队列、连接工厂配置在 7.1 里都是翻天覆地的变化。如果你的项目正在做这种升级我给一个比较稳妥的路径先把应用代码从 Java EE 6 规范升级到 Java EE 7/8尤其是 EJB 和 JPA 相关的 API 变化。用一个干净的 EAP 7.1.0 环境部署原应用让报错暴露出来逐个解决。对照standalone.xml新老差异手工迁移数据源、队列、安全域等自定义配置。重点测试 JMS 和事务嵌套的场景这些最容易出问题。举个例子EAP 6 里配置 JMS 队列通常要在messaging子系统的jms-destinations节点加配置EAP 7.1.0 里则换成messaging-activemq子系统通过添加 JMS Queue 资源完成。同一个业务配置路径完全不同文档如果没有及时更新排查起来效率极低。5.2 微服务与轻量化部署场景EAP 7.1.0 对微服务场景并不是完全不适配但你需要做一些取舍。MicroProfile 1.2 的技术预览让你可以用它跑起一个小型 REST 服务并拥有配置、健康检查等能力。如果团队不想引入 Spring Boot又想要 Java EE 的成熟生态把 EAP 当作一个轻量级服务运行平台是可行的。不过说实话如果是新项目且没有历史包袱我建议直接用 WildFly 最新版或 Quarkus这类框架在启动速度和内存占用上比 EAP 7.1.0 优秀太多。EAP 7.1.0 更适合的是一个稳定、保守、需要厂商支持的企业环境而不是追逐新技术的场景。我还试过一种混搭方案核心交易系统跑在 EAP 7.1.0 上周边简单服务用 Quarkus。EAP 负责可靠性要求高、事务性强的核心链路Quarkus 负责编辑性强、需要快速迭代的边缘服务。这个方案在我们业务里运行了两年稳定性表现不错遇到升级时也可以分模块灰度。6. 一些实在的运维建议EAP 7.1.0 这个版本我用了挺长时间踩过不少坑最后分享几条实际运维心得。第一目录权限一定要控制好。EAP 运行账户不要用 root建议用独立的系统账户比如jboss并且只授予standalone/、domain/、bin/这些目录的写权限。曾经遇到过因为日志目录权限过大应用被写入了大量垃圾日志把磁盘打满的案例。第二定期清理standalone/data/content和tmp目录。每次部署都会在 content 目录留下应用内容副本大量版本更新后会占用不少空间。别一股脑全删要结合当前部署的子系统和模块来清理稳妥做法是先从管理接口确认哪些应用还在使用中。第三CLI 脚本一定要纳入版本管理。团队里每个人的排查习惯不同但变更操作必须记录。我在项目里会把所有 CLI 操作写成.cli脚本提交到 Git 仓库里标注批次和变更内容。这样既方便回滚也方便后来者了解系统配置的演进历史。第四如果遇到 EAP 7.1.0 的应用诡异报错不要只盯着应用代码。先看server.log里有没有容器层面的异常再jstack打印线程栈看看有没有死锁、阻塞最后再排查代码问题。很多时候应用层表现出的异常根因都在容器配置或依赖冲突上。如果你正准备把某个老系统升级到 EAP 7.1.0或者首次在这个平台上部署业务按照上面这些步骤来基本能避掉大多数字面上能避开的坑。实际操作中遇到具体报错时也欢迎带着日志来交流这类问题很多是环境相关的一起排查往往比一个人看代码更高效。本文还有配套的精品资源点击获取 JBoss EAP 7.1.0实战：从部署配置到集群迁移的完整指南
简介JBoss EAP 7.1.0是一套由Red Hat维护的企业级Java应用服务器基于WildFly提供Java EE 7规范支持面向需要构建、部署与管理复杂企业应用的后端开发、架构及运维人员。该版本内置模块化类加载机制、RBAC安全控制、SSL/TLS、SOAP/REST Web服务、JPA/JTA数据访问、HornetQ消息中间件、集群负载均衡与故障转移等能力并提供了图形化管理控制台与CLI工具便于配置部署、监控与热更新也适合作为微服务和DevOps流水线的底层运行平台。资源以zip压缩包形式提供整体约175.28MB页面未提供具体文件总数和类型明细实际内容应包含JBoss EAP 7.1.0发行包及相关部署素材。目前已有897人学习下载适合希望离线搭建企业级中间件环境、快速掌握EAP配置思路或完成本地开发环境准备的Java技术人群。1. 项目概述EAP 7.1.0 到底是什么1.1 版本背景与关键组件如果你在公司里做过 Java 后端开发一定对 JBoss 这个老牌应用服务器不陌生。EAP 是 Red Hat 企业级产品线里的应用服务器全称 Enterprise Application Platform7.1.0 是 7.x 系列里一个相当关键的迭代版本。很多刚接触这个版本的人会把它和 WildFly 混为一谈这里先厘清一个基本事实JBoss EAP 7.1.0 基于 WildFly 11Red Hat 在 WildFly 的基础上做了大量裁剪、加固和兼容性验证去掉了很多实验性功能换来了生产环境可用的稳定性。这一版最核心的技术变化有三个方向Java EE 8 规范支持虽然 7.1.0 没有把 Java EE 8 全部规范都落地但 Servlet 4.0、JAX-RS 2.1、CDI 2.0、Bean Validation 2.0 这些主流规范都已经支持对大多数企业应用来说够用了。Eclipse MicroProfile 1.2 技术预览这是 EAP 7.1 在微服务方向上的一次尝试把配置、健康检查、容错、指标等 API 集成到应用服务器内部。Elytron 安全框架技术预览Elytron 是 Red Hat 后续版本主推的安全架构7.1.0 里算第一次正式露面虽然默认还是走传统安全域但可以开始接触了。除了这些底层组件也有明显升级Hibernate 5.1.x 做持久层、Infinispan 8.2 做缓存、ActiveMQ Artemis 做消息中间件。如果你用过 EAP 6会明显感觉 7.1.0 的启动速度快了一大截内存占用也下降不少这主要归功于 Undertow 替代了原来的 Web 容器以及模块化类加载机制的优化。1.2 为什么 2025 年了还要聊这个版本有人会问EAP 都出到 8.x 了7.1.0 已经是很老的版本聊它还有什么意义这里得说句实话国内很多银行、保险、政企、制造业的核心系统至今还在 EAP 7.1.0 上跑着。原因无非几个系统稳定不想动、迁移成本高、内部技术栈绑定太深。所以如果你想接手这些老系统或者参与中间件运维工作EAP 7.1.0 是你躲不开的一个坎。另外EAP 7.1.0 的很多配置思路、CLI 命令、部署方式在 7.2、7.3、7.4 里面依然沿用甚至到了 EAP 8 也没有根本性变化。学好这个版本等于掌握了 JBoss 这条产品线的基本功后面升级版本只是增量学习的问题。这篇文章主要面向三类人刚接手 EAP 7.1.0 的运维/开发人员、准备从 WebLogic/WebSphere 迁移过来的团队以及想搞懂应用服务器内部工作原理的后端工程师。2. 环境准备与安装要点2.1 下载安装与目录结构EAP 7.1.0 的安装过程并不复杂Red Hat 官方提供两种方式一种是 ZIP 包解压安装另一种是 RPM 或安装程序安装。实际生产环境我推荐 ZIP 方式理由有两点第一解压即用目录结构透明方便排查问题第二可控性强方便做多版本并存和快速回滚。我一般把压缩包解压到/opt/jboss-eap-7.1然后设置环境变量export JBOSS_HOME/opt/jboss-eap-7.1 export PATH$PATH:$JBOSS_HOME/bin解压完成后的目录结构里有几个核心目录需要先认识目录作用备注standalone/单机模式配置、部署、日志目录生产环境最常见domain/域模式配置、部署、日志目录多机管理时使用bin/启动脚本、CLI 脚本、工具脚本日常操作都在这里modules/模块化类加载目录所有依赖组件都在这里docs/官方文档和样例配置排查配置问题时值得翻坦白说我对第一次接触 EAP 的同学有个建议先别急着看 domain 模式把你的精力集中在 standalone 模式上。绝大多数中大型项目一台机器一个实例作为独立节点就够了domain 模式虽然听起来可以统一管理多台机器但配置复杂度和排障难度直接上升一个量级没有专业运维团队撑着很容易踩坑。2.2 启动方式standalone 与 domain 如何取舍启动单机模式很简单bin/standalone.sh默认后台运行方式会带一个-b 0.0.0.0参数表示监听所有网卡生产环境千万别这么干最好通过配置文件或者启动参数显式指定内网 IPbin/standalone.sh -Djboss.bind.address192.168.1.10 -Djboss.bind.address.management192.168.1.10这里两个地址要区分开jboss.bind.address是业务端口监听地址jboss.bind.address.management是管理控制台和原生管理接口的监听地址。常规做法是管理地址只监听内网或跳板机不直接暴露到业务网络。启动完成后默认端口是 8080HTTP、9990管理控制台/管理接口、8443HTTPS 如果有配置。默认配置是standalone.xml另外还有standalone-full.xml带全部子系统和standalone-ha.xml带高可用和集群功能做集群测试可以直接指定bin/standalone.sh --server-configstandalone-ha.xml3. 核心配置与实操细节3.1 管理 CLI 的高频操作EAP 的管理方式主要有三种Web 管理控制台、原生管理接口 CLI、配置文件手工修改。我个人强烈推荐 CLI因为脚本化、可审计、能复现Web 控制台更适合快速查看状态或者在图形界面里做一些临时调整。CLI 的启动和连接方式bin/jboss-cli.sh --connect连接成功后你可以执行很多日常操作。比如查看当前运行状态:read-attribute(nameserver-state)结果会返回running表示服务器正常。查看所有部署的应用deployment-info查看端口是否正常占用这个在用脚本做健康检查时很管用/socket-binding-groupstandard-sockets/socket-bindinghttp/:read-attribute(namebound-address)CLI 的一个好处是支持 tab 补全命令写一半按 tab 就能自动补全不用去死记硬背所有路径。另一个好处是支持batch模式比如批量创建数据源和子系统配置可以把所有命令写在一个 batch 里最后统一执行这一步在生产环境变更时特别重要能减少中间状态产生的不一致风险。3.2 数据源配置的完整流程数据源配置是 EAP 生产环境里最常见的操作几乎每个业务系统都要连数据库。EAP 7.1.0 里数据源的配置逻辑是先装驱动再建数据源最后测试连接。以连接 MySQL 为例第一步需要安装 MySQL 驱动。EAP 的类加载是模块化的不能随手把 jar 丢到 classpath 里必须把驱动做成一个 module或者用 deploy 方式部署一个 driver 包。我习惯用 module 方式因为这样驱动和应用解耦也方便多应用共享cd $JBOSS_HOME/modules/system/layers/base/com/mysql/main/ cp mysql-connector-java-5.1.49.jar ./ vi module.xmlmodule.xml 内容示例如下?xml version1.0 encodingUTF-8? module xmlnsurn:jboss:module:1.5 namecom.mysql resources resource-root pathmysql-connector-java-5.1.49.jar/ /resources dependencies module namejavax.api/ module namejavax.transaction.api/ /dependencies /module创建完 module 之后通过 CLI 注册驱动并创建数据源driver add --namemysql --driver-module-namecom.mysql --driver-class-namecom.mysql.jdbc.Driver >tail -f standalone/log/server.logEAP 的日志默认按天滚动开发测试时可以直接看 server.log生产环境建议把server.log的 level 设置为 INFO 以上避免日志量过大。日志文件路径默认在standalone/log/下这个目录也是排查问题第一时间要看的。4. 生产环境常见问题与排查4.1 诡异报错实录先记录一次我实际踩过的坑。某业务系统在 EAP 7.1.0 上部署正常但一调用某个接口就报错错误信息类似ClassNotFoundException: com.example.common.util.JsonUtil。一开始我以为只是简单的缺 jar 包但检查了应用的lib目录类明明在里面。问题出在 EAP 的模块化类加载机制上。EAP 默认每个部署单元是独立 classloader虽然能看到应用自己的类但跨部署或者和容器自带类库之间有冲突时行为会变得很隐蔽。最后定位发现是应用里引入了 Hadoop 的客户端 jar里面带了老版本的javax.xml.bind类和 EAP 7.1.0 自带的 Jakarta XML Binding 实现产生了冲突。这种类冲突问题在 EAP 上很常见排查思路一般分三步看具体报错的类在哪个 jar 里用jar tvf xxx.jar | grep ClassName查看。看应用里是否包含多个相同package路径的 jar或者同一个 jar 的多个旧版本。用-Djboss.modules.system.pkgsorg.jboss.logmanager这类参数调试类加载或者干脆用 jboss-deployment-structure.xml 把冲突的依赖排除掉。4.2 性能与内存排查技巧EAP 7.1.0 在默认参数下并不适合生产高并发场景需要根据业务量调 JVM。我一般通过bin/standalone.conf修改 JVM 参数Linux 下实际生效的是JAVA_OPTS变量。我常用的初始配置如下JAVA_OPTS-Xms4g -Xmx4g -XX:MetaspaceSize512m -XX:MaxMetaspaceSize512m -XX:UseG1GC -XX:MaxGCPauseMillis200这里特别注意-Xms和-Xmx建议设成相同值避免 JVM 动态扩容带来的性能抖动。Metaspace 大小也别给太小EAP 模块化加载类很多如果MaxMetaspaceSize不够会出现OutOfMemoryError: Metaspace而且这种错误经常在频繁重部署应用时才暴露出来。还有一个容易被忽略的问题线程池配置。EAP 的 Undertow 默认 worker 线程数会按 CPU 核心数计算但实际业务里如果涉及大量阻塞 IO比如远程调用第三方接口默认线程池容易被占满。可以在 CLI 里调整/subsystemundertow/serverdefault-server/http-listenerdefault:write-attribute(namemax-post-size, value104857600)这个max-post-size是限制请求体重上限的默认约 10MB如果业务要上传大文件不调大会直接报 413。类似这样的参数很多动手前先翻一下文档或者用:read-resource-description看看有哪些属性可以设置。症状可能原因排查方向接口响应慢线程池满、数据库连接池打满看jstack、数据源统计定时任务不执行EJB 定时器持久化后状态异常检查standalone/data/timer-service-data应用启动报端口冲突8080 或 9990 被占用lsof -i:8080改端口或杀进程偶发 503Undertow 线程池耗尽调大 worker 线程数优化阻塞代码内存持续上涨本地缓存未过期、Session 未回收用 JConsole 连接查看堆占用检查 Infinispan 缓存配置4.3 高可用与集群配置的经验如果你要做集群EAP 7.1.0 的配置核心在于standalone-ha.xml和domain.xml里的ha配置。集群模式下应用 Session 默认没有开启分布式缓存需要显式配置web子系统的分布式 Session 管理和 Infinispan 缓存容器。一个典型配置是通过 CLI 启用 Session 复制/subsysteminfinispan/cache-containerweb:add() /subsysteminfinispan/cache-containerweb/distributed-cachedist:add()然后还要配置 JGroups 的协议栈EAP 默认是udp组播方式不过很多云环境下组播不通必须改成 TCP Gossip 或 KUBE_PING 这类协议。这块我自己的经验是如果你在 Kubernetes 里跑 EAP 集群提前研究下KUBE_PING别上来就配组播否则在云环境里会折腾到怀疑人生。5. 从迁移视角看 EAP 7.1.05.1 从 EAP 6 / WildFly 8-10 迁移EAP 6 到 EAP 7 是一个大的架构调整不只是升级版本号那么简单。核心变化包括Web 容器从 JBoss Web 换成了 Undertow事务子系统从 Bitronix 换成了 Narayana消息中间件从 HornetQ 换成了 ActiveMQ Artemis。这意味着很多在 EAP 6 上配置过的 JMS 队列、连接工厂配置在 7.1 里都是翻天覆地的变化。如果你的项目正在做这种升级我给一个比较稳妥的路径先把应用代码从 Java EE 6 规范升级到 Java EE 7/8尤其是 EJB 和 JPA 相关的 API 变化。用一个干净的 EAP 7.1.0 环境部署原应用让报错暴露出来逐个解决。对照standalone.xml新老差异手工迁移数据源、队列、安全域等自定义配置。重点测试 JMS 和事务嵌套的场景这些最容易出问题。举个例子EAP 6 里配置 JMS 队列通常要在messaging子系统的jms-destinations节点加配置EAP 7.1.0 里则换成messaging-activemq子系统通过添加 JMS Queue 资源完成。同一个业务配置路径完全不同文档如果没有及时更新排查起来效率极低。5.2 微服务与轻量化部署场景EAP 7.1.0 对微服务场景并不是完全不适配但你需要做一些取舍。MicroProfile 1.2 的技术预览让你可以用它跑起一个小型 REST 服务并拥有配置、健康检查等能力。如果团队不想引入 Spring Boot又想要 Java EE 的成熟生态把 EAP 当作一个轻量级服务运行平台是可行的。不过说实话如果是新项目且没有历史包袱我建议直接用 WildFly 最新版或 Quarkus这类框架在启动速度和内存占用上比 EAP 7.1.0 优秀太多。EAP 7.1.0 更适合的是一个稳定、保守、需要厂商支持的企业环境而不是追逐新技术的场景。我还试过一种混搭方案核心交易系统跑在 EAP 7.1.0 上周边简单服务用 Quarkus。EAP 负责可靠性要求高、事务性强的核心链路Quarkus 负责编辑性强、需要快速迭代的边缘服务。这个方案在我们业务里运行了两年稳定性表现不错遇到升级时也可以分模块灰度。6. 一些实在的运维建议EAP 7.1.0 这个版本我用了挺长时间踩过不少坑最后分享几条实际运维心得。第一目录权限一定要控制好。EAP 运行账户不要用 root建议用独立的系统账户比如jboss并且只授予standalone/、domain/、bin/这些目录的写权限。曾经遇到过因为日志目录权限过大应用被写入了大量垃圾日志把磁盘打满的案例。第二定期清理standalone/data/content和tmp目录。每次部署都会在 content 目录留下应用内容副本大量版本更新后会占用不少空间。别一股脑全删要结合当前部署的子系统和模块来清理稳妥做法是先从管理接口确认哪些应用还在使用中。第三CLI 脚本一定要纳入版本管理。团队里每个人的排查习惯不同但变更操作必须记录。我在项目里会把所有 CLI 操作写成.cli脚本提交到 Git 仓库里标注批次和变更内容。这样既方便回滚也方便后来者了解系统配置的演进历史。第四如果遇到 EAP 7.1.0 的应用诡异报错不要只盯着应用代码。先看server.log里有没有容器层面的异常再jstack打印线程栈看看有没有死锁、阻塞最后再排查代码问题。很多时候应用层表现出的异常根因都在容器配置或依赖冲突上。如果你正准备把某个老系统升级到 EAP 7.1.0或者首次在这个平台上部署业务按照上面这些步骤来基本能避掉大多数字面上能避开的坑。实际操作中遇到具体报错时也欢迎带着日志来交流这类问题很多是环境相关的一起排查往往比一个人看代码更高效。本文还有配套的精品资源点击获取