目录
一、现有部署方案介绍
二、Nacos 介绍
三、影响时间的因素
四、方案目录结构
五、方案脚本实现
六、遇到的问题及优化
七、其他替代方案
一、现有部署方案介绍
在程序开发和运维过程中，会频繁地部署服务，并且每个服务的正常运行都依赖于其他服务，所以能够在不停服的情况下部署新版本服务来保持应用的整体稳定性可用性十分重要。
不停服部署有3种常见的发布部署模式。
滚动部署：滚动更新是一种逐步部署的方式，它逐步替换集群中的旧版本实例，同时保持应用程序的整体可用性。这个过程可以是自动化的，并且可以根据需要控制更新的速度和批次大小。
- 优点：保证了服务在整个更新过程中持续可用。可以控制更新速度，减少风险。
- 缺点：如果新版本有严重问题，可能会影响到一部分用户。更新过程中资源管理复杂。
灰度发布：灰度发布（也称作金丝雀发布）是指将新版本首先部署给一小部分用户或者流量，然后根据新版本的表现决定是否扩大部署范围。这允许团队在全面发布之前测试新功能或修复的效果。
- 优点：可以在实际环境中验证新版本，降低风险。用户反馈可以帮助及时调整或回滚，提高产品质量。
- 缺点：需要一套复杂的规则来决定哪部分用户或流量接受新版本。监控和分析新版本表现需要额外的工具。
蓝绿部署：蓝绿部署是一种零停机时间的部署策略，它通过同时维护两个生产环境（一个是当前活跃的“Blue”环境，另一个是待部署的“Green”环境）来实现。在新版本准备就绪时，流量从Blue环境无缝切换到Green环境。如果新版本有问题，可以快速回滚到Blue环境，无需停机。
- 优点：确保了高可用性，因为随时有一个完全运行的环境可以服务用户。回滚过程快速且风险低。
- 缺点：需要双倍的基础设施资源。
每种部署方案都有其特定的应用场景和优势，结合我们应用的系统架构、部署运维情况，确定利用nacos open-api可实现服务上下线的特性,编写shell脚本实现蓝绿部署方案.
二、Nacos 介绍
Nacos是一款支持服务发现、配置管理和服务管理的平台，专为微服务架构设计，提供动态配置更新、健康检查、服务注册与发现等核心能力。
Nacos的服务管理有上下线服务的功能,且有open-api可直接调用触发。
Nacos api官方地址: https://nacos.io/zh-cn/docs/open-api.html
Enabled可控制服务上下线: true s上线. false: 下线
注意: postman调用时, 不可带http相关头参数, 只保留Host即可。
三、影响时间的因素
Nacos的心跳机制
心跳机制可表示当前微服务模块运行状态是否正常, 还有和当前微服务模块保持沟通和交换信息。
默认情况下,服务启动开始每隔5秒会想Nacos发送一个"心跳包",这个心跳包中包含了当前服务的基本信息。
Nacos接收到这个心跳包,首先检查当前服务在不在注册列表中,如果不在按新服务的业务进行注册,如果在,表示当前这个服务是健康状态。
如果一个服务连续3次心跳(默认15秒)没有和Nacos进行信息的交互,就会将当前服务标记为不健康的状态。
如果一个服务连续6此心跳(默认30秒)没有和Nacos进行信息的交互,Nacos会将这个服务从注册列表中剔除。
这些时间可以通过配置修改，服务上线时间, 不能小于5。
nginx超时时间
nginx设置超时时间为65, 故下线时间需设置的比nginx长一些即可
服务启动时间
一般启动时间20秒左右。
异常情况: 启动时间超过了80秒,导致服务上线失败, 后续服务提前kill了
总结:
1. 下线的等待时间 不能小于nginx超时时间. 下线时间到,才可kill；
2. 上线前等待时间 不能小于服务启动时间 + nacos的注册发现时间；
3. 上线后等待时间 不能小于nacos同步时间。
四、方案目录结构
nacos-test(Blue环境): 主启动目录, 日常运行
nacos-test-duplicate(Green环境): 备份启动目录, 重启时运行
nacos-test-jar: 新升级的jar包暂存区. (解决jar包覆盖, 导致classNotFound错误)
五、方案脚本实现
脚本结构:
重启服务脚本: restart.sh
一个服务的重启脚本, 所有服务都调用此脚本
入参: jar包名, 端口号
蓝绿部署控制脚本: restart-double.sh
重启脚本: 各个服务调用的入口
传入参数: jar名, serviceName, dev环境端口, DUPLICATE端口。
整个重启过程不到6分钟. 可根据实际情况,调整等待时间(时间设置可参考: 影响时间的因素)。
# 下线等待时间
WAIT_TIME_OFF=70
# 上线前 等待时间
WAIT_TIME_ON_BEFORE=36
# 上线后 等待时间
WAIT_TIME_ON_AFTER=36
具体服务启动脚本: run-ssp-cloud-base.sh
以base服务为例:
格式如下: 就是调用restart-double.sh传入所需参数及设置日志即可
sh restart-double.sh ssp-cloud-base base-application 16001 16101 >> logs-console/start_sh_log/run-ssp-cloud-base.log 2>&1 &
六、遇到的问题及优化
1.重启过程中jar包覆盖, 导致classNotFound错误.
-- 解决办法: 单独目录存放要升级的jar, 不要覆盖正在运行的jar.
2.Jar包保留上一次发版做备份, 失败时,可随时回滚上一版本.
-- cp -f /project/${JAR_NAME}.jar /project/jar_bak/${JAR_NAME}.jar
3.服务启动时间变长,要80秒左右
-- 延长等待时间,
-- 加shell循环等待,判断服务是否可用.
4.频繁重启,导致上下线混乱的问题,
-- 加文件标记重启状态, 循环等待(shell脚本如下:).
重启完成后解锁
七、其他替代方案
Nginx作为负载均衡器, 也可实现蓝绿部署.
可行方案: nginx配置文件shell脚本替换指定字符..
作者：刘金龙| 资深后端开发工程师
版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。
公众号搜索神州数码云基地，后去更多技术干货。
