Open zwwill opened 5 years ago
关于灰度发布的意义此处就不进行介绍了，可以先读下这两篇文章
《微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布》
《灰度发布：灰度很简单，发布很复杂》
灰度方案说白了就是，分配一定比例或者筛选有特殊身份的用户，让这部分用户提前试用产品的最新版本，以便尽早发现问题也可将问题的影响最小化。不同公司都有自己独特的灰度流程，此处仅仅讨论灰度方案中的其中一个小环节，用户分配。
粗粒度灰度流程图（存在细节问题）
粗粒度的流程看上去似乎没有多大问题，但如果往细里考究，就会看到，漏洞百出
接下来，优化是必然的
描述：
同一个会话下，由于时机不同，导致同步资源和异步资源流入不同集群，此处假设 online 集群和 beta 集群资源不一致
场景： 1、同步 online 异步 beta：同步资源在无 cookie 条件下流入 online 集群，同步命中灰度设置了 cookie，之后的异步请求将会流入 beta 集群 2、同步 beta 异步 online：同步资源在有 cookie 条件下流入 beta 集群，随后 cookie 失效，之后的异步请求将会流入 online 集群
场景：
1、同步 online 异步 beta：同步资源在无 cookie 条件下流入 online 集群，同步命中灰度设置了 cookie，之后的异步请求将会流入 beta 集群
2、同步 beta 异步 online：同步资源在有 cookie 条件下流入 beta 集群，随后 cookie 失效，之后的异步请求将会流入 online 集群
方案 a) node 中台灰度命中后重新代理回 ngnix 进行分流。 （1-，-2）{1：有效，1-：部分有效，-1：无效，下同} 方案 b) beta 集群资源兼容 online 集群。 （1，-2） 方案 c) beta 集群独立域名（302），使用域名区分 online & beta。 （-1，2）
方案 a) node 中台灰度命中后重新代理回 ngnix 进行分流。 （1-，-2）{1：有效，1-：部分有效，-1：无效，下同}
方案 b) beta 集群资源兼容 online 集群。 （1，-2）
方案 c) beta 集群独立域名（302），使用域名区分 online & beta。 （-1，2）
综合方案 b，c 可解决场景 1，2
会话期间更新 disconf 配置，或 cookie 自然过期会出现以下场景，导致资源请求错乱问题
场景： 3a、同步请求前设置灰度配置（online -> beta，同步资源同步） 3b、同步请求前关闭灰度配置（beta -> online，同步资源同步） 4a、同步（online）请求后异步请求前重置灰度配置（beta） 4b、同步（beta）请求后异步请求前重置灰度配置（online） 5a、下一个同步请求前重置灰度配置（online -> beta，同步资源不同步） 5b、下一个同步请求前重置灰度配置（beta -> online，同步资源不同步）
3a、同步请求前设置灰度配置（online -> beta，同步资源同步）
3b、同步请求前关闭灰度配置（beta -> online，同步资源同步）
4a、同步（online）请求后异步请求前重置灰度配置（beta）
4b、同步（beta）请求后异步请求前重置灰度配置（online）
5a、下一个同步请求前重置灰度配置（online -> beta，同步资源不同步）
5b、下一个同步请求前重置灰度配置（beta -> online，同步资源不同步）
方案 a) 同上。（3a，3b，-4a，-4b，-5a，-5b） 方案 b) 同上。（3a，-3b，4a，-4b，5a，-5b） 方案 c) 同上。（-3a，3b，4a，4b，-5a，5b）
方案 a) 同上。（3a，3b，-4a，-4b，-5a，-5b）
方案 b) 同上。（3a，-3b，4a，-4b，5a，-5b）
方案 c) 同上。（-3a，3b，4a，4b，-5a，5b）
综合 b，c 可解决场景 3，4，5
假设上方问题都已经解决，那么 cookie 的 maxAge 该设置成多少才比较合理？
有效期较短，如 10s
问题：假设用户访问一个页面的时间大于10s，那么，此用户的异步请求将会在 online 和 beta 集群来回切换，虽然解决了资源错乱的问题，用户无感知，但 beta 集群受到的压力将会成倍增大。 同时，从目标用户分配的比例上来看，1天内机会所有的用户都会引流到 beta 集群，这样灰度将失去意义，且带来较大风险
问题：假设用户访问一个页面的时间大于10s，那么，此用户的异步请求将会在 online 和 beta 集群来回切换，虽然解决了资源错乱的问题，用户无感知，但 beta 集群受到的压力将会成倍增大。
同时，从目标用户分配的比例上来看，1天内机会所有的用户都会引流到 beta 集群，这样灰度将失去意义，且带来较大风险
有效时间较长，如 1 天或更高
问题：过期时间设置较长，其优点恰恰是有效规避了有效期较短的致命缺点，beta 集群的流入用户比例和服务器压力都比较低。 但是，另外一个方面，如果 beta 集群出错宕机，或者我们主动将 beta 集群下线。就会导致灰度用户在 1 天内的反馈就是 404，且无解，只能等 cookie 过期或者用户主动换浏览器。导致的结果就是，客服电话被打爆，然后甩一句【垃圾网站！】，这是完全不能接受的。
问题：过期时间设置较长，其优点恰恰是有效规避了有效期较短的致命缺点，beta 集群的流入用户比例和服务器压力都比较低。
但是，另外一个方面，如果 beta 集群出错宕机，或者我们主动将 beta 集群下线。就会导致灰度用户在 1 天内的反馈就是 404，且无解，只能等 cookie 过期或者用户主动换浏览器。导致的结果就是，客服电话被打爆，然后甩一句【垃圾网站！】，这是完全不能接受的。
适中的有效期，如 10分钟到 1 小时
一般来讲，如果不是生产工具类的网站，用户一次的访问周期不会超过 1 小时，及时用户没有关闭网页的习惯，1 个小时候再次操作也不会对网站造成多大影响。 虽然说，宕机导致的 404 同样无解，但损失可以降到最小
一般来讲，如果不是生产工具类的网站，用户一次的访问周期不会超过 1 小时，及时用户没有关闭网页的习惯，1 个小时候再次操作也不会对网站造成多大影响。
虽然说，宕机导致的 404 同样无解，但损失可以降到最小
灰度细化流程图
综合来看，方案 b,c 基本可以解决我们的上述问题。
beta 集群资源兼容 online 集群，静态资源长发布到 CDN，所以只需对异步资源进行同步即可。
集群独立域名（302），使用域名区分 online & beta，做域隔离，即使 cookie 失效也可以保证用户的当前会话操作维持在 beta 集群。
另外针对 a 方案，针对不同的业务场景，还有有一定的作用，比如避免出现跨域请求等。
问题是相对的，方案是灵活的。不同类型的系统会用不同的问题，我们能做的就只有针对问题思考解决方案。
如果你有更好的解决方案，还请不吝赐教！拜谢！
转载请标明出处 作者： 木羽 zwwill 首发地址：https://github.com/zwwill/blog/issues/25
转载请标明出处
作者： 木羽 zwwill
首发地址：https://github.com/zwwill/blog/issues/25
前言
关于灰度发布的意义此处就不进行介绍了，可以先读下这两篇文章
《微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布》
《灰度发布：灰度很简单，发布很复杂》
灰度方案说白了就是，分配一定比例或者筛选有特殊身份的用户，让这部分用户提前试用产品的最新版本，以便尽早发现问题也可将问题的影响最小化。不同公司都有自己独特的灰度流程，此处仅仅讨论灰度方案中的其中一个小环节，用户分配。
灰度流程
粗粒度灰度流程图（存在细节问题）
粗粒度的流程看上去似乎没有多大问题，但如果往细里考究，就会看到，漏洞百出
接下来，优化是必然的
几个大的问题
1、同步资源和异步资源的问题
描述：
同一个会话下，由于时机不同，导致同步资源和异步资源流入不同集群，此处假设 online 集群和 beta 集群资源不一致
综合方案 b，c 可解决场景 1，2
2、灰度 cookie 过期或重置问题
描述：
会话期间更新 disconf 配置，或 cookie 自然过期会出现以下场景，导致资源请求错乱问题
综合 b，c 可解决场景 3，4，5
3、灰度 cookie 的有效期时长问题
描述：
假设上方问题都已经解决，那么 cookie 的 maxAge 该设置成多少才比较合理？
有效期较短，如 10s
有效时间较长，如 1 天或更高
适中的有效期，如 10分钟到 1 小时
总结
综合来看，方案 b,c 基本可以解决我们的上述问题。
beta 集群资源兼容 online 集群，静态资源长发布到 CDN，所以只需对异步资源进行同步即可。
集群独立域名（302），使用域名区分 online & beta，做域隔离，即使 cookie 失效也可以保证用户的当前会话操作维持在 beta 集群。
另外针对 a 方案，针对不同的业务场景，还有有一定的作用，比如避免出现跨域请求等。
问题是相对的，方案是灵活的。不同类型的系统会用不同的问题，我们能做的就只有针对问题思考解决方案。
如果你有更好的解决方案，还请不吝赐教！拜谢！