批量伺服器如何灰度發布

『壹』 如果安裝了很多伺服器，有沒有軟體可以同時對多個伺服器進行批量操作，不用一個一個的去設置

如果是要管理站點的話，linux下試試zijidelu吧

『貳』 新版本發布如何不影響線上呢灰色發布，藍綠發布

很多企業升級伺服器端應用，需要將源碼或程序包上傳到伺服器，然後停掉老版本，再啟動新版本。但是這種發布方式存在兩個問題，一方面，在新版本升級過程中，線上的服務是中斷的無法訪問和使用的，另一方面，如果新版本有BUG或更新後發現有問題，升級失敗，回滾起來也非常麻煩，容易造成更長時間的服務不可用。

以下內容轉自網路，僅供本人自己學慣用，侵刪，原文鏈接： https://blog.51cto.com/13886290/2162766 ，

為了解決這些問題，人們研究出了多種發布策略，下面我們一一介紹。

藍綠部署

所謂藍綠部署，是指同時運行兩個版本的應用，如上圖所示，藍綠部署的時候，並不停止掉老版本，而是直接部署一套新版本，等新版本運行起來後，再將流量切換到新版本上。但是藍綠部署要求在升級過程中，同時運行兩套程序，對硬體的要求就是日常所需的二倍，比如日常運行時，需要10台伺服器支撐業務，那麼使用藍綠部署，你就需要購置二十台伺服器。

滾動發布

滾動發布能夠解決掉藍綠部署時對硬體要求增倍的問題。

所謂滾動升級，就是在升級過程中，並不一下子啟動所有新版本，是先啟動一台新版本，再停止一台老版本，然後再啟動一台新版本，再停止一台老版本，直到升級完成，這樣的話，如果日常需要10台伺服器，那麼升級過程中也就只需要11台就行了。

但是滾動升級有一個問題，在開始滾動升級後，流量會直接流向已經啟動起來的新版本，但是這個時候，新版本是不一定可用的，比如需要進一步的測試才能確認。那麼在滾動升級期間，整個系統就處於非常不穩定的狀態，如果發現了問題，也比較難以確定是新版本還是老版本造成的問題。

為了解決這個問題，我們需要為滾動升級實現流量控制能力。

灰度發布

灰度發布也叫金絲雀發布，起源是，礦井工人發現，金絲雀對瓦斯氣體很敏感，礦工會在下井之前，先放一隻金絲雀到井中，如果金絲雀不叫了，就代表瓦斯濃度高。

在灰度發布開始後，先啟動一個新版本應用，但是並不直接將流量切過來，而是測試人員對新版本進行線上測試，啟動的這個新版本應用，就是我們的金絲雀。如果沒有問題，那麼可以將少量的用戶流量導入到新版本上，然後再對新版本做運行狀態觀察，收集各種運行時數據，如果此時對新舊版本做各種數據對比，就是所謂的A/B測試。

當確認新版本運行良好後，再逐步將更多的流量導入到新版本上，在此期間，還可以不斷地調整新舊兩個版本的運行的伺服器副本數量，以使得新版本能夠承受越來越大的流量壓力。直到將100%的流量都切換到新版本上，最後關閉剩下的老版本服務，完成灰度發布。

如果在灰度發布過程中（灰度期）發現了新版本有問題，就應該立即將流量切回老版本上，這樣，就會將負面影響控制在最小范圍內。

關於負載均衡的另一篇文章： https://www.jianshu.com/p/836a87355ea7

『叄』 F5提出的「灰度發布」是什麼意思呢

灰度發布是在軟體開發過程中交付的一種方式
F5率先提出在應用交付控制器中支持「灰度發布」，並進一步完善了灰度發布的實現形式，除支持傳統的A/B測試場景外，還可在線復制生產系統的流量到測試系統。在互聯網產品的發布過程中也較多採用此種發布方式：產品的發布過程不是一蹴而就，而是逐步擴大使用用戶的范圍，從公司內部用戶->忠誠度較高的種子用戶->更大范圍的活躍用戶->所有用戶。在此過程中，產品團隊根據用戶的反饋及時完善產品相關功能。此種發布方式，按照中國特色的叫法被冠以「灰度發布」、「灰度放量」、「分流發布」。

請採納！

『肆』 部署的幾種方式

由於之前只接觸了單服務應用，並且是自己做的，所以部署的方式也比較隨意，想要部署的話直接打一個war包部署上去就好了。接觸過分布式的多服務後，事情就沒有這么簡單了，如果還是採用之前的方式，會存在兩個問題，一方面，在新版本升級過程中，服務是暫時中斷的，另一方面，如果新版本有BUG，升級失敗，回滾起來也非常麻煩，容易造成更長時間的服務不可用。

