本文介绍在无法升级 jboss 5 的前提下，通过轻量级 servlet 健康端点 + aws alb 原生健康检查机制，实现对 9 台 soap 服务节点的自动扩缩容与故障剔除，避免自研代理或逐个封装千级 webservice 的高成本方案。
本文介绍在无法升级 jboss 5 的前提下，通过轻量级 servlet 健康端点 + aws alb 原生健康检查机制，实现对 9 台 soap 服务节点的自动扩缩容与故障剔除，避免自研代理或逐个封装千级 webservice 的高成本方案。
在遗留系统运维中，常面临“技术锁定”困境：业务强依赖 JBoss 5（2010 年发布），EJB 架构、SOAP 协议、无 REST 接口，且 AWS 上已部署 9 台同构应用服务器，亟需基于真实业务健康状态（而非仅 TCP 连通性）进行动态流量调度。关键约束在于：AWS ALB 默认健康检查要求 HTTP GET 请求，而原生 SOAP 服务不暴露 GET 端点。
最优解并非重写负载均衡器，而是“桥接协议语义”：在现有 JBoss 5 应用中注入一个轻量级健康探测 Servlet，作为 ALB 与底层 EJB 服务之间的语义适配层。
✅ 实施步骤（零侵入、低代码、高兼容）
-
新增 HealthCheckServlet（部署于同一 WAR）
创建标准 javax.servlet.http.HttpServlet，映射至 /health（如 @WebServlet("/health")），在 doGet() 中执行最小化业务探活逻辑：
@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 {
// 方式1：调用本地 EJB Home 接口（推荐，零网络开销）
InitialContext ctx = new InitialContext();
MyStatelessBeanLocal bean = (MyStatelessBeanLocal)
ctx.lookup("java:comp/env/ejb/MyStatelessBean");
boolean isHealthy = bean.ping(); // 自定义 ping() 方法，仅校验核心依赖（DB 连接池、JNDI 绑定等）
// 方式2：若 EJB 无 ping 方法，可模拟一次轻量 SOAP 调用（注意超时控制）
// SoapClient.invoke("http://localhost:8080/MyApp/MyService", "ping");
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("{\"status\":\"DOWN\",\"error\":\"" + e.getMessage() + "\"}");
}
}
}⚠️ 注意事项：
- 严禁在 doGet() 中执行耗时操作（如全量数据库查询、远程服务调用）。ping() 方法应仅验证核心依赖（如 HikariCP 连接池活跃连接数 > 0、JNDI lookup 成功）。
- 设置合理的 ALB 健康检查参数（建议：健康阈值 2 次成功、不健康阈值 2 次失败、超时 5 秒、间隔 30 秒），避免因瞬时抖动误判。
- 确保 /health 不受安全框架拦截（如 JBoss Seam 或自定义 Filter 需放行该路径）。
-
配置 AWS ALB Target Group
- 将 9 台 JBoss 5 实例注册为 Target Group 的目标（端口 8080）；
- 在 Target Group 健康检查设置中：
- Protocol: HTTP
- Path: /health
- Success codes: 200
- 其余参数按上述建议调整。
-
（可选）演进路径：API Gateway 作为现代化入口
若未来计划逐步迁移 SOAP 服务，可在 ALB 前叠加 Amazon API Gateway：- 将 ALB Endpoint 注册为 API Gateway 的 HTTP 后端；
- 利用 API Gateway 的缓存、限流、请求转换（SOAP → JSON）、日志审计能力；
- 后续将单个 SOAP 服务重构为 Lambda 函数时，仅需更新对应路由后端，前端调用无感知。
✅ 为什么这是最佳实践？
- 零 SOAP 封装成本：无需为 1000+ WebService 编写代理层，健康探活与业务逻辑解耦；
- 完全利用 AWS 托管能力：ALB 自动完成节点增删、流量切换、监控指标（TargetResponseTime, UnHealthyHostCount）；
- 符合云原生可观测性原则：健康状态直接反映业务可用性（非仅进程存活），且日志/指标可接入 CloudWatch；
- 平滑演进友好：/health Servlet 本身是标准 Java EE 组件，未来升级 JBoss 或迁移到 WildFly 时仍可复用。
? 总结：面对遗留系统，真正的架构智慧不在于推倒重来，而在于用最小改动打通新老技术栈的语义鸿沟。一个 50 行的 Servlet，即可激活 AWS 全套弹性能力——这正是云迁移中“杠杆效应”的经典体现。
