背景
之前在思考雙活/多活架構的時候，其實對於藍綠髮布是有一些瞭解的，也梳理過在底層存儲是一份，服務是多份的模式有做過深入的分析。但那個時候對於Kubernetes的瞭解還不是很熟悉，是通過傳統的方式來考量的。
因爲現在的互聯網公司基本都是上雲了，我們也必須對於Kubernetes那一整套要有比較深入、熟悉的運用才能真的提高我們的效率。先聊一下，我爲什麼需要利用灰度+藍綠髮布的模式來去做？
現在有一個比較老的項目，應該在10年+，每天請求量大概在1.5億+，峯值的QPS在6000/s，存在着比較多性能問題。現在需要在它上面新增一個服務，爲了後面優化做準備，比如：請求的分流、限流、熔斷、日誌的上報與監控（新）、統一編譯處理，特殊報文轉換等。也就是說，只要你新增加了一層，你纔有可能更好的去做更多的事情。
那麼我們需要達到一些什麼的基礎條件了？
- 服務流量比較大，我們需要對新服務的可靠性需要驗證，需要灰度先了解
- 因爲存在慢查詢，不能在滾動發佈中，導致請求還未執行完畢，就被k8s kill掉了，業務會感知到502
如果是你？針對於這2個基礎的要求，你會如何去思考的你架構方案呢？
思考
新增服務的思考：
- 它的性能必須要強、服務穩定。一個服務的性能好不好，其實跟它的：
I/O模型、線程模型、數據結構、算法等息息相關。比如：你在思考Redis單線程爲什麼快的時候？應該就很能get到這裏的點了。解決這個問題，我們選擇了Go語言來開發（當然，最熟悉的語言風險最小），爲了保證性能，也是做了2輪非常細緻的壓測。 - 發佈過程中不能因爲kill掉服務導致請求
502。如果說我在發佈的過程中，我把滾動這一步省略掉，直接先準備好一份最新的，驗證可以後，我一刀直接把流量引導最新服務上，老的服務也不會斷掉，這是否就可以達到效果了？
方案設計
下面是我畫的一個架構圖，方便大家的理解，一共是3條路線：
路線1：原始的路線
Ingress→Service:server-read→StatefulSet:server-g3-read + server-g3-read-gray，整條鏈路是通過ingress的指向與selector的標籤：k8s-app:server-read。
路線2：灰度方案
服務正常
就是我只能讓一少部分的流量進入到新的服務(2%~10%，支持慢慢調整，其實就是pod的數量佔比)。
2%的概率走的路徑：Ingress→Service:server-gateway-read01→StatefulSet:server-gateway-read01→註冊中心獲取負載地址→Service:server-read→StatefulSet:server-g3-read + server-g3-read-gray，整條鏈路是通過ingress的指向與selector的標籤：server-app:server-gateway-read0198%的概率還是走的路線1
服務異常解決方案
- 因爲這個流量是通過節點數來控制的，如果發生異常，可以把灰度節點的POD數量調整爲0
- 還可以從ingress的地址切換到線路1的原始方案。這一招永遠生效，因爲一整套label標籤依然存在。
路線3：藍綠路線
服務正常
- 100%的流量全部走灰度方案的。即：
Ingress→Service:server-gateway-read01→StatefulSet:server-gateway-read01→註冊中心獲取負載地址→Service:server-read→StatefulSet:server-g3-read + server-g3-read-gray。但是它的selector的標籤：server-app:server-gateway-read02
服務異常解決方案
- 直接切換ingress地址到線路1或者是線路2都可以
最終的方案
後面如果長期穩定後，方案2其實就沒有必要再繼續灰度了，直接就替換成線路3了。相當於是一個藍綠+主備的模式了。優缺點非常的明顯：
- 優點：解決了重啓中可能出現的中斷問題，其實也可以通過一些
Graceful Shutdown優化。 - 缺點：就是發佈的一瞬間，你是需要多出一倍的機器來支撐服務的。
再溫馨提示一下，因爲做了藍綠髮布，我們的系統對應的配置中心應該也最好是要分開的。系統之間要避免藍色通過與綠色通道之間的交叉訪問等問題。