下面是對集中常見部署方式的了解：

藍綠部署是我可以不看其他推薦，自己想到了部署方式。直接運行兩個版本的應用，並不停止舊版本的運行，而是等新版本運行正常後將流量切到新版本，但是缺點也很明顯，我需要雙倍的資源，平時10台伺服器就可以解決的問題現在需要20台了。

滾動發布能夠解決掉藍綠部署時對硬體要求增倍的問題。在升級的時候不是把所有的服務都啟動，而是啟動一台新的服務就替換掉對應的老服務，這樣正常需要10台伺服器，現在只需要11台就好了，缺點也很明顯，就是太不穩定了，出了問題不容易追溯。

灰度發布也叫金絲雀發布，起源是，礦井工人發現，金絲雀對瓦斯氣體很敏感，礦工會在下井之前，先放一隻金絲雀到井中，如果金絲雀不叫了，就代表瓦斯濃度高。

在灰度發布開始後，先啟動一個新版本應用，但是並不直接將流量切過來，而是測試人員對新版本進行線上測試，啟動的這個新版本應用，就是我們的金絲雀。如果沒有問題，那麼可以將少量的用戶流量導入到新版本上，然後再對新版本做運行狀態觀察，收集各種運行時數據，如果此時對新舊版本做各種數據對比，就是所謂的A/B測試。

當確認新版本運行良好後，再逐步將更多的流量導入到新版本上，在此期間，還可以不斷地調整新舊兩個版本的運行的伺服器副本數量，以使得新版本能夠承受越來越大的流量壓力。直到將100%的流量都切換到新版本上，最後關閉剩下的老版本服務，完成灰度發布。

如果在灰度發布過程中（灰度期）發現了新版本有問題，就應該立即將流量切回老版本上，這樣，就會將負面影響控制在最小范圍內。

『伍』 使用Nginx 簡單實現灰度發布

灰度發布是指在黑與白之間, 能夠平滑過渡的一種發布方式. AB test就是一種灰度發布試. 讓一部分用戶繼續使用A, 一部分用戶開始使用B, 如果用戶對B沒有什麼反對意見, 那麼逐步擴大范圍, 把所有用戶都遷移到B上面來.

灰度發布可以保證整體系統的穩定, 在初始灰度的時候就可以發現,調整問題, 以保證其影響度.

灰度發布常見一般有三種方式:

本文主要講解 根據Cookie和來路IP這兩種方式來實現簡單的灰度發布, Nginx+LUA 這種方式涉及內容太多就不再本文展開了.

根據 Cookie 查詢 Cookie 鍵為 version 的值, 如果該 Cookie 值為 V1 , 則轉發到 hilinux_01 , 為 V2 則轉發到 hilinux_02 , Cookie 的值都不匹配的情況下, 默認走 hilinux_01 所對應的伺服器.

兩個伺服器分別定義為:

在Nginx裡面配置一個映射, $COOKIE_version 可以解析出 Cookie 裡面的version欄位, $group 是一個變數, {}裡面是映射規則.

如果一個 version 為 V1 的用戶來訪問， $group 就等於 hilinux_01 。在 server 裡面使用就會代理到 http://hilinux_01 上。 version 為 V2 的用戶來訪問， $group 就等於 hilinux_02 。在 server 裡面使用就會代理到 http://hilinux_02 上。 Cookie 值都不匹配的情況下默認走 hilinux_01 所對應的伺服器。

如果是內部IP，則反向代理到hilinux_02(預發布環境)；如果不是則反向代理到hilinux_01(生產環境)。

如果你只有單台伺服器，可以根據不同的IP設置不同的網站根目錄來達到相同的目的。

到此最基本的實現灰度發布方法就講解完了，如果要做更細粒度灰度發布可參考ABTestingGateway項目。

『陸』 藍綠發布、紅黑發布、灰度發布和滾動發布

總結:
藍綠發布、紅黑發布、灰度發布和滾動發布組最終的目標都是避免因發布導致流量的丟失或服務不可用的問題

四種方式均可以做到平滑式升級，在升級過程中服務仍然保持服務的連續性，升級對外界是無感知的。那生產上選擇哪種部署方法最合適呢？這取決於哪種方法最適合你的業務和技術需求。如果你們運維自動化能力儲備不夠，肯定是越簡單越好，建議藍綠發布，如果業務對用戶依賴很強，建議灰度發布。如果是K8S平台，滾動更新是現成的方案，建議先直接使用。

