在软件开发中，"灰度"通常指的是渐进式地将新功能、更新或改进引入到生产环境中，但只对一小部分用户或流量进行部署和测试的过程。这种方法允许开发团队在生产环境中逐步测试新功能，以确保其稳定性、可靠性和用户体验，同时最小化对整个用户群体的影响。
主要流程：
1.选取目标用户、流量或比例： 灰度发布开始时，开发团队会选择一小部分用户、流量或服务器来尝试新功能。这可以是随机选择的用户群体，也可以是特定的用户分段。
2.部署新功能： 新功能或更新版本会在选定的用户或流量上进行部署。这可能涉及更新生产环境中的代码、配置或资源文件。
3.监控和反馈： 在新功能部署后，团队会密切监控系统的运行状况，并收集用户反馈。这有助于确定新功能是否引发了任何问题或负面影响。
4.逐步扩大范围： 如果新功能在初始阶段表现良好，团队可能会逐步扩大新功能的范围，覆盖更多的用户或流量。这可能通过增加新的用户分组或增加新的服务器来实现。
完全发布： 一旦团队确认新功能在所有方面都稳定可靠，他们就会将其完全发布到生产环境中，使所有用户都能够访问。
通过灰度发布，团队可以最小化潜在的风险，因为他们只是在一小部分环境中测试新功能。这种逐步、渐进式的方法有助于发现和解决问题，同时保持对用户的影响最小化。
后端灰度的做法：
例如：
在docker/k8s里 ，原服务有2个，都是1.1版本，
他们通过网关和外部进行交流
发布一个新服务 新版本1.2到docker/k8s里，设置灰度比例为10%
灰度比例10%就意味着用户请求网关,有10%的请求会路由到版本1.2
灰度比例一般是网关控制的
除了用比例控制,还有按照消息头信息控制,这样也能使得部分满足条件的用户使用到新版本
灰度合并:发布同样数量的版本1.2,
稳定后将请求都打到版本1.2(相当于灰度比例100%)
然后1.1版本还是保留在环境内,以便回滚(防止新服务错误,一错误就马上切回版本1.1)
上线成功后把旧服务删除掉
这只是后端灰度发布的概念
其他灰度发布大同小异
目的在于如何平稳的过渡到新版本,以及如何选部分流量/人员试用新版本的功能