我们正在AWS ECS上使用eureka运行spring-cloud微服务。我们还在进行连续部署，并且遇到了一个问题，即滚动生产部署会导致一小段服务不可用的窗口。我将重点放在使用功能区的@LoadBalanced RestTemplate客户端上。我想我已经可以在本地测试环境中重试正常工作，但是我担心新的服务实例eureka注册滞后时间和ECS滚动部署的工作方式。
当我们合并对master的新提交时，如果构建通过（编译和测试通过），我们的jenkins管道就会构建并将新的docker映像推送到ECR，然后创建一个指向已更新的docker映像的新ECS任务定义修订版，并更新ECS服务。例如，我们有一个ECS服务定义，其期望任务计数设置为2，最小可用百分比设置为100％，最大可用百分比设置为200％。 ECS服务调度程序会使用新映像启动2个新的Docker容器，而现有2个docker容器将在旧映像上运行。我们使用容器运行状况检查，一旦执行器运行状况端点返回200，容器运行状况检查就会通过，一旦发生，ECS服务调度程序就会停止在旧docker映像上运行的2个旧容器。
我在这里的理解可能是不正确的，所以如果我对任何这些都不对，请纠正我。 Eureka客户端每30秒获取一次注册表，因此最多30秒钟，服务器列表中所有客户端都是旧服务实例，因此重试将无济于事。
我询问了AWS支持有关如何在滚动部署期间延迟ECS任务终止的问题。当ECS服务与ALB目标组相关联时，存在ECS遵守的注销延迟设置，但是当不涉及负载平衡器时，则不存在这样的选项。 AWS的响应是通过这样的入口点bash脚本运行Java应用程序：
#!/bin/bash
cleanup() {
date
echo "Received SIGINT, sleeping for 45 seconds"
sleep 45
date
echo "Killing child process"
kill -- -$$
}
trap 'cleanup' SIGTERM
"${@}" &
wait $!
当ECS终止旧实例时，它将SIGTERM发送到docker容器，此脚本将其捕获，休眠45秒，然后继续关闭。我还必须在/ etc / ecs中更改一个ecs config参数，该参数控制宽限期，然后ECS在SIGTERM之后发送SIGKILL之前，默认为30秒，这还不够长。
这对我来说很肮脏。我不确定该脚本不会引起其他无法预料的问题。是否正确转发所有信号？感觉像是不必要的并发症。
我想念什么吗？有人能发现AWS支持人员建议的入口点脚本方法有什么问题吗？是否有更好的方法来处理此问题并达到预期的结果，即在ECS上在eureka中注册的服务上进行零停机滚动部署？