搞过中间件运维的人都知道WebLogic 在生产环境里很少单机跑尤其业务量上来之后单机部署就是给自己埋雷。进程一挂应用全挂稍微有点规模的项目都扛不住这种单点风险。我最近刚做完一套 WebLogic 双机集群的部署从环境规划、安装配置、集群创建到会话复制、入口负载均衡、故障切换验证全程踩了不少坑也整理了不少经验。这篇文章就是围绕 weblogic 集群搭建、双机部署这条主线把部署过程中我会反复确认的点和真实遇到的问题记录一遍。适合准备做 WebLogic 高可用改造、刚接手中间件运维、或者被领导要求“把两个节点组集群”但还没理清思路的同事参考。文章不会去翻官方文档的每一句话而是按实际操作顺序来先想清楚拓扑和端口再装软件和初始化环境然后创建域、配置集群、管理受管服务器最后验证会话复制和故障切换。每一部分都会说明“为什么要这么做”也会把容易返工的地方提前标出来。1. 部署前把这三件事想明白1.1 双机集群到底解决什么问题集群不是把两台机器装一样的软件就算完事。WebLogic 集群解决的核心问题是高可用和水平扩展一台 WebLogic ManagedServer 挂了另一台还能接住用户请求并发上来了两台节点分摊压力。这里的双机部署我理解是两台物理机或虚拟机分别运行一个或多个 ManagedServer通过集群协议互相感知对方状态并由统一入口把流量分发过去。实际做的时候很多人会把“集群”和“负载均衡”搞混。WebLogic 集群本身不对外提供访问入口它只是把多个 ManagedServer 组成一个逻辑组节点之间会做心跳通信、Session 复制、消息转发。真正接收用户请求的是前端入口比如 Apache、Nginx、OHS或者硬件负载均衡设备。只有在入口层用轮询、最小连接数等策略把请求分到两台节点上集群的意义才能落地。理解了这一点部署的时候就不会漏配负载均衡器了。另外要明确的是双机部署不等于双活所有组件。WebLogic 的 AdminServer 在集群里承担管理职能它可以挂在其中一台机器上生产环境不建议让 AdminServer 和 ManagedServer 混跑在业务关键路径里。官方也支持多种拓扑独立 AdminServer、一对多 ManagedServer、AdminServer 高可用等。对于“双机”这种规模我的做法是一台小机器放 AdminServer 和 NodeManager 管两个节点或者干脆在每台机器各放一个 NodeManager但 AdminServer 只选一台机器启动。前提是 AdminServer 宕机不影响已运行节点但部署新应用、修改集群配置时必须要它在线。1.2 我推荐的集群拓扑一个 Admin、两个 ManagedServer双机部署最省事的拓扑是两台机器 x 一个 ManagedServer外加一个 AdminServer。举例来说weblogic-node01IP 192.168.10.11运行 AdminServer端口 7001、NodeManager端口 5556、ManagedServer1端口 8001。weblogic-node02IP 192.168.10.12运行 NodeManager端口 5556、ManagedServer2端口 8001。这样配置前端负载均衡器将请求同时转发到 8001 端口两个 ManagedServer 加入同一个集群。Session 复制依赖集群内部的组播或单播通道完成和前端设备无关。这种结构的好处是简单、占机器少、容易排查。缺点是 AdminServer 只在一台节点上如果 node01 整机宕机AdminServer 也暂时不可用。不过只要 ManagedServer2 还在运行应用请求依然能通过 node02 继续服务只是控制台暂时登录不了也不能做动态部署。对绝大多数业务场景来说这个可用性水平已经够用。如果希望 AdminServer 也高可用可以把它放到独立的第三台机器再做脚本监控或虚拟 IP 漂移双机部署先不用考虑这么复杂。1.3 端口、IP、防火墙规划一次配好没有端口规划就开始装软件后面一定会反复改。我这次部署的端口规划如下组件服务器监听端口用途说明AdminServernode017001管理控制台、WLST 管理NodeManagernode015556管理 ManagedServer 启停ManagedServer1node018001业务访问入口NodeManagernode025556管理 ManagedServer 启停ManagedServer2node028001业务访问入口集群单播端口node01/node02通用配置 7001/8001集群心跳、Session 复制WebLogic 集群通信如果使用单播模式会通过集群地址中的某个端口作为“Cluster Address”心跳数据就在这个端点上跑。单播配置会在后面详细说。现在要做的就是提前确认两台机器之间这些端口能互通防火墙规则里面把 7001、8001、5556 以及集群通信用的端口都放通。这里特别提醒一句生产环境的防火墙千万不要图省事直接关掉保险起见只放通业务需要的端口即可。WebLogic 单播模式需要的通信端口本质上就是 ManagedServer 的监听端口相对容易控制。如果用了多播还要专门放开组播地址和端口很多网络设备默认禁多播排查起来非常麻烦所以我不推荐双机部署用多播。2. WebLogic 安装与双机环境初始化2.1 版本选型12cR2 JDK8 是最稳的组合WebLogic 版本很多10.3.x、12.1.x、12.2.x、14c 都有生产环境在用。我的建议是新做集群尽量选 WebLogic 12.2.1.4.0也就是 12cR2。这个版本稳定、对 JDK8 支持好、补丁更新也比较及时而且控制台和 WLST 脚本的功能都足够完整。JDK 版本没有太多悬念JDK8 的稳定小版本即可比如 8u201、8u231 这类旧一点但很成熟的版本。JDK 版本不是越新越好要结合 WebLogic 官方的兼容矩阵来看。安装 WebLogic 之前先把 JDK 装好java -version确认再装中间件。安装账户方面建议新建专用的系统用户比如weblogic不要用root跑 WebLogic。生产安全审计一般也会要求中间件进程以非 root 用户运行。我用的是/home/weblogic作为用户目录软件安装目录放在/opt/weblogicDomain 目录放在/u01/app/weblogic/user_projects/domains提前把权限分好。2.2 静默安装 WebLogic 快速记录WebLogic 官方有图形安装和静默安装两种方式。如果是内网服务器没有图形环境静默安装更实用。我习惯先下载fmw_12.2.1.4.0_wls.jar然后写一个wls.rsp响应文件[ENGINE] Response File Version1.0.0.0.0 [GENERIC] ORACLE_HOME/opt/weblogic/oracle_home INSTALL_TYPEWebLogic Server DECLINE_SECURITY_UPDATEStrue SECURITY_UPDATES_VIA_MYORACLESUPPORTfalse执行安装java -jar fmw_12.2.1.4.0_wls.jar -silent -responseFile /home/weblogic/wls.rspDECLINE_SECURITY_UPDATEStrue表示不配置在线更新。装的时候关闭外部下载避免安装卡在远程检查上。安装完成后检查/opt/weblogic/oracle_home/wlserver存在与否。两台机器都执行同样的安装动作确保版本一致。有坑的地方如果机器上没有图形终端直接敲java -jar可能会抛HeadlessException。加-silent参数就不会弹图形。另一个常见问题是磁盘空间不够WebLogic 完整安装大概需要 5~8GB提前用df -h检查。装错路径更麻烦Oracle Home 一旦确定后面改起来很费劲。2.3 hosts、防火墙、用户权限一次性配好WebLogic 对主机名解析很敏感。双机部署时每台机器的/etc/hosts都要同时加上两台机器的 IP 和主机名映射而且主机名最好别用localhost。比如192.168.10.11 weblogic-node01 192.168.10.12 weblogic-node02如果不加 hosts集群节点之间通过主机名通信时DNS 解析慢或解析不到会出现 ManagedServer 反复“Starting”却始终起不来。防火墙规则按前面表格放通。Linux 如果用的是firewalld可以用firewall-cmd --permanent --add-port7001/tcp这一类方式逐一加。加完别忘--reload再用telnet或nc双向测试端口连通性。两台机器之间建议配置 SSH 免密登录后续同步文件、远程执行命令会方便很多。同时把 weblogic 用户的ulimit调大合理设置nofile和nproc否则高并发时句柄可能不够。3. 创建集群域控制台与 WLST 两种方式3.1 图形化创建域的核心选项如果是第一次搭建图形化向导最直观。在 node01 上执行/opt/weblogic/oracle_home/wlserver/common/bin/config.sh选择“Create a new domain”域名我写base_domain。模板选择“Basic WebLogic Server Domain”。向导里会有几个关键选项是否包含集群选择“Generate a domain compatible with a cluster”或者后续通过集群向导手动创建。AdminServer 地址建议填 node01 的实际 IP不要填 127.0.0.1 或 localhost否则后面客户端和 ManagedServer 找 AdminServer 会找不到。NodeManager 类型生产环境建议选择“Per-domain NodeManager”这样每台机器可以通过 NodeManager 管理该域下的 ManagedServer。ManagedServer 和 Cluster这个版本可以在创建域时直接添加两台 ManagedServer并新建 Cluster。添加 ManagedServer 的时候监听地址一定不要默认成All Local Addresses。在双机部署里最好显式指定每个 ManagedServer 的监听 IP比如 ManagedServer1 监听 192.168.10.11 的 8001ManagedServer2 监听 192.168.10.12 的 8001。理由很简单如果监听所有网卡万一机器多网卡WebLogic 可能选错地址注册到集群后端会话复制就乱了。Cluster 部分集群地址可以写成192.168.10.11:8001,192.168.10.12:8001。这里的端口建议和管理端口保持一致方便记忆。还要在“Cluster Messaging”里选择Unicast单播模式。WebLogic 12c 默认就是单播这是个好变化老版本多播配起来烦死人。图形化创建域后会生成一个base_domain目录。此时 node02 上还没有 Domain可以把整个 Domain 目录同步过去或者用 WLST 在第二台机器上创建。如果直接scp -r拷贝整个目录注意目录里面很多路径写的是 node01 的绝对路径启动前要检查和修正。3.2 WLST 脚本创建域双机复制不再心累图形化向导虽然直观但版本升级、多环境 clone 时会很痛苦。我后来更推荐用 WLST 脚本创建域和集群脚本化之后每次初始化新环境都是几分钟的事。下面是一个精简的 WLST Python 脚本可以根据实际路径调整readTemplate(/opt/weblogic/oracle_home/wlserver/common/templates/wls/wls.jar) name base_domain set(Name, name) # AdminServer cd(/Servers/AdminServer) set(ListenAddress, 192.168.10.11) set(ListenPort, 7001) # Manage Servers cd(/) create(ManagedServer1, Server) cd(/Servers/ManagedServer1) set(ListenAddress, 192.168.10.11) set(ListenPort, 8001) cd(/) create(ManagedServer2, Server) cd(/Servers/ManagedServer2) set(ListenAddress, 192.168.10.12) set(ListenPort, 8001) # Cluster cd(/) create(DCluster, Cluster) cd(/Clusters/DCluster) set(ClusterAddress, 192.168.10.11:8001,192.168.10.12:8001) # Add servers to cluster cd(/Servers/ManagedServer1) set(Cluster, DCluster) cd(/Servers/ManagedServer2) set(Cluster, DCluster) # Write domain writeDomain(/u01/app/weblogic/user_projects/domains/base_domain) closeTemplate() exit()保存为create_domain.py然后在 node01 执行. /opt/weblogic/oracle_home/wlserver/server/bin/setWLSEnv.sh java weblogic.WLST create_domain.py执行完会在目标路径生成 Domain。再把这个目录拷贝到 node02但要注意拷贝后修改bin/setDomainEnv.sh和config/config.xml中的绝对路径、IP 地址否则 node02 启动 ManagedServer2 时还是找 node01 的配置文件路径。3.3 配置 Machine 与 NodeManager把 ManagedServer 管起来Domain 创建好之后ManagedServer 并不会自动跟着 AdminServer 启动。WebLogic 生产环境一般通过 NodeManager 管理受管服务器的启停所以要给每个受管服务器配置 Machine。Machine 这个概念很多新手容易绕晕。简单理解Machine 是“一台物理机器或虚拟机”的抽象NodeManager 是跑在这台机器上的进程ManagedServer 由一个 Machine 上的 NodeManager 拉起。因此 node01 和 node02 各要创建一个 MachineMachine 里填 NodeManager 的地址端口比如 192.168.10.11:5556 和 192.168.10.12:5556然后再让 ManagedServer1 关联到 Machine1ManagedServer2 关联到 Machine2。NodeManager 的启动方式是执行cd /u01/app/weblogic/user_projects/domains/base_domain/bin ./startNodeManager.shNodeManager 启动默认监听 5556如果端口被占用可以在nodemanager.properties里改。需要注意Domain 拷到 node02 后node02 上的 NodeManager 也会读取这个目录里的配置但它启动时不能用同名端口冲突。双机正常情况是各跑各的 NodeManager所以端口冲突概率不大但如果 node01 暂时关了 NodeManager又想在 node01 上测试启动 node02 的 ManagedServer就很容易搞混。配置完 Machine登录 AdminServer 控制台http://192.168.10.11:7001/console在“环境 服务器”里能看到两个 ManagedServer 的状态。此时手动启动 ManagedServer1 和 ManagedServer2确认状态变成 RUNNING。3.4 启动顺序与首次验证我这次部署总结的启动顺序如下在 node01 启动 AdminServerstartWebLogic.sh。在 node01、node02 分别启动 NodeManagerstartNodeManager.sh。在控制台或通过 NodeManager 分别启动 ManagedServer1、ManagedServer2。这里有一个容易跳坑的操作如果先把 ManagedServer 起来启动它时会去连 AdminServer 的 7001 端口如果 AdminServer 没起来受管服务器会报BEA-000362之类连不上 AdminServer 的错误。所以顺序不能乱。启动完成后在控制台的“集群”页面能看到两个节点状态为 RUNNING。还可以检查两台机器上的logs/base_domain/下的日志确认集群成员之间的心跳、复制通道正常。验证应用部署方面把测试 war 包部署到集群目标DCluster上访问前端负载均衡地址多刷新几次确认两个节点都能收到请求。4. 双机部署的真正关键会话复制与入口负载均衡4.1 让 Session 在两台节点间复制缺一不可的三件事集群搭好只是第一步如果用户的登录 Session 没有复制node01 挂了切换到 node02用户会被强制退出业务体验直接崩。WebLogic 的 Session 复制需要满足三个条件一是应用必须是“可分发”的也就是web.xml里要加distributable/标签。web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee display-nametest-webapp/display-name distributable/ /web-app二是集群的复制模式要配置正确。WebLogic 默认单播环境下会启用“Session Replication”在集群配置的 Replication 标签页里复制类型选择Replication Groups就可以默认配置通常够用。三是集群内各节点时间要同步。两台机器差个几十秒心跳和复制都会出问题。建议配置 NTP 时间同步这是很多故障的隐藏原因。配好之后怎么验证我常用的方法是部署一个带 Session 的测试页面在 node01 上登录并写入 Session 数据然后手动 kill 掉 node01 的 Java 进程再刷新前端地址session 里的数据还在说明复制生效。如果数据丢了优先检查web.xml有没有distributable/这一步最容易漏。4.2 入口负载均衡Apache、Nginx 与粘滞会话集群内部复制做得再好入口层也得配合。如果前端直接随机转发到两台节点但 WebLogic 集群复制有时延用户请求在节点切换时可能拿不到 Session所以负载均衡器最好开启“粘滞会话”也就是 session sticky。同一个用户尽量固定到同一个 ManagedServer只有那个节点故障了才切到另一台。我用 Apache 或者 OHS 比较多。以 Apache 配mod_wl_ohs.so为例虚拟主机里可以这样配置VirtualHost *:80 ServerName app.example.com # WebLogic Cluster Config Location / SetHandler weblogic-handler WebLogicHost 192.168.10.11 WebLogicPort 8001 WebLogicCluster 192.168.10.11:8001,192.168.10.12:8001 WLCookieName JSESSIONID WLProxySSLPassThrough Off /Location /VirtualHost如果用的是 NginxWebSocket 或 HTTP 场景可以这样写upstream weblogic_cluster { ip_hash; # 简单的粘滞策略 server 192.168.10.11:8001 max_fails2 fail_timeout30s; server 192.168.10.12:8001 max_fails2 fail_timeout30s; } server { listen 80; server_name app.example.com; location / { proxy_pass http://weblogic_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }注意ip_hash并不是严格的应用 Session 粘滞如果客户端 IP 网络分层多变会失效。更稳的是按 Cookie 做 sticky比如 Nginx 的sticky cookie模块但 Nginx 对 WebLogic 的 JSESSIONID 适配要小心。建议生产环境优先选用 WebLogic 官方配套的 OHS mod_wl因为对JSESSIONID识别、节点故障甩连接这些细节处理得更完善。4.3 数据源与 JMS 的集群注意事项双机集群解决了应用层的高可用但如果数据源连接的是一个单点数据库数据库一挂应用照样不可用。WebLogic 的数据源可以配成向多个数据库地址发起连接比如 Oracle RAC 场景用 GridLink 数据源或者普通多实例数据库配多地址。配置时在数据源连接池里填多个 URL并设置“测试连接”和“失败重连”让连接池能自动切换到可用实例。JMS 也是容易踩坑的地方。集群里如果 JMS 服务器只在某个 ManagedServer 上那它依然是单点。建议把 JMS 服务器分别部署到两个节点并启用消息持久化文件存储放在共享存储或各自节点本地持久化目录。双机部署下JMS 的故障转移与持久化策略需要单独测很多人把关系型数据库配好了JMS 却没测切换真出问题就措手不及。5. 双机集群常见问题与排查实录5.1 我实际遇到的几个典型故障表格能快速定位问题展开讲更容易理解背后的原因。现象可能原因解决方式AdminServer 能起来管理台打不开7001 端口未放通或监听地址错了检查/etc/hosts、监听地址是否写成了 localhostManagedServer 一直 StartingNodeManager 没起、密码不匹配、AdminServer 未启动依次启动 AdminServer、NodeManager并检查boot.properties两台节点之间 Session 不复制web.xml缺少distributable/补上标签并重新部署集群节点各自为政互不认识集群地址配置不一致单播/多播模式不匹配在 Cluster 配置里把两个节点地址写成同一个集群地址一台节点宕机前端还在往它转发负载均衡器健康检查未配置在 Apache/Nginx/OHS 配置健康检查策略应用启动报端口被占用8001 端口被其他服务占用netstat -anp堆内存溢出JVM 参数没调修改setDomainEnv.sh里的USER_MEM_ARGS展开讲一两个最典型的。先说“ManagedServer 一直 Starting”。这个现象最常见也最让人焦虑。NodeManager 起来之后控制台看到 ManagedServer 状态是 STARTING等很久也没有变成 RUNNING。这时候先去 AdminServer 日志和服务端日志里搜关键词很多是BEA-000362或BEA-000362连接超时。原因无外乎ManagedServer 的监听地址填错、NodeManager 和 ManagedServer 在同一台机器上起不来、节点密码和 AdminServer 中记录的不一致。排查时先确认 NodeManager 进程在跑再检查端口再去看ManagedServer.log基本能定位。再说“节点之间互相看不到”。WebLogic 集群节点要看config.xml中的 Cluster 配置。如果两台机器的config.xml里cluster-address不一样节点就加入了不同集群或无法互相发现。双机部署时建议把两个 ManagedServer 都分配到同一个 Cluster并且 ClusterAddress 写两个地址。同步 Domain 后一定要保证配置一致。5.2 故障切换实测kill 一个节点看用户会话丢不丢部署完成后我习惯做一次“破坏性测试”。过程很简单准备一个测试页面向 Session 写入用户名通过负载均衡地址访问确认请求落在 node01再执行kill -9杀掉 node01 的 ManagedServer 进程然后立刻刷新前端地址看请求是否自动切到 node02、Session 是否保留。如果 Session 保留了说明整条链路是通的负载均衡健康检查把 node01 摘掉、请求转到 node02、node02 通过复制拿到了 Session。如果 Session 丢了按优先级检查应用的web.xml是否有distributable/、集群复制是否启用、两台机器时间是否同步、负载均衡器是否真的能识别 JSESSIONID。测试的时候建议开两个终端一边看access.log一边看 WebLogic 的access.log。前端访问记录能直观看到请求在哪个节点之间切换。这样能快速区分问题出在入口层还是 WebLogic 层。5.3 WebLogic 安全补丁与漏洞更新WebLogic 这些年被爆过不少安全漏洞很多漏洞不需要见控制台只要向 7001 等端口发特定请求就能被利用。双机集群部署完后安全基线检查是必须做的一步。至少要做这几件事一是及时更新补丁。安装完 WebLogic 之后需要根据版本到官方支持站点下载最新的 PSU 或 CPU 补丁使用opatch工具应用到 Oracle Home。补丁升级会影响集群内所有节点升级前先备份 Domain 和 Oracle Home并做灰度升级。可以按“先 node02、再 node01”的顺序滚动升级避免业务中断。二是修改默认端口和管理账号。7001 作为默认管理端口众所周知建议通过网络策略限制来源 IP或把管理端口改成非常规端口。WebLogic 默认管理员账号weblogic必须修改强密码控制台和 NodeManager 不要用同一个密码。三是对外访问尽量走 HTTPS。入口负载均衡器和 WebLogic 之间使用 SSL或者至少通过代理层终结 TLS避免明文传输。如果 WebLogic 直接暴露公网风险极高无论在双机还是单机环境都不推荐。6. 写在最后双机部署的经验与扩展方向WebLogic 双机集群搭建这件事流程本身不算复杂但每个环节都藏着“默认配置能不能直接上生产”的坑。比如图形化创建域时默认的监听地址、集群的多播单播选择、应用是否加distributable/、负载均衡是否粘会话这些点只要有一个没考虑到上线后就会变成半夜两点的告警电话。我个人在实际操作中的体会是先把最小可用拓扑跑通再逐步加高可用细节。第一次做的时候不用急着上 AdminServer 高可用、多集群互联这些高级功能先把双机、双 ManagedServer、会话复制、入口切换跑顺把日志和监控补上再考虑更复杂的扩展。WebLogic 控制台的“监控”标签页里能看集群状态和复制流量日志文件要定时清理和备份配合 Zabbix 或 Prometheus 之类监控工具盯端口和进程双机部署也才真正称得上生产可用。再分享一个小技巧每次修改集群配置前先备份config目录最稳妥。我曾经因为调整集群地址时写错端口导致整个集群启动异常最后靠备份目录回滚才恢复。集群和单机部署最大的区别就是配置有全局性一个config.xml同步不到位后面全是蓝屏。先备份再调整永远是一条实用的保命原则。