WebLogic在Ubuntu上的高可用方案

架构总览

1. 在 Ubuntu 上构建 WebLogic 高可用，通常采用“多节点集群 + 网络负载均衡 + 会话保持/复制 + 共享存储/共享数据库 + 监控与自动恢复”的组合架构。
2. 建议至少部署 2 台物理机/虚拟机，每台运行 1 个管理服务器（AdminServer）+ 1 个或多个受管服务器（Managed Server），受管服务器加入同一 集群（Cluster），由 网络负载均衡器（如 HAProxy/Nginx/商用 F5） 对外提供统一入口。
3. 会话保持与故障转移：优先使用 In-Memory Replication（内存复制） 或 JDBC 复制 保障无状态横向扩展；对数据库等状态服务使用 主从/集群 与 应用级重试。
4. 共享资源：应用包与静态资源建议放在 共享文件系统（如 NFS） 或对象存储；日志与诊断数据集中到 集中式日志/监控 平台。

实施步骤

1. 环境与基础
   1. 安装受支持的 JDK，创建 weblogic 系统用户与目录，配置 sudo 与 systemd 服务单元；内核与文件句柄按 Java 应用调优（如提高 fs.file-max 等）。
2. 安装与域规划
   1. 安装 WebLogic，创建 域（Domain） 与 集群，在域中规划 AdminServer + 多个 Managed Server；各受管服务器分布在不同 Ubuntu 节点。
3. 节点管理与启动
   1. 配置 Node Manager，在同一域下远程启停受管服务器；验证节点通信与健康检查。
4. 负载均衡与对外入口
   1. 部署 HAProxy/Nginx 或硬件 F5 作为前端，开启 HTTP/HTTPS 与 会话保持（如基于 JSESSIONID 的 cookie 插入/重写），对外暴露 VIP/DNS。
5. 应用部署与会话策略
   1. 将 EAR/WAR 部署到集群，启用 In-Memory Replication 或 JDBC 复制；对无状态服务优先“粘性会话 + 优雅降级”。
6. 数据库与消息高可用
   1. 数据库采用 主从/集群（如 MySQL InnoDB Cluster、PostgreSQL Patroni、Oracle RAC）；JMS 使用 持久化存储 与 多目标 策略。
7. 监控与告警
   1. 启用 WebLogic Administration Console/REST/ WLST 巡检；结合 Prometheus + Grafana 采集 JVM/线程/连接池/OS 指标并设置阈值告警。
8. 备份与演练
   1. 定期备份 域目录、应用、配置与数据库；进行 滚动升级 与 故障转移演练，验证 RTO/RPO 指标。

关键配置与参数建议

1. 线程与网络
   1. 在 config.xml 的 Server 配置中合理设置 Thread Count、Queue Length、Accept Backlog、Socket Readers；必要时启用 Native IO 提升吞吐。
2. JDBC 连接池
   1. 将 Initial Capacity 与 Max Capacity 设为接近，且 Max Capacity ≥ 工作线程数；开启 Statement Cache 并控制上限，避免泄漏。
3. JVM 与 GC
   1. 生产模式建议 -Xms 与 -Xmx 等值，减少堆抖动；选择合适的 GC 算法（如 G1/ZGC）并基于 暂停时间与吞吐 调优。
4. 粘性会话与复制
   1. 启用 In-Memory Replication 时配置 多播/单播 与 复制组；使用 JDBC 复制 时确保 表结构与索引 高效并定期校验复制延迟。
5. 操作系统
   1. 提升 文件描述符 与 网络/磁盘 I/O 能力；对高并发场景可启用 zswap/zram 缓解内存压力（结合应用与延迟要求评估）。

运维与监控要点

1. 健康检查与自动恢复
   1. 负载均衡器对 /health 或 /console 做 HTTP 200 探活；Node Manager 与 systemd 保证实例异常退出后自动拉起。
2. 容量与性能
   1. 持续观察 线程池使用率、队列积压、连接池占用、JVM GC 次数/停顿、磁盘/网络 I/O；结合 WLST/Prometheus 建立容量阈值与扩容机制。
3. 日志与诊断
   1. 启用 server.log、access.log、diagnostics.log 的 JSON 化 与 集中采集；对 Stuck Thread 与 慢查询 设置告警与根因分析流程。
4. 变更与回滚
   1. 采用 蓝绿/金丝雀 发布；保留 回滚版本 与 数据库迁移脚本 的可逆性；变更窗口内 限流与熔断 保护关键业务。

常见故障与排查清单

1. 节点无法加入集群
   1. 核对 集群名称、监听地址、端口、防火墙/安全组；检查 多播/单播 网络连通性与 Node Manager 状态。
2. 会话丢失
   1. 核对 会话复制策略 是否启用且健康；检查 负载均衡器会话保持 配置（cookie 名称/路径/域）；评估 复制延迟 与网络抖动。
3. 数据库连接耗尽
   1. 检查 Max Capacity、超时、泄漏；优化 SQL 与索引；必要时 扩容连接池 或引入 读写分离/连接治理。
4. 线程池饱和与响应变慢
   1. 分析 Stuck Thread、慢请求与阻塞锁；优化 线程数、队列、GC 与下游依赖；考虑 服务拆分 与 异步化。
5. 磁盘/内存压力
   1. 清理 旧日志/诊断文件，扩容 磁盘；评估 zswap/zram 与 JVM 堆 配比；限制 容器/进程 资源上限。

参考实践要点

1. 在 Linux/Ubuntu 上通过 WebLogic 集群 + 网络负载均衡 实现 高可用与负载均衡，集群可自动感知节点故障并路由流量，保障业务连续性。
2. 会话复制可采用 数据库复制、基于文件复制、内存复制 等方式，按一致性/性能要求选择；结合 HAProxy/Nginx 等负载均衡器提升可用性与可观测性。
3. 性能层面需结合 线程池、连接池、Native IO 等关键参数与 JVM/OS 调优，持续用 监控平台 验证调优成效。