本文介绍在无法升级 jboss 5 的前提下，通过轻量级健康端点 + aws alb 实现动态服务发现与自动扩缩容的生产级负载均衡方案，避免自研代理的高维护成本。
本文介绍在无法升级 jboss 5 的前提下，通过轻量级健康端点 + aws alb 实现动态服务发现与自动扩缩容的生产级负载均衡方案，避免自研代理的高维护成本。
在 AWS 环境中为运行于 JBoss 5 的遗留 EJB/SOAP 应用实现智能负载均衡，关键在于解耦健康探测逻辑与业务协议。由于 SOAP 协议不支持直接用于 HTTP 健康检查（如 AWS ALB 要求的 GET 请求），且手动为上千个 WSDL 接口编写代理层既不可行也不可持续，推荐采用“内嵌轻量健康 Servlet + 标准化 ALB 集成”架构，兼顾兼容性、可维护性与云原生能力。
✅ 推荐方案：在现有 WAR 中注入健康检查 Servlet
无需修改业务逻辑或 EJB 层，只需向当前部署的 WAR 包中添加一个极简的 HealthCheckServlet，并确保其映射到标准 HTTP 路径（如 /health）：
// src/main/java/com/example/HealthCheckServlet.java
@WebServlet("/health")
public class HealthCheckServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
try {
// 示例：调用本地 EJB 或核心服务验证可用性（非网络调用，零额外依赖）
InitialContext ctx = new InitialContext();
MySystemService service = (MySystemService) ctx.lookup("java:global/myapp/MySystemService");
boolean isHealthy = service.isOperational(); // 自定义健康逻辑
if (isHealthy) {
resp.setStatus(HttpServletResponse.SC_OK);
resp.getWriter().write("{\"status\":\"UP\"}");
} else {
resp.setStatus(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
resp.getWriter().write("{\"status\":\"DOWN\"}");
}
} catch (Exception e) {
resp.setStatus(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
resp.getWriter().write(String.format("{\"status\":\"DOWN\",\"error\":\"%s\"}",
e.getMessage().substring(0, Math.min(100, e.getMessage().length()))));
}
}
}? 关键设计说明：该 Servlet 运行在 JBoss 5 同一 JVM 内，直接调用本地 EJB 或数据源连接池验证，不发起任何远程 HTTP/SOAP 调用，规避了协议限制与性能开销，同时满足 ALB 对响应时间（默认 < 5s）、状态码（2xx/3xx 视为健康）和路径可访问性的要求。
⚙️ AWS ALB 配置要点
- 目标组设置：将全部 9 台 JBoss 实例注册至同一目标组；
-
健康检查配置：
- 路径：/health
- 协议：HTTP（或 HTTPS，若启用 SSL 终止）
- 健康阈值：3（连续成功次数）
- 不健康阈值：3（连续失败次数）
- 超时：5 秒｜间隔：30 秒（可根据实际响应微调）
- 粘性会话（可选）：若应用存在强 Session 依赖，启用 ALB 的基于 Cookie 的会话保持（注意：EJB 容器级集群需配合 JBoss 5 的 jboss-web.xml 中 <distributable/> 和 mod_jk 配置）。
? 为什么不建议自研负载均衡器？
- 协议复杂性：SOAP 消息解析、WSDL 动态路由、MTOM/Binary 处理、WS-Security 兼容等将引入大量不可控风险；
- 运维负担：需自行实现连接池管理、熔断降级、指标埋点（如 Prometheus）、日志追踪（如 OpenTracing），远超 ALB 原生能力；
- 扩展瓶颈：当实例数从 9 扩至 50+ 时，自研组件将成为单点故障与性能瓶颈。
? 进阶建议：面向演进的 API 网关分层
若未来计划逐步迁移，可在 ALB 前叠加 Amazon API Gateway（HTTP API 类型）作为统一入口：
- 将 /soap/* 路由代理至 ALB；
- 新增 RESTful 接口（如 /v1/orders）由 Lambda 或新微服务承接；
- 利用 API Gateway 的缓存、限流、JWT 验证、请求转换（SOAP-to-REST）能力平滑过渡。
✅ 总结：对 JBoss 5 遗留系统，最务实的负载均衡实践是「最小侵入式健康暴露 + 云平台托管负载均衡」。仅需新增一个不超过 50 行的 Servlet，即可激活 AWS ALB 的全自动实例生命周期管理，彻底规避重复造轮子，为后续现代化演进保留清晰路径。
