滾動升級和灰度發佈常見場景(未完待續)

前言

• 關於藍綠部署、滾動升級、灰度發佈的描述、區別、優缺點，網上有很多討論，這裏不做過多描述，比如：https://www.cnblogs.com/nulige/articles/10929182.html
• 藍綠部署的場景，相對比較簡單，這裏也不做贅述

---

滾動升級（無損升級）

介紹

• 故名思議，就是逐步升級服務中的節點

場景

基於haproxy的四七層滾動升級：

• 方式：使用socat（unix套接字工具）管理haproxy上掛載服務的狀態實現無損變更
• 場景：假如某服務有A、B兩個節點，且掛載到了haproxy上
• 無損變更方式：
  • 準備：首先haproxy需要配置生成套接字sock：stats socket /usr/local/haproxy/stats
  • 變更前：使用socat連接該sock，
  • 變更中：disable掉A節點（此時流量全部到B）
  • 變更中：升級A節點
  • 變更中：A節點升級完成後，enable A節點，驗證A節點上流量是否正常，否則disable掉後回滾
  • 變更中：disable掉B節點（此時流量全部到A）
  • 變更中：升級B節點
  • 變更中：B節點升級完成後，enable B節點，驗證B節點上流量是否正常，否則disable掉B節點
  • 驗證
• 潛在問題：該場景前提是，升級的新版本沒有bug，否則升級過程中，所有的用戶請求都可能出現問題（包括VIP用戶流量報障）

基於nginx的滾動升級

• 方式：修改nginx的upstream節點配置，並使用reload命令動態加載配置，實現節點的上線、下線，從而實現滾動升級
• 整個升級過程以及潛在問題，同上面的haproxy方式類似，這裏不做贅述
• 備註：nginx的upstream模塊可以配置weight權重，滾動升級時，一般先升級weight權重較小的節點

基於服務註冊與發現的方式

• 場景：多用於大規模的微服務化場景下
• 開源解決方案有：springcloud場景下的Eureka、consul、zookeeper、etcd
• 方式：通過調用接口，實現節點在註冊中心的上線與下線，從而達滾動升級的目的。整個升級過程以及潛在問題同上，這裏不做贅述。比如Eureka的更改狀態接口：
  • PUT /eureka/apps/appID/instanceID/status？value=OUT_OF_SERVICE

基於k8s的滾動升級

• 背景：微服務化大行其道的今天，作爲重要的微服務話的工具，k8s實現滾動升級可少不了
• 方式：待完善
• 擴展：https://www.cnblogs.com/justmine/p/8688828.html

---

灰度發佈

• 實現版本的平滑升級，有效降低版本升級帶來的風險，實現更高效的發佈
• 此外，精細的灰度策略，可以選擇特定的用戶(ip/cookie等)參與新版本的試用，得到更快的業務反饋

灰度發佈場景

自定義開發nginx+lua實現精細的灰度發佈

• 方式：自定義開發lua腳本控制nginx的流量走向，從而實現灰度升級
  • 實現1：集羣內多節點間的灰度發佈
  • 實現2：不同集羣間的灰度發佈
• 常見的灰度流量策略：
  • IP限制：將來源IP的流量送到特定節點上
  • ID限制：將部分特定的租戶ID的流量送到特定節點上
  • 百分比：將流量按百分比劃分，送到特定節點上
• 擴展：lua爲開源的腳本語言，參見：https://www.runoob.com/lua/lua-tutorial.html

基於開源Kong(基於openresty(nginx+lua)）實現灰度發佈

• 當然，社區有一套比較成熟的可直接用的開源框架：https://konghq.com/kong/
  • 限流
  • 熔斷
  • 認證
  • … …
• 擴展：https://openresty.org/cn/download.html
• 擴展：lua爲開源的腳本語言，參見：https://www.runoob.com/lua/lua-tutorial.html

基於雲服務廠商的APIG實現灰度發佈

• 可通過各大雲服務廠商提供的APIG服務，實現灰度發佈升級
• 比如華爲雲的：https://support.huaweicloud.com/productdesc-apig/apig-zh-pd-180307002.html