藍綠發布：兩套環境交替升級，舊版本保留一定時間便於回滾。

紅黑發布: 申請新環境,刪除老版本

灰度發布：根據比例將老版本升級，例如80%用戶訪問是老版本，20%用戶訪問是新版本。

滾動發布：按批次停止老版本實例，啟動新版本實例。

項目邏輯上分為AB組，在項目系統時，首先把A組從負載均衡中摘除，進行新版本的部署。B組仍然繼續提供服務。

當A組升級完畢，負載均衡重新接入A組，再把B組從負載列表中摘除，進行新版本的部署。A組重新提供服務。

1.如果出問題，影響范圍較小；
2.發布策略簡單；
3.用戶無感知，平滑過渡；
4.升級/回滾速度快。

1.需要准備正常業務使用資源的兩倍以上伺服器，防止升級期間單組無法承載業務突發；
2.短時間內浪費一定資源成本；
3.基礎設施無改動，增大升級穩定性。

當前服務都運行在集群A上

在雲上申請一個黑色集群 B，在 B 上部署新版本的服務； 等到 B 升級完成

最後一次性地把負載均衡全部指向 B,並把 A 集群從負載均衡列表中刪除，並釋放集群 A 中所有機器。

可以看到，與藍綠部署相比，紅黑部署只不過是充分利用了雲計算的彈性伸縮優勢，從而獲得了兩個收益：一是，簡化了流程；二是，避免了在升級的過程中，由於只有一半的伺服器提供服務，而可能導致的系統過載問題。

1.從LB摘掉灰度伺服器，升級成功後再加入LB；
2.少量用戶流量到新版本；
3.如果灰度伺服器測試成功，升級剩餘伺服器。

1.保證整體系統穩定性，在初始灰度的時候就可以發現、調整問題，影響范圍可控；
2.新功能逐步評估性能，穩定性和健康狀況，如果出問題影響范圍很小，相對用戶體驗也少；
3.用戶無感知，平滑過渡。

自動化要求高

滾動發布是指每次只升級一個或多個服務，升級完成後加入生產環境，不斷執行這個過程，直到集群中的全部舊版本升級新版本。

1.保證整體系統穩定性，在初始灰度的時候就可以發現、調整問題，影響范圍可控；
2.新功能逐步評估性能，穩定性和健康狀況，如果出問題影響范圍很小，相對用戶體驗也少；
3.用戶無感知，平滑過渡。

自動化要求高

『柒』 灰度發布

灰度發布又稱金絲雀發布，起源是早起礦井工人發現金絲雀對瓦斯氣體很敏感。因此曠工在下井之前都會先將一隻金絲雀放到井中，如果金絲雀不叫了，就代表瓦斯濃度高。

度娘說的挺好的~

在灰度發布開始後，先啟動一個新版本應用，但是並不直接將流量切過來，而是測試人員對新版本進行線上測試，啟動的這個新版本應用，就是我們的金絲雀。如果沒有問題，那麼可以將少量的用戶流量導入到新版本上，然後再對新版本做運行狀態觀察，收集各種運行時數據，如果此時對新舊版本做各種數據對比，就是所謂的A/B測試。

當確認新版本運行良好後，再逐步將更多的流量導入到新版本上，在此期間，還可以不斷地調整新舊兩個版本的運行的伺服器副本數量，以使得新版本能夠承受越來越大的流量壓力。直到將100%的流量都切換到新版本上，最後關閉剩下的老版本服務，完成灰度發布。

如果在灰度發布過程中（灰度期）發現了新版本有問題，就應該立即將流量切回老版本上，這樣，就會將負面影響控制在最小范圍內。

『捌』 藍綠發布、滾動發布、灰度發布（金絲雀發布）、A/B測試

在一般情況下，升級伺服器端應用，需要將應用源碼或程序包上傳到伺服器，然後停止掉老版本服務，再啟動新版本。但是這種簡單的發布方式存在兩個問題，

（1）在新版本升級過程中，服務是會暫時中斷的。

（2）如果新版本有BUG，升級失敗，回滾起來也非常麻煩，容易造成更長時間的服務不可用。

（3）新功能體驗不好，版本升級過程中帶來的流量有損，造成用戶流失。

為了解決這些問題，人們研究出了幾種常見的服務發布策略，下面一一介紹。

所謂藍綠部署，是指同時運行兩個版本的應用，

