基礎介紹

下文分別從名詞解釋、灰度升級的作用、灰度升級方案3個方面展開介紹：

1.名詞解釋

灰度升級：灰度升級是一種升級時候的平滑切換，當有些服務器的客戶端要進行升級，可以只對其中一個客戶端升級并測試，確保程序無誤后再全局升級。也就是說所有服務器可以不同步更新升級，首次只是對一個地區的服務器進行更新升級，待升級完成確保無誤后，再對其他地區的服務器進行統一的更新升級。

灰度期：灰度發布從開始到結束的這一段時間，被稱為灰度期。

Nginx：Nginx不僅是一個十分輕量級的HTTP服務器，也是一個高性能的HTTP和反向代理服務器，同時還是一個IMAP/POP3/SMTP代理服務器。目前很多國內網站采用Nginx作為Web服務器，如國內知名的新浪、163、騰訊、Discuz、豆瓣等。本次灰度升級就是通過調整Nginx配置文件的方式實現。

2.灰度作用

1.及早獲得用戶的意見反饋，完善產品功能，提升產品質量；

2.讓用戶參與產品測試，加強與用戶的互動；

3.降低產品升級所影響的用戶范圍，降低升級風險，避免升級事故。

3.升級方案

實現思路方向可分為兩種，一種是在代碼中實現，一種是在接入層中實現。靈活的灰度方案一般需要在接入層實現，也就是自定義負載均衡策略實現。本篇文檔介紹的就是這種在接入層實現，使用Nginx實現負載均衡的策略。

> > > >實現思路

• 在代碼中

一套線上環境，在代碼中做開關，對于不同的用戶走不同的邏輯。

優點：靈活，粒度細；一套代碼(環境)運維成本低；

缺點：灰度邏輯侵入代碼。

• 在接入層

多套(隔離的)線上環境，接入層針對不同用戶轉發到不同的環境中。

優點：無需或少量侵入代碼，風險小；

缺點：多套線上環境，運維成本高。

• 接入模式

1.在nginx層實現，例如通過IP地址判斷，部分IP段(如辦公環境的IP地址段)的請求會引入到灰度環境；

2.在網關層實現(spring-cloud-zuul)；

3.dubbo的灰度，項目中如果使用dubbo，有可能會需要dubbo服務的灰度實現。

2灰度框架

下面介紹灰度升級的整體架構流程，方便大家快速理解。

1.整體框架

灰度發布只升級部分服務，即讓一部分用戶繼續用老版本(下圖綠框部分)，一部分用戶開始用新版本(下圖藍框部分)，如果事業用新版本的用戶沒有意見反饋，接下來就會逐步擴大使用范圍，直到將所有用戶都遷移到新版本。

2.項目架構

在本次項目中，灰度升級包含兩個部分，一個是現有環境至云平臺正式環境的灰度升級，另一個是云平臺發布環境至云平臺正式環境的灰度升級，兩種情況下升級的主要配置及原理如下：

> > > >現有與云平臺正式

說明：

1.用戶A登錄服務，根據ip網段分配到現有環境；

2.用戶B登錄服務，根據ip網段分配到云平臺正式環境。

> > > >云平臺發布與正式

說明：

1.用戶A登錄服務，根據ip網段分配到云平臺發布環境；

2.用戶B登錄服務，根據ip網段分配到云平臺正式環境。

配置說明

1.現有與云平臺正式

現有環境和云平臺環境灰度升級實際為調整Nginx配置添加兩個upsteamcluster，一套配置為原有CentOS部署的運行環境，另一套配置為云平臺部署的運行環境，在Server監聽的過程中按照IP段進行配置判斷，劃分IP區間，實現定義分割IP區間。根據IP區間實現某一段IP訪問的為原有CentOS環境，另一端訪問的IP區間則為云平臺部署環境，運行一段時間后調整為整體IP區間全部訪問云平臺的模式。

關鍵配置如下：

定義兩個upsteamcluster，一套配置為原有CentOS部署的運行環境，另一套配置為云平臺部署的運行環境。

在Server監聽的過程中按照IP段進行配置判斷，劃分IP區間，根據IP區間實現某一段IP訪問的為原有CentOS環境，另一端訪問的IP區間則為云平臺部署環境。

說明：

1)set $group cluster_classic：設置proxy_pass默認值為“cluster_classic”，現有環境；

