基於 cookie 的 node 中間層灰度流程的一些思考
關於灰度釋出的介紹此處就不進行介紹了，不清楚的同學可以先讀下這兩篇文章
ofollow,noindex">《微服務部署：藍綠部署、滾動部署、灰度釋出、金絲雀釋出》
灰度方案說白了就是，分配一定比例或者篩選有特殊身份的使用者，讓這部分使用者提前試用產品的最新版本，一遍儘早發現問題也可將問題的影響最小化。不同公司都有自己獨有灰度流程，此處僅僅討論灰度方案中的其中一個小環節，使用者分配。
灰度流程
粗粒度灰度流程圖（存在細節問題）
粗粒度的流程看上去似乎沒有多大問題，但如果往細裡考究，就會看到，漏洞百出
- 首次訪問的時候無 cookie 必然走 online 叢集，但如果命中灰度，接下來的非同步請求將被分流到 beta 叢集，資源錯亂
- beta 叢集下 cookie 過期後（瀏覽器自動清理），接下來的非同步請求將會從新被灰度分配，如果未命中灰度，接下來的非同步請求將被分流到 online 叢集，資源錯亂
- 失效時間如果設定較短，則達不到灰度的目的
接下來，優化是必然的
幾個大的問題
1、同步資源和非同步資源的問題
描述：
同一個會話下，由於時機不同，導致同步資源和非同步資源流入不同叢集，此處假設 online 叢集和 beta 叢集資源不一致
場景：
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]。 （1，-2）
方案 c) beta 叢集獨立域名（302），使用域名區分 online & beta。 （-1，2）
綜合方案 b，c 可解決場景 1，2
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
3、灰度 cookie 的有效期時長問題
描述：
假設上方問題都已經解決，那麼 cookie 的 maxAge 該設定成多少才比較合理？
- 有效期較短，如 10s
問題：假設使用者訪問一個頁面的時間大於10s，那麼，此使用者的非同步請求將會在 online 和 beta 叢集來回切換，雖然解決了資源錯亂的問題，使用者無感知，但 beta 叢集受到的壓力將會成倍增大。
同時，從目標使用者分配的比例上來看，1天內機會所有的使用者都會引流到 beta 叢集，這樣灰度將失去意義，且帶來較大風險
- 有效時間較長，如 1 天或更高
問題：過期時間設定較長，其優點恰恰是有效規避了有效期較短的致命缺點，beta 叢集的流入使用者比例和伺服器壓力都比較低。
但是，另外一個方面，如果 beta 叢集出錯宕機，或者我們主動將 beta 叢集下線。就會導致灰度使用者在 1 天內的反饋就是 404 ，且無解，只能等 cookie 過期或者使用者主動換瀏覽器。導致的結果就是，客服電話被打爆，然後甩一句【垃圾網站！】，這是完全不能接受的。
- 適中的有效期，如 10分鐘到 1 小時
一般來講，如果不是生產工具類的網站，使用者一次的訪問週期不會超過 1 小時，及時使用者沒有關閉網頁的習慣，1 個小時候再次操作也不會對網站造成多大影響。
雖然說，宕機導致的 404 同樣無解，但損失可以降到最小
灰度細化流程圖