如果你点开这篇文章大概率是已经受够了单机WebLogic的提心吊胆应用发版只能半夜停机发布机器一挂业务就全停监控短信凌晨三点准时把人叫醒。WebLogic集群搭建和双机部署这件事我在生产环境前前后后做过好几次踩过的坑比配置项还多今天把这些经验整理成一份实操记录从方案选型到双机部署再到问题排查把关键步骤和容易忽略的细节一次说清楚。这篇文章适合中间件运维、应用运维和刚接手WebLogic集群的架构师参考。内容不会绕弯子讲太多理论重点放在“怎么落地”和“出了问题怎么查”上你照着步骤操作至少能少踩一半的坑。1. 集群方案选型双机部署前先想清楚的事1.1 为什么双机部署先分清“高可用”和“负载均衡”两种诉求需求方说“要做高可用”但“高可用”这个表述太笼统了实际建设前必须把诉求掰开。有的系统是希望一台机器挂了另一台能顶上业务不中断这叫故障转移有的系统是并发量上来了单机扛不住希望两台机器一起扛流量这叫负载均衡。WebLogic集群两者都能实现但设计思路和配置侧重点完全不同。我做的这个双机部署项目业务方一开始只说要“两台机器互相备份”。后来梳理会话状态之后发现业务应用重度依赖HttpSession保存登录态和中间数据如果只是简单做主备切换切换过去所有用户都要重新登录业务上根本没法接受。所以最终选择了WebLogic集群方案让两台机器同时在线提供服务通过会话复制机制保证任一台宕机时用户会话不丢失。这里要明白一个关键点集群的价值不只是高可用还是平滑扩容两个节点同时跑业务一台出问题另一台能无缝接管。1.2 集群与主备的区别别用错了方案WebLogic集群Cluster和传统的主备Active-Passive是两条不同的技术路线。集群模式下多个受管服务器节点同时对外服务各自有独立的JVM进程和内存节点之间通过心跳和会话复制保持状态同步。主备模式则是一台主节点干活备用节点空转或半空转只在主节点故障时接管。主备方案通常配合虚拟IP漂移或者外部脚本实现资源利用率低且切换时存在明显的服务中断窗口。WebLogic集群虽然没有内置统一的访问入口需要在前端配负载均衡设备、Nginx或Apache转发但从应用视角来看所有节点都是对等的任何一个节点宕机负载均衡器通过健康检查把流量切走即可。选型上我的建议是如果你的系统对会话保持要求高并发量又不止一台机器能扛住优先考虑WebLogic集群如果业务无状态或可接受会话短暂丢失且预算有限主备方案也能凑合。但对大多数Java Web业务系统来说集群是更稳妥的选择。1.3 版本与JDK的匹配一个能省一周的决策WebLogic版本和JDK版本的匹配问题经常被新手忽略等两台机器装好才发现互相不认折腾半天全推倒重来。目前生产环境主流的组合是WebLogic 12.2.1.4配JDK8或者WebLogic 14.1.1.0配JDK11具体以Oracle官方的认证矩阵为准。我这次用的是12.2.1.4加JDK 8u202原因很实在业务系统是老项目用的第三方组件和代码库对JDK8的兼容性最稳。如果项目比较新、没有历史包袱可以考虑14c加JDK11性能和安全性有一定提升。但有一点必须严格做到两台机器的WebLogic版本、补丁版本、JDK版本和架构位数必须完全一致。我见过一个生产事故两台机器WebLogic补丁差了一个小版本序列化字节流不兼容集群会话复制间歇性失败查了一整天才定位到是补丁不一致。所以双机部署前先花十分钟核对两边的版本号值得。1.4 底层网络、主机名与存储双机架构的物理基础很多人搭建集群一上来就装软件结果集群建好了节点之间怎么都发现不了对方最后发现问题出在底层网络和主机名配置上。双机部署前有几项物理基础必须提前确认。第一主机名和解析。两台机器的主机名不能相同/etc/hosts里要写清两台的IP和主机名对应关系确保互相能解析。WebLogic在集群通信中会用到主机名解析不对直接导致节点注册失败。第二时间同步。两台机器的时间偏差不能超过允许范围否则会报认证失败。建议配置NTP定时同步这个细节经常被忽略。第三端口连通性。管理端口、受管端口、节点管理器端口、集群通信端口双向都需要放通。第四存储。双机集群不强制要求共享存储但应用包必须保证两台机器内容一致我习惯在发布机上打包然后通过发布系统或脚本统一分发到各节点避免手工拷包出现新旧混合的问题。2. 环境准备与安装从JDK到域的完整链路2.1 用户、目录与操作系统参数WebLogic不要用root用户直接跑生产环境务必创建专用系统用户比如weblogic用户。原因不只是权限安全还因为WebLogic的域配置里记录了文件路径和用户信息用root创建的文件后续以其他用户管理会非常别扭。目录规划上我习惯把安装目录、域目录和日志目录分开比如/opt/weblogic 存放WebLogic安装程序/home/weblogic/domains 存放域目录/data/logs 存放应用和服务器日志这样做的原因是备份的时候只需要备份域目录和日志目录安装目录坏了直接用安装包重建就行。另外操作系统层要把文件句柄数调大修改/etc/security/limits.conf设置weblogic用户的nofile和nproc。WebLogic默认的文件句柄限制在某些Linux发行版上只有1024并发一上来就报Too many open files非常坑。2.2 JDK安装与WebLogic安装JDK安装没什么花活解压到固定路径配置JAVA_HOME和PATH就行。有一点要提醒确认你下载的是64位JDK并且与WebLogic架构一致。32位JDK跑WebLogic 12c虽然能启动但堆内存一超过2GB就难受生产环境别这么干。WebLogic安装支持图形界面和静默安装两种方式。服务器上没图形环境时用静默安装写一个install.xml?xml version1.0 encodingUTF-8? bea-installer input-fields data-value nameBEAHOME value/opt/weblogic/oracle/wlserver / data-value nameWLS_INSTALL_DIR value/opt/weblogic/oracle/wlserver / data-value nameINSTALL_NODE_MANAGER_SERVICE valueno / data-value nameCOMPONENT_PATHS valueWebLogic Server/Core Application Server / data-value nameINSTALL_TYPE valueComplete / /input-fields /bea-installer执行安装命令java -jar fmw_12.2.1.4.0_wls.jar -silent -responseFile /path/install.xml -invPtrLoc /path/oraInst.loc安装完成后检查目录结构确认wlserver目录存在。这里还有个容易被忽略的点安装路径不要包含空格和中文WebLogic的部分脚本对路径中的空格处理有历史遗留问题。2.3 创建域理解Domain、AdminServer与ManagedServer的关系第一次接触WebLogic的人会被Domain、AdminServer、ManagedServer这些概念绕晕。我用一句话解释Domain就是一套WebLogic的运行环境里面有一个管理员进程AdminServer负责管理若干个业务进程ManagedServer负责跑应用。集群就是把多个ManagedServer组织在一起统一归属AdminServer管理。双机部署的域规划我建议这样分配A机器AdminServer端口7001 ManagedServer1端口7002B机器ManagedServer2端口7003为什么要这样分因为WebLogic的管理功能很重AdminServer会消费一定的CPU和内存把它和第一个业务节点放一起能省下一台机器。但要注意如果A机器宕机AdminServer也随之不可用此时B机器上的业务节点仍然可以继续提供服务只是无法做管理操作。对业务连续性来说这是可以接受的折中方案。创建域用Configuration Wizard也可以执行WLST脚本。交互式创建方便直观但生产环境我建议写脚本保证两台机器的域基础配置一致。域创建完成后把$DOMAIN_HOME/config下的配置内容梳理清楚后续集群的创建和管理都是基于这个目录进行的。2.4 pack与unpack双机部署中传播域的标准姿势双机部署最容易犯的错误是手动在第二台机器上重新配置一遍域。WebLogic配置项非常多手配两台机器极易出现细微差异轻则集群注册失败重则整个集群起不来。正确做法是用WebLogic自带的pack和unpack工具把A机器上的域打包再到B机器上解包。在A机器上执行打包cd /opt/weblogic/oracle/wlserver/common/bin ./pack.sh -managedtrue -domain/home/weblogic/domains/base_domain -template/backup/base_domain.jar -template_namebase_domain把生成的jar包拷贝到B机器在B机器上执行解包./unpack.sh -domain/home/weblogic/domains/base_domain -template/backup/base_domain.jar注意pack时如果是管理服务器所在域的完整包要带-managedtrue参数生成受管服务器模板。unpack后B机器的域目录会和A机器保持完全一致包括用户、密码、集群配置等敏感信息。解包完成后需要根据B机器的实际情况修改监听地址相关的配置这个后面在集群配置章节细说。3. 集群创建与双机部署实操记录3.1 在AdminServer上创建集群并配置集群地址域创建完成后登录AdminServer控制台地址是http://A机器IP:7001/console。用创建域时设置的weblogic管理员账号登录进入环境-集群菜单新建一个集群。集群名称我用的是ProductionCluster这个名称后续在应用部署和脚本中都会用到。创建集群时有两处配置要格外注意。第一是集群消息模式分单播和组播。组播依赖网络设备支持云环境和不规范的办公网络经常禁组播导致节点互相发现不了。WebLogic 12c之后默认推荐单播模式我也一直用单播省心而且稳定。第二是集群地址Cluster Address这个配置项必须填它决定了集群服务器之间通信时使用的地址列表。双机场景下填两台机器的IP加受管端口中间用逗号分隔例如192.168.1.10:7002,192.168.1.11:7003如果你使用了负载均衡器的虚拟IP也可以填虚拟IP对应端口但我更推荐直接填物理地址避免中间环节影响集群内部的通信探测。3.2 配置Machine与Node Manager把第二台机器纳入管理WebLogic的受管服务器有三种启动方式命令行启动、脚本启动和通过Node Manager托管。生产环境强烈建议用Node Manager托管因为AdminServer可以通过Node Manager远程启动、停止受管服务器故障时能自动重启也方便日常运维。要启用Node Manager托管先在AdminServer控制台的“环境-计算机”里新建Machine指定A机器和B机器的IP地址和Node Manager端口默认5556。然后在“环境-服务器”里把ManagedServer1和ManagedServer2分别归属到对应的Machine上再分别设置每个服务器的监听地址。Node Manager的配置在$DOMAIN_HOME/nodemanager/nodemanager.properties关键参数ListenAddressB机器IP ListenPort5556 SecureListenerfalseListenAddress要填对应机器的实际IP不能留空让它自己猜。SecureListener这里我先关掉SSL降低联调时的复杂度生产环境建议打开并配置证书。启动Node Manager命令cd $DOMAIN_HOME/bin ./startNodeManager.sh启动成功后回控制台的“环境-服务器”页面选择受管服务器点启动按钮就能看到Node Manager远程拉起进程的全过程。这一步也是检验双机网络和防火墙是否放通的最直接方式。3.3 双机受管服务器加入集群并验证节点发现所有配置完成后按顺序启动服务。正常情况下先从A机器启动AdminServer然后通过Node Manager或命令行启动A机器的ManagedServer1再启动B机器的ManagedServer2。观察启动日志关注两个关键信息。一是角色的确认日志里会输出类似“Server started in RUNNING mode”的提示。二是集群成员发现日志中会出现当前节点尝试连接集群地址的记录。等两个节点都起来后登录控制台进入“环境-集群”点开ProductionCluster的监视页签应该能看到两个受管服务器都处于RUNNING状态且运行模式为“集群”。如果B机器的ManagedServer2起来了但集群监视里始终看不到它大概率是以下三类问题B机器到A机器的管理端口不通B机器无法访问集群地址中的A机器端口两台机器的主机名或域名解析异常。排查时先看B机器受管服务器日志里面会明确写出连接不上哪个地址。我曾经遇到过因为B机器防火墙没放通到A机器7002端口的TCP访问节点日志里反复报ping失败放通后问题立即消失。3.4 部署应用并验证会话复制与负载均衡集群搭好只是第一步应用能正常跑起来且会话能复制才是目的。在控制台“部署”菜单中点击安装选择应用包目标选择ProductionCluster。这里有一个部署模式的选择分为stage模式、nostage模式和external_stage模式。stage模式下AdminServer会把应用包推送到每个集群节点的暂存目录适合集中式管理nostage模式直接使用AdminServer上的应用包路径适合双机共享存储或保证各节点本地路径一致external_stage模式适合发布系统已经把包分发到各节点的情况。我这次用的是nostage因为发布脚本会把应用包同时分发到A、B两台的相同目录部署时指定这个目录两个节点加载的是本地副本避免stage模式在包较大时拖慢部署速度。部署完成后写一个简单的测试页面往session里塞一个时间戳再读出来% String ts session.getAttribute(timestamp) null ? String.valueOf(System.currentTimeMillis()) : (String) session.getAttribute(timestamp); session.setAttribute(timestamp, ts); % % ts % | 当前节点: % System.getProperty(weblogic.Name) %部署后通过负载均衡器访问多次刷新能看到请求在两个节点间轮询同一个session的值始终保持不变。此时手动kill掉其中一个受管服务器进程刷新页面会发现另一个节点接管session里的时间戳没有变化这说明会话复制生效了。如果看不到这个效果去查会话复制配置和应用的序列化情况这是下一章的重点。4. 集群里的核心配置细节数据源、会话复制、防火墙与安全加固4.1 JDBC数据源与连接池参数别用默认值裸奔应用访问数据库不能每个节点各连各的必须在集群里统一配置JDBC数据源并把它部署到集群目标上。在控制台“服务-数据源”中新建数据源填入数据库连接URL、驱动和账号测试连接通过后目标选择ProductionCluster。数据源配置看着简单但连接池参数最容易被忽略。默认的初始容量、最大容量往往不适合生产业务。我通常这样设置参数建议值说明初始容量5-10冷启动时预留的连接数太小了高峰期易排队最大容量50-100根据应用并发量和数据库上限设置太大拖垮数据库Statement缓存大小20-50减少SQL解析开销对高频查询有明显效果连接测试语句SELECT 1 FROM DUAL防止连接被网络设备或数据库端静默断开数据源还有一个容易踩的坑集群场景下每个节点的数据源是独立维护各自连接池的数据库连接无法像HttpSession那样复制。也就是说一台机器宕机后另一台机器的数据源连接池必须能独立支撑全部流量。所以双机部署时单节点的连接池上限要按“能扛住全部业务”的标准来配置而不是按50%流量来配。如果预算允许、数据库也支持可以进一步配置多数据源Multi Data Source实现数据库层的故障转移但对事务一致性要求严格的系统要小心XA事务带来的性能损耗这个不在这次的讨论范围内有兴趣的可以单独研究。4.2 会话复制的工作原理与配置要点WebLogic集群的会话复制是基于内存的复制机制节点会把会话变化通过单播或组播消息同步到集群内的其他节点。这个机制用法很简单但坑也不少。首先要强调对象可序列化。会话里存放的对象必须实现java.io.Serializable接口否则复制会失败。问题在于WebLogic的日志里不一定显式报错而是默默地在后台记录异常业务上表现为“偶发性掉登录”。排查这个问题唯一有效的办法是检查受管服务器日志中是否有NotSerializableException相关记录。其次是复制范围。WebLogic默认采用“邻近复制”策略每个会话会复制到一个邻近节点而不是广播到集群所有节点。这样设计是为了减少网络开销。如果两台机器互为备份正好天然匹配。如果集群超过两个节点就要显式配置复制组Replication Group让会话能正确落到预期的备份节点上。第三是会话过大问题。如果业务系统把大对象直接塞进session比如把一个10MB的列表放进去每次请求变化都复制一次网络成本不容小觑。生产环境我见过一个系统因为session里放了大对象的引用两个节点之间的网络流量暴涨现象是页面越来越卡。排查下来罪魁祸首就是会话复制。所以在架构层面尽量只往session里放必要的状态数据大数据量场景优先考虑分布式缓存。4.3 防火墙、端口清单与安全加固建议双机部署涉及多组端口我把这次项目的完整端口清单整理如下服务端口说明AdminServer7001管理控制台和管理通道必须限制来源IPManagedServer17002A机器业务端口ManagedServer27003B机器业务端口Node Manager5556管理服务器远程启停受管服务器用集群单播通信随机或指定端口节点间会话复制和心跳通信这些端口在防火墙或云安全组上都要双向放通。实际操作中常见的坑是只放了业务端口和管理端口漏了集群通信端口结果是节点能注册上但会话复制一直失败。集群通信端口具体是多少可以在启动日志里找到线索也可以在创建集群时显式指定单播端口比如设置为9001方便管理和放通。安全加固方面这里说几点实用的。管理控制台和AdminServer应限制来源IP只允许运维网段访问通过防火墙规则或WebLogic的Network Channel配置实现。生产环境如果应用不需要T3协议建议通过全局安全筛选器禁用这是针对WebLogic历史上公开过的反序列化漏洞最直接有效的缓解措施。还要及时关注Oracle官方发布的补丁按变更窗口定期升级。WebLogic控制台默认账密一定要改掉示例应用和默认文件不要部署到生产环境。4.4 日志管理与进程守护WebLogic日志分散在多个位置出问题时先分清看哪个。$DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log管理服务器日志$DOMAIN_HOME/servers/ManagedServer_1/logs/ManagedServer_1.log业务节点日志$DOMAIN_HOME/servers/ManagedServer_1/logs/ManagedServer_1_access.logHTTP访问日志集群相关的问题比如节点互相发现失败、会话复制异常都会记在对应受管服务器的日志里排查时用grep过滤关键字比如Cluster、Replication、Remote等。日志文件默认会无限增长需要在管理控制台配置日志文件滚动策略按文件大小或天数切割并清理保留份数。我一般设置单个文件50MB、保留20个文件这样一个节点日志量控制在1GB左右。进程守护方面Node Manager本身是守护受管服务器的第一道防线但Node Manager进程自身挂了怎么办生产环境建议把Node Manager配置成操作系统服务systemd开机自启动这样链路才完整。AdminServer我习惯单独用systemd管理因为如果AdminServer挂了Node Manager的托管功能也随之不可用。5. 问题排查与经验总结5.1 我遇到过的几个典型故障与处理过程故障现场往往比预想的诡异这里挑几个印象深刻的记录一下。第一个是B机器受管服务器一直报“Cannot connect to AdminServer”。启动日志反复出现连接被拒绝。我先telnet A机器7001端口通的再telnet B机器到A机器的7001也是通的最后发现是B机器受管服务器的启动参数里监听地址配置成了自己原有的旧IP修改为正确的IP后恢复正常。原因就是unpack后没有根据B机器实际网卡地址调整监听配置。第二个是节点注册成功但集群监视里只有一个节点。两台机器都用Node Manager启动ManagedServer1正常ManagedServer2启动报“Unable to ping at cluster address”。排查发现是防火墙没有放通A机器7002到B机器7003之间的TCP通信集群内部无法互ping。放通后问题解决。第三个是会话复制间歇性失败用户反馈偶尔要重新登录。查ManagedServer日志发现大量NotSerializableException定位到应用里有个工具类没有实现Serializable接口。这个故障最有迷惑性因为不是每次请求都复制有时候能成功有时候失败如果不看日志根本发现不了。我用一个表格把这些典型问题整理出来现象可能原因排查步骤解决方案受管服务器连不上AdminServer监听地址错误、端口未放通telnet测试、检查监听地址配置修改监听地址、放通端口节点加入不了集群集群通信端口不通、主机名解析异常看受管日志、检查hosts放通端口、修正hosts会话复制失败对象不可序列化、复制组配置缺失搜索NotSerializableException实现Serializable、配置复制组启动超时堆内存配置过大、机器负载高观察启动日志、检查资源占用调整启动超时时间、优化参数5.2 双机部署中最容易被忽略的五个小细节经历了几次从零搭建双机集群之后我发现真正让人掉坑的并不是某个高深的技术而是细节一致性。这里列出五个最常见的细节建议搭建前逐项核对。第一主机名解析必须双向。A机器要能解析B机器的主机名B机器也要能解析A机器的主机名并且IP要和实际网卡IP一致。不要图省事只写一台。第二集群地址不能漏配。控制台上创建集群后如果集群地址留空集群内部通信就无法建立节点互相发现全靠运气。第三两台机器的JDK和WebLogic补丁要完全一致。差一个小版本可能导致序列化兼容问题这种问题极难定位。第四部署模式和本机路径要提前规划好。用stage模式时如果B机器没有暂存目录的写权限部署会失败用nostage模式时两台机器的应用路径必须一致。第五操作系统时间要同步。时间偏差超过一定阈值WebLogic会直接拒绝认证请求报错信息还不是很明确容易误导排查方向。5.3 故障演练与日常运维建议集群搭建完成后一定要做一次真实的故障演练别等生产出事了才第一次面对切换场景。我的演练步骤很简单但很有效先从负载均衡器断开A机器节点观察B机器是否正常接管全部流量然后直接kill掉A机器的ManagedServer进程模拟宕机观察B机器上已登录用户的会话是否保持最后重新启动A机器的ManagedServer观察它是否自动重新加入集群并同步状态。演练中容易发现两个隐藏问题。一是负载均衡器的健康检查配置不对没把宕机节点及时摘除导致部分请求被路由到故障节点用户看到502或超时。二是数据源连接池需要一段时间才能重建全部连接刚恢复的节点如果一上来就承接大流量数据库连接会瞬间被打满。所以生产环境建议配置受管服务器启动后的预热时间让连接池慢热起来。日常运维中定期备份域目录是必须养成的习惯。$DOMAIN_HOME目录不大但包含全部配置和密码信息每天凌晨打包备份一次配合保留多份历史版本出问题能快速回滚。日志清理也要做定时脚本避免日志占满磁盘导致服务异常。此外WebLogic的安全补丁要按变更管理流程定期评估不能因为“系统稳定运行就不动它”毕竟WebLogic历史上公开过不少漏洞不及时修补相当于把业务系统裸奔在公网上。5.4 集群运维的其他经验谈在多年的运维经验中我发现集群运维的难点不在“搭建”而在“日常管理”。双机集群意味着有两份配置、两份日志、两份进程需要管理运维成本不会因为用了集群就减少反而会有所增加。所以建议把常用操作脚本化比如统一重启脚本、日志收集脚本、健康检查脚本用标准化流程减少人为操作的差异。还有一个容易被忽略的点是集群与其他分布式系统的边界。WebLogic集群解决的是应用层的可用性和横向扩展数据库层的可用性不是WebLogic能管的缓存层的分片一致性也不是它管的。如果业务系统还有依赖的MySQL、Redis等组件那些组件本身还需要自己的高可用方案别指望一个WebLogic集群包办所有环节。在这个项目里我把数据库做了主从应用层用WebLogic集群整体才算真正闭环。写在最后这次WebLogic双机集群和双机部署做下来我最大的体会是技术本身不难难的是两台机器的一致性。很多故障看着像配置问题追根溯源都是环境差异导致的要么JDK版本不一致要么hosts解析不同要么防火墙规则漏了一条。所以我后来每次搭建集群都会先写一份checklist把IP、端口、版本号、路径这些基础信息列全逐项核对后再动手效率反而比边做边查高得多。最后再分享一个实际经验如果你熟悉了WebLogic集群里的节点发现、心跳通信、状态同步这些机制再去接触K8s的Pod多副本、Hadoop的NameNode/DataNode、Spark的Driver/Executor你会发现它们在集群设计思路上是共通的。传统中间件的集群经验完全可以迁移到这些分布式系统上。先把WebLogic双机这套玩透后面学任何分布式组件都会顺畅许多。