2)set $environmentType "classic：設置環境類型默認值為"classic"，現有環境；

3)set $ingressPath "/"：設置proxy_cookie_path路徑默認值為“/”，cookie地址保持不變；

4)if ($remote_addr ~ "18.0.9.*")：根據ip是否在這個網段，如果在就走云平臺正式環境；

5)set $group cluster_cloud：proxy_pass重新賦值為“cluster_cloud”，云平臺正式環境；

6)set $environmentType "cloud_product"：將環境類型重新設置為"cloud_product"，云平臺正式環境；

7)if ($environmentType = "cloud_product")：判斷是否是云平臺正式環境；

8)set $ingressPath "/S01/Product/ESB/"：設置proxy_cookie_path路徑；

9)rewrite (/|$)(.*) $ingressPath$2 break：設置重定向路徑；

10)proxy_pass http://$group：proxy_pass引用$group；

11)proxy_cookie_path $ingressPath /：proxy_cookie_path引用$ingressPath。

2.云平臺發布與正式

云平臺內部發布與生產的回復升級，原理與CentOS升級至云平臺模式相同，不同的是云平臺內部灰度升級是依據訪問路徑進行區分，核心配置如下：

說明：

1)set $ingressPath "/S01/Release/ESB/"：設置proxy_cookie_path路徑默認值發布路徑；

2)if ($remote_addr ~ "18.0.8.*")：根據ip是否在這個網段選擇訪問環境，如果在就走云平臺正式環境；

3)set $ingressPath "/S01/Product/ESB/"：proxy_cookie_path路徑重新賦值為正式路徑；

4)rewrite (/|$)(.*) $ingressPath$2 break：設置重定向路徑；

5)proxy_cookie_path $ingressPath /：proxy_cookie_path引用$ingressPath。

3.傳統與云區別說明

現有環境和云平臺正式環境與云平臺正式環境和發布環境灰度升級配置的主要區別如下：

1)定義upstream的訪問地址不同，一個是云平臺部署地址，云平臺地址為動態替換proxy_pass；另一個是現有CentOS部署環境地址，現有部署無需動態替換proxy_pass；

2)云平臺與現有部署環境中的proxy_pass引用upstream不同；proxy_cookie_path設置的地址不同，現有部署為“/”，不轉換cookie路徑，云平臺需要轉換為內部Ingress路徑。

心得總結

灰度升級可以比較有效地解決服務升級對用戶的影響，之前一直使用調整nginx配置進行全量更新升級，灰度升級方式并沒有被使用，通過本次在項目中使用灰度升級方式學習到了許多新的知識。

1.能力欠缺

在開始配置nginx時，想要使其支持根據IP進行分流，需要設置變量的方式，而其中有一處配置問題一直沒有攻克，嘗試多種方式依舊沒有解決。在嘗試過程中感受到了自己在網絡層面、代理方面能力的不足，真是有些力不從心，最后還是在公司領導的幫助下解決的，后續不僅要對底層代碼加深研究，也要對上層邏輯深入了解。

2.知識收獲

在這次使用Nginx實現灰度升級過程中，學習到了許多新的知識，同時也鞏固了已經積累的知識。對Nginx中的變量更加熟知，掌握了在Nginx里script的常規用法、變量的使用范圍和配置重定向路徑的方法。

3.個人總結

升級策略不僅僅只有灰度發布一種，還有滾動發布和藍綠部署。本次我們選擇灰度升級的原因是這種方式的影響用戶少、配置簡單。后續會繼續了解滾動發布和藍綠部署的優缺點及配置方法，融入到產品項目體系中。

團隊作戰不僅需要相互協作，自己也要多嘗試多思考，不要灰心不要輕言放棄，領導的指點為我提供了解決思路，這些經歷也讓我不斷成熟，在以后處理各種問題時會考慮得更加全面。基于K8S云平臺來構建集成開發解決方案、開發集成方案未來是數通暢聯的主打方式，K8S云平臺管理中心UMC是公司SOA應用集成、數據治理分析套件的管理底座，融入了大量平臺產品與集成項目結合的最佳實踐和管理思想，也是構建集成中臺、數據中臺、應用中臺的利器，未來考慮陸續輸出云平臺相關文檔。

總結

以上是生活随笔為你收集整理的nginx 没有cookie_Nginx灰度升级实现说明的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。