关于灰度释放的讨论
灰度发布的核心思想是在不影响软件系统当前版本可用性的前提下，验证新版本的功能并发布。
所谓灰色区域，就是在生产环境中创建的与部署待验证新版本的生产环境版本相同的环境。
对于前端客户端程序来说，推送并安装了待验证的新版客户端程序的客户群构成了灰色地带。
创建一个灰色区域->；流量控制->；灰色区域验证->；正式发布/回滚
灰色区域用于验证新版本的部署和功能。灰色发布的关键是将新版本部署到生产环境中，并在验证后发布。那么在正式发布之前，如何部署和验证新版本呢？这其实就是制造灰色地带的问题，那么如何制造灰色地带呢？
典型的做法是首先淘汰在生产环境中运行的集群节点，然后部署一个新版本来创建一个灰色区域。在验证开始之前，禁止将生产流量路由到灰色区域。
选择群集中失效节点的可能方法有:
1)如果只有一个集群，可以选择集群中的少量应用服务节点(就像金丝雀发布选择金丝雀节点一样)。
2)如果有多个集群(例如，跨IDC的多活动系统)，您可以选择其中一个进行淘汰。
在同一个生产环境中，部署一组完全冗余的集群节点，部署一个新版本，构建一个灰色区域(类似蓝绿发布)。根据冗余集群的提供方式，从物理机、虚拟机到容器，其成本逐渐降低，灵活性逐渐提高。
灰度发布的主要验证方式是导入真实流量，那么如何可控的将真实流量引流到创建的灰度区域？
根据路由器/负载平衡器的类型，可以采用不同的排放方法:
使用灰度域名将灰度域名配置指向灰度区域。这种域名引流的方法需要灰色域名接入，增加了域名资源，对外部用户不一定适用。
向HTTP请求添加灰度信息的可能方法有:
1)使用不同的URL路径，例如hello.com.cn/金丝雀/...，缺点是占用urlpath资源。
2)在HTTP头或URL查询字符串中添加一个灰色字段来存储灰色信息。
3)基于原始HTTP请求的信息和一定的路由策略，进行灰度引流。例如，基于cookie中的用户信息，可以基于用户白名单、用户区域或其他用户属性来实现引流策略。
根据上述方法添加的灰度信息，同时在负责七层路由的负载均衡器上配置基于灰度信息的引流策略，实现引流。
通用灰阶需要经过环境适应性、功能、性能和用户的验证。
部署的程序能否正常启动，运行状态是否稳定；是否使用基础设施资源(CPU、内存、IO、网络等。)是正常的；虚拟运行环境(如JVM)是否正常运行等。
通过promethues等基础设施资源指标监控工具监控响应指标。
通过集成APM工具(如CAT、Zipkin、Pinpoint和Skywalking)来监控和验证应用程序状态。
通过冒烟测试验证程序的基本功能；UAT；用于新功能和缺陷修复；通过导入真实交通数据，验证了程序的功能。
监控和验证应用程序/服务开放接口的RT和TPS。
导入真实流量，收集用户行为数据，分析用户行为；监控真实用户流量访问产生的业务指标等。舆情监测等等。
当验证结束后，需要正式发布，而正式发布的方式取决于灰色地带是如何打造的。
如果是canary release的部署模式，首先将官方的生产环境流程策略还原到灰色区域，然后通过滚动的方式无损更新旧版本节点。
如果灰色区域以蓝绿色冗余模式构建，则路由配置被修改为将总生产流直接路由到灰色区域，并且灰色区域被转变为处理生产流的生产环境集群。
当灰度得到验证，决定取消发布时，需要回滚灰度区域。
Canary部署模式需要回滚灰色节点，恢复正式的流量路由策略。
如果灰色区域采用蓝绿冗余模式建设，只需要关闭灰色区域的生产流引流即可。