在云效发布JAVA两台机器，中途业务会停止一段时间，怎么回事？

在云效发布Java应用到两台机器时，如果中途业务会停止一段时间，可能是由于以下原因导致的。以下是详细分析和解决方法：

1. 部署策略配置问题

在云效中，主机部署任务支持分批发布和暂停机制。如果未正确配置分批发布或暂停方式，可能会导致两台机器同时停止服务。

原因：

• 如果分批数量设置为“不分批”或“同时发布”，两台机器会同时进行部署操作，导致业务中断。
• 如果未启用暂停方式（如第一批暂停），所有机器会在同一时间执行部署脚本，可能导致服务不可用。

解决方法：

• 在主机部署任务中，合理配置分批数量和暂停方式：
  • 分批数量：将两台机器分为两批，每批只发布一台机器。
  • 暂停方式：选择“第一批暂停”，在第一批机器发布完成后，观察线上服务是否正常，再继续发布第二批机器。
  • 示例配置：
  • 分批数量：2批（每批1台机器）。
  • 暂停方式：第一批暂停。

2. 部署脚本未实现平滑重启

部署脚本中如果没有实现平滑重启逻辑，可能会导致服务在部署过程中短暂中断。

原因：

• 部署脚本中直接使用了restart命令（如sh deploy.sh restart），而未考虑服务的优雅停机和启动过程。
• 例如，旧服务可能在新服务启动之前被强制终止，导致请求无法处理。

解决方法：

• 修改部署脚本，确保服务能够平滑重启：
  • 在deploy.sh中添加优雅停机逻辑，例如：

  # 停止旧服务前等待当前请求处理完成
  kill -15 $(pgrep java) && sleep 5
  

  • 确保新服务启动后再停止旧服务，避免服务中断。
  • 示例脚本：

  # 启动新服务
  nohup java -jar app.jar > app.log 2>&1 &
  # 等待新服务启动完成
  sleep 10
  # 停止旧服务
  kill -15 $(pgrep java)
  

3. 负载均衡未正确配置

如果两台机器通过负载均衡对外提供服务，但负载均衡未正确配置健康检查或流量切换策略，可能会导致业务中断。

原因：

• 负载均衡未及时检测到某台机器的服务状态变化，仍然将流量转发到正在部署的机器上。
• 部署过程中，服务可能处于不可用状态，但负载均衡未及时剔除该机器。

解决方法：

• 确保负载均衡配置了正确的健康检查策略：
  • 设置健康检查路径（如/health），并确保服务在启动后能够返回健康状态。
  • 配置负载均衡的流量切换策略，确保在服务不可用时自动剔除该机器。
  • 示例配置：
  • 健康检查路径：/health
  • 健康检查间隔：5秒
  • 不健康阈值：3次

4. 人工卡点缺失

如果流水线中未添加人工卡点，可能会导致未经验证的制品直接进入生产环境，增加业务中断的风险。

原因：

• 流水线中缺少人工审核机制，未经测试验证的制品直接部署到生产环境。
• 部署过程中发现问题时，无法及时回滚。

解决方法：

• 在流水线中添加人工卡点：
  • 在主机部署任务前添加人工审核步骤，确保只有经过验证的制品才能进入生产环境。
  • 示例配置：
  • 卡点名称：生产环境发布审核
  • 验证人：运维负责人或测试负责人

5. 回滚机制未启用

如果部署失败或业务中断，未启用回滚机制可能会导致问题持续存在。

原因：

• 未配置历史版本回滚功能，导致在部署失败时无法快速恢复到之前的稳定版本。

解决方法：

• 启用云效的回滚功能：
  • 在流水线运行页面，单击部署历史，选择需要回滚的版本。
  • 示例操作：
  • 回滚到版本#2：单击版本#2的回滚按钮。

总结建议

为了避免业务中断，建议按照以下步骤优化发布流程： 1. 配置分批发布和暂停机制，确保每次只更新一台机器，并在第一批发布完成后观察服务状态。 2. 优化部署脚本，实现服务的平滑重启，避免直接终止旧服务。 3. 检查负载均衡配置，确保健康检查和流量切换策略正确。 4. 添加人工卡点，确保只有经过验证的制品才能进入生产环境。 5. 启用回滚机制，在部署失败时快速恢复到稳定版本。

通过以上措施，可以有效减少业务中断时间，提升发布的稳定性。