基于 cookie 的 node 中间层灰度流程的一些思考

前言

关于灰度发布的意义此处就不进行介绍了，能够先读下这两篇文章

《微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布》

《灰度发布：灰度很简单，发布很复杂》

灰度方案说白了就是，分配必定比例或者筛选有特殊身份的用户，让这部分用户提早试用产品的最新版本，以便尽早发现问题也可将问题的影响最小化。不一样公司都有本身独特的灰度流程，此处仅仅讨论灰度方案中的其中一个小环节，用户分配。

灰度流程

粗粒度灰度流程图（存在细节问题）

粗粒度的流程看上去彷佛没有多大问题，但若是往细里考究，就会看到，漏洞百出

• 首次访问的时候无 cookie 必然走 online 集群，但若是命中灰度，接下来的异步请求将被分流到 beta 集群，资源错乱
• beta 集群下 cookie 过时后（浏览器自动清理），接下来的异步请求将会重新被灰度分配，若是未命中灰度，接下来的异步请求将被分流到 online 集群，资源错乱
• 失效时间若是设置较短，则达不到灰度的目的

接下来，优化是必然的

几个大的问题

一、同步资源和异步资源的问题

描述：

同一个会话下，因为时机不一样，致使同步资源和异步资源流入不一样集群，此处假设 online 集群和 beta 集群资源不一致

场景：

一、同步 online 异步 beta：同步资源在无 cookie 条件下流入 online 集群，同步命中灰度设置了 cookie，以后的异步请求将会流入 beta 集群

二、同步 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）

综合方案 b，c 可解决场景 1，2

二、灰度 cookie 过时或重置问题

描述：

会话期间更新 disconf 配置，或 cookie 天然过时会出现如下场景，致使资源请求错乱问题

场景：

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）

综合 b，c 可解决场景 3，4，5

三、灰度 cookie 的有效期时长问题

描述：

假设上方问题都已经解决，那么 cookie 的 maxAge 该设置成多少才比较合理？

• 有效期较短，如 10s

问题：假设用户访问一个页面的时间大于10s，那么，此用户的异步请求将会在 online 和 beta 集群来回切换，虽然解决了资源错乱的问题，用户无感知，但 beta 集群受到的压力将会成倍增大。

同时，从目标用户分配的比例上来看，1天内机会全部的用户都会引流到 beta 集群，这样灰度将失去意义，且带来较大风险

• 有效时间较长，如 1 天或更高

问题：过时时间设置较长，其优势偏偏是有效规避了有效期较短的致命缺点，beta 集群的流入用户比例和服务器压力都比较低。

可是，另一个方面，若是 beta 集群出错宕机，或者咱们主动将 beta 集群下线。就会致使灰度用户在 1 天内的反馈就是 404，且无解，只能等 cookie 过时或者用户主动换浏览器。致使的结果就是，客服电话被打爆，而后甩一句【垃圾网站！】，这是彻底不能接受的。

• 适中的有效期，如 10分钟到 1 小时

通常来说，若是不是生产工具类的网站，用户一次的访问周期不会超过 1 小时，及时用户没有关闭网页的习惯，1 个小时候再次操做也不会对网站形成多大影响。

虽说，宕机致使的 404 一样无解，但损失能够降到最小

总结

灰度细化流程图

综合来看，方案 b,c 基本能够解决咱们的上述问题。

beta 集群资源兼容 online 集群，静态资源长发布到 CDN，因此只需对异步资源进行同步便可。

集群独立域名（302），使用域名区分 online & beta，作域隔离，即便 cookie 失效也能够保证用户的当前会话操做维持在 beta 集群。

另外针对 a 方案，针对不一样的业务场景，还有有必定的做用，好比避免出现跨域请求等。

问题是相对的，方案是灵活的。不一样类型的系统会用不一样的问题，咱们能作的就只有针对问题思考解决方案。

若是你有更好的解决方案，还请不吝赐教！拜谢！

---

转载请标明出处

做者： 木羽 zwwill

首发地址：github.com/zwwill/blog…