前言
当前服务节点集群化架构，一个应用在发布期内，存在多个节点, 发布过程持续过久(30分钟以上)。
发布新版需要发布30分钟，基于tag回滚也需要这么长时间。这个在试错上的成本非常大。核心的问题在于，发版前的服务，和发版后的服务，不能共存。
引入【灰度服务器集群】, 将【正式服务回滚部署】优化成【旧服务流量切换】。该方式和原方式相比，差异在:
- 新旧服务共存。验收通过以前，只有灰度是基于新tag发布，正式服一直是旧tag。
- 流量切换没有时间开销。回滚部署，要部署很久。
如果可以发布前的节点，和发布后的节点，同时保持运行，在发布时，按照以下顺序:
- 发布新版本服务节点到【灰度服务器集群(2台以上,4核8G)】
- 通过ng，将流量切到灰度服务器集群。
- 线上回归测试。通过以后，将正式服务器发布。流量切回来。
灰度服务器集群
发布时，新版本的服务会临时构建发布在灰度服务器集群。验收通过后，该服务可以下线。
- 灰度服务器仅服务于无状态的服务。
- 灰度服务器，设置灰度集群入口(lb实现)。
- 灰度服务器，最少2台。
- 如果灰度服务器配置不高，发布过程，也优先选择人想对较少的时间发。
发布过程
- 发布前
- 发布新版服务到灰度并进行线上回归测试
- 回归结束, 更新正式服，并流量切回, 灰度服务离线。
问题预测
TCP的流量切换怎么实现。
发布前:
长连接域名解析规则里，填写的是【待更新应用】集群入口lb x.x.x.x
发布灰度:
lb x.x.x.x 将集群入口lb解析修改至灰度服务器lb
回归完毕,正式服构建结束:
lb x.x.x.x 解析修正回