如上圖所示，藍綠發布部署時候需要對服務的新版本進行冗餘部署並不停止掉老版本，一般新版本的機器規格和數量與舊版本保持一致，相當於該服務有兩套完全相同的部署環境，只不過此時只有舊版本在對外提供服務，新版本作為熱備。當服務進行版本升級時，我們只需將流量全部切換到新版本即可，舊版本作為熱備。由於冗餘部署的緣故，如果新版本上線後出現嚴重的程序 BUG，那麼我們只需將流量全部切回至舊版本，大大縮短故障恢復的時間。待新版本完成 BUG 修復並重新部署之後，再將舊版本的流量切換到新版本。

藍綠發布通過使用額外的機器資源來解決服務發布期間的不可用問題，當服務新版本出現故障時，也可以快速將流量切回舊版本。

藍綠部署的優點：

1、部署結構簡單，運維方便；

2、服務升級過程操作簡單，周期短。

藍綠部署的缺點：

1、資源冗餘，需要部署兩套生產環境；

2、新版本故障影響范圍大。

ps：當然，藍綠發布也可以在系統非繁忙時段進行升級，把現有的集群伺服器一分為二，一半升級一半保留並隔離，待到新系統穩定後升級另一半伺服器，並解除隔離。從而充分利用現有伺服器資源。

滾動發布能夠解決掉藍綠部署時對硬體要求增倍的問題。

所謂滾動升級，就是在升級過程中，並不一下子啟動所有新版本，是先啟動一台新版本，再停止一台老版本，然後再啟動一台新版本，再停止一台老版本，直到升級完成，這樣的話，如果日常需要10台伺服器，那麼升級過程中也就只需要11台就行了。

但是滾動升級有一個問題，在開始滾動升級後，流量會直接流向已經啟動起來的新版本，這個時候，新版本是不一定可用的，比如需要進一步的測試才能確認。那麼在滾動升級期間，整個系統就處於非常不穩定的狀態，如果發現了問題，也比較難以確定是新版本還是老版本造成的問題。

為了解決這個問題，我們需要為滾動升級實現流量控制能力。

在灰度發布開始後，先啟動一個新版本應用，但是並不直接將流量切過來，而是測試人員對新版本進行線上測試，啟動的這個新版本應用，就是我們的金絲雀。驗證新版本符合預期後，逐步調整流量權重比例，使得流量慢慢從老版本遷移至新版本，期間可以根據設置的流量比例，對新版本服務進行擴容，同時對老版本服務進行縮容，使得底層資源得到最大化利用。

相比於前兩種發布策略，灰度發布的思想則是將少量的請求引流到新版本上，因此部署新版本服務只需極小數的機器。

灰度發布可以基於用戶請求的元信息將流量路由到新版本，這是一種基於請求內容匹配的灰度發布策略。只有匹配特定規則的請求才會被引流到新版本，常見的做法包括基於 Http Header 和 Cookie。基於 Http Header 方式的例子，例如 User-Agent 的值為 Android 的請求 （來自安卓系統的請求）可以訪問新版本，其他系統仍然訪問舊版本。基於 Cookie 方式的例子，Cookie 中通常包含具有業務語義的用戶信息，例如VIP可以訪問新版本，普通用戶用戶仍然訪問舊版本（或者相反）。

如圖，某服務當前版本為 v1，現在新版本 v2 要上線。為確保流量在服務升級過程中平穩無損，採用金絲雀發布方案，逐步將流量從老版本遷移至新版本。

灰度發布期間再對新版本做運行狀態觀察，收集各種運行時數據，如果此時對新舊版本做各種數據對比， 就是所謂的A/B測試。 通過在監控平台觀察舊版本與新版本的成功率、RT 對比，當新版本整體服務預期後，即可將所有請求切換到新版本。

灰度發布的優點：

1、可以對特定的請求或者用戶提供服務新版本，新版本故障影響范圍小；

2、發布期間逐步對新版本擴容，同時對老版本縮容，資源利用率高。

3、需要構建完備的監控平台，用於對比不同版本之間請求狀態的差異（做A/B測試）。

灰度發布的缺點：

1、仍然可能存在資源冗餘，因為無法准確評估請求容量；

2、如果流量無差別地導向新版本，可能會影響用戶的體驗；

3、發布周期長。

最佳實踐：

在新版本應用發布時，為了伺服器不停機升級且影響最小，使用灰度發布策略，

在灰度發布開始時，使用HTTP Header等策略 匹配指定測試人員的流量到新版本上，

然後當新版本內部測試通過後，可以再按百分比、白名單等，將用戶流量一點一點導入到新版本中，直到將流量全部導入到新版本上，最後完成升級，

如果期間發現問題，就立即取消升級，將流量切回到老版本。

運用灰度發布，就再也不需要加班到深夜進行停機升級了，在白天就可以放心大膽地、安全地發布新版本^_^。

參考：

https://blog.csdn.net/luo15242208310/article/details/118888496

https://developer.aliyun.com/article/847533

『玖』 Spring微服務灰度發布（熱部署）的實現（二）

接著上篇說，我們微服務中用到的nepxion discovery主要採用了三種灰度發布方式，一種是web圖形化界面發布，二是zuul過濾器灰度發布，三是業務參數策略灰度發布。下面將重點介紹三種方式的實現。

一、web圖形化界麵灰度發布

因為我們項目用到了eureka注冊中心，所以選擇web圖形化界麵灰度發布比較合適。

1） 首先需要建立一個discovery控制台工程console, 埠為2222，控制台工程負責web圖形化界面請求的處理，運行console工程。

2） 下載discovery ui,地址：https://github.com/Nepxion/DiscoveryUI，運行discovery UI，埠為8090

3）瀏覽器中輸入localhost:8090,即可打開控制台，如下

注意：全鏈路灰度發布需要在「配置中心」下才可用。灰度發布配置中心，負責存儲全鏈路灰度發布規則，並將規則推送到各個微服務中。而配置中心可用nacos，redis等，Discovery 中提供了相應配置中心的插件包。

二、zuul網關過濾器灰度發布

通過網關過濾器傳遞Http Header的方式傳遞全鏈路灰度路由規則。下面代碼只適用於Zuul和Spring Cloud Gateway網關，Service微服務不需要加該方式。

三、業務參數在策略類中自定義灰度路由規則

通過策略方式自定義灰度路由規則。下面代碼既適用於Zuul和Spring Cloud Gateway網關，也適用於Service微服務，同時全鏈路中網關和服務都必須加該方式

上面說了具體灰度規則發布方式，那究竟怎麼定義灰度規則呢？？

規則是基於XML或者Json為配置方式，存儲於本地文件或者遠程配置中心，可以通過遠程配置中心修改的方式達到規則動態化。其核心代碼參考discovery-plugin-framework以及它的擴展、discovery-plugin-config-center以及它的擴展和discovery-plugin-admin-center等，規則示例

XML示例（Json示例見discovery-springcloud-example-service下的rule.json）

黑/白名單的IP地址注冊的過濾規則

微服務啟動的時候，禁止指定的IP地址注冊到服務注冊發現中心。支持黑/白名單，白名單表示只允許指定IP地址前綴注冊，黑名單表示不允許指定IP地址前綴注冊。規則如何使用，見示例說明

最大注冊數的限制的過濾規則

微服務啟動的時候，一旦微服務集群下注冊的實例數目已經達到上限（可配置），將禁止後續的微服務進行注冊。規則如何使用，見示例說明

黑/白名單的IP地址發現的過濾規則

微服務啟動的時候，禁止指定的IP地址被服務發現。它使用的方式和「黑/白名單的IP地址注冊的過濾規則」一致

版本訪問的灰度發布規則

版本權重的灰度發布規則

全局版本權重的灰度發布規則

區域權重的灰度發布規則

全局區域權重的灰度發布規則

網關端全鏈路路由策略的灰度發布規則

注意 路由策略的入口有三個（以{"discovery-springcloud-example-a":"1.0", "discovery-springcloud-example-b":"1.0", "discovery-springcloud-example-c":"1.0;1.2"}）為例：

其作用的優先順序為外界傳入>網關Filter指定>配置中心或者本地rule.xml配置

您可以根據自己需求，自由定義灰度發布規則，靈活實現微服務的灰度發布。

源碼位置：https://github.com/Nepxion/Discovery

『拾』 計算機術語中「灰度發布」的英文是什麼

Gray released in computer terms。

灰度發布（又名金絲雀發布）是指在黑與白之間，能夠平滑過渡的一種發布方式。

灰度分布讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什麼反對意見，那麼逐步擴大范圍，把所有用戶都遷移到B上面來。

注意事項

灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。

對於一般的小系統並不需要單獨的灰度發布引擎，可以參考A/B測試中做法，在頁面JavaScript或伺服器端實現分流的規則即可。但對於大型的互聯網應用而言，單獨的用於管理用戶分流的發布引擎就很有必要了。