基於 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…