前言

相信很多小伙伴們都聽說過灰度發布，但是不一定知道如何實現？今天我們就介紹一下基本原理，以及提供代碼實現給小伙伴們。

灰度概念

即原來的生產環境是1.0版本，那現在我們需要升級到2.0版本，但是我們需要驗證2.0版本，在生產環境不會出問題，而且要穩定后，才能夠完全切換為2.0。

小伙伴們就會問，2.0版本應該我們測試人員 測試了啊，肯定沒有問題啊。升級到2.0，直接升級就行了啊。

這個是不對的，因為生產環境有很多場景是獨有的，如用戶流量，數據量等。所以必須要驗證2.0的穩定性；升級步驟如下：

1)100%的用戶流量打到1.0版本上面；但測試人員可以通過測試工具指定線上2.0版本，即測試人員請求的是2.0版本。2)測試初步驗證后，可以先分5%的用戶流量到2.0版本，95%的用戶流量還是在1.0版本3)查看2.0的穩定情況，分階段的分配用戶流量4)完成切換到2.0版本，下線1.0版本；在下線1.0版本的時候不同的方案 會遇到不同的坑

實現原理一

老顧這個灰度的框架是建立在springcloud alibaba生態的，注冊中心和配置中心都是使用的是nacos；我們先來看看整個系統架構，在升級狀態是什么情況：

在spring cloud中，不管是網關 -> 服務A -> 服務B -> 服務C整個請求，網關是怎么知道有哪些服務A的？服務A是怎么知道有哪些服務B？服務B有哪些服務C？

這個是因為我們的所有服務都注冊到了nacos注冊中心里面，然后每個服務實例會通過5秒的心跳去請求nacos，獲取到nacos里面的注冊信息。

這個就是很重要的一個點，服務信息的同步；我們可以重寫每個服務實例去拉取服務信息的時候，做一些過濾處理。舉個例子，我們怎么保證服務A(1.0)只訪問服務B(1.0)。

服務A(1.0)在調用服務B時，需要去拉取服務B的服務實例信息，當我們發現服務B中有2.0版本時，就直接過濾掉；1.0才同步到本地緩存；通過這原理，就是保證了服務A(1.0)實例，只能訪問服務B(1.0)

那怎么重寫拉取服務呢？就是繼承NacosServerList重寫getInitialListOfServers、getUpdatedListOfServers方法，直接上源代碼。

實現原理二

只實現過濾掉不需要的版本，是不夠的；因為我們有另一個需求，就是流量權重；即服務A可以訪問服務B(1.0)，也就是訪問服務B(2.0)；只是流量權重占比不一樣而已；那怎么實現呢？

那就要用到我們客戶端client的rabbion組件了，這個組件主要用來調用服務實例的，而是可以實現負載均衡；那我們就可以重寫負載均衡算法，實現自定義的流量權重這個需求。

具體實現就是繼承ZoneAvoidanceRule

重寫Server choose(Object key)，直接上代碼

public class ZoneAvoidanceRuleDecorator extends ZoneAvoidanceRule { 。。。。。。 @Override? ? public Server choose(Object key) { //todo 選擇的邏輯 }}

知道了基本的原理后，就可以直接去寫了。

實現原理三

另一個需求，就是我們需要考慮到在線動態的改變灰度路由的規則，而不是每次改變了規則，需要重新啟動服務，這個就不對了。

這個的實現可以考慮利用nacos自身的功能。去訂閱nacos的配置中心的變化，從而達到動態更新。

案例

因為篇幅原因，老顧這里只介紹一些原理，具體源代碼，可以到git上面去獲取，要給個star哦。

https://gitee.com/gujiachun/gray

引入依賴

1、微服務項目需引入gray-plugin-framework-starter-service項目。

<dependency>? ?<groupId>com.rainbow.graygroupId>? ?<artifactId>gray-plugin-framework-starter-serviceartifactId>? ?<version>1.0.0-SNAPSHOTversion>dependency>

2、網關項目需引入gray-plugin-framework-starter-gateway項目。

<dependency>? ?<groupId>com.rainbow.graygroupId>? ?<artifactId>gray-plugin-framework-starter-gatewayartifactId>? ?<version>1.0.0-SNAPSHOTversion>dependency>

3、本組件推薦使用遠程配置的方法，配置rule規則，現在只支持nacos配置中心。

4、組件支持全局訂閱，或局部訂閱。

全局訂閱即：DataId = group1，Group=group1；即DataId也為group名稱，這樣每個微服務以及網關都只訂閱的是同一個rule規則。

局部訂閱即：DataId = 服務名稱，Group=group1；即DataID是服務名稱，即只有這個服務訂閱了rule規則；其他服務不適用。

(推薦全局訂閱，因為灰度發布一般針對所有的服務生效；而且規則里面可以細化到每個服務的規則)

規則說明

使用說明

1、配置nacos，在bootstrap.properties中配置nacos注冊中心。

spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848spring.cloud.nacos.discovery.username=nacosspring.cloud.nacos.discovery.password=nacosspring.cloud.nacos.discovery.namespace=sit

2、在bootstrap.properties中組件需要的配置。

nacos.server-addr=${spring.cloud.nacos.discovery.server-addr}nacos.username=${spring.cloud.nacos.discovery.username}nacos.password=${spring.cloud.nacos.discovery.password}nacos.plugin.namespace=${spring.cloud.nacos.discovery.namespace}

3、在application.properties 配置元數據，非常重要，這個就是每個服務不同的版本version，地域region,環境env，區zone相關的配置。

spring.cloud.nacos.discovery.metadata.group=example-service-groupspring.cloud.nacos.discovery.metadata.version=1.0spring.cloud.nacos.discovery.metadata.region=devspring.cloud.nacos.discovery.metadata.env=env1spring.cloud.nacos.discovery.metadata.zone=zone1

4、親和性

啟動和關閉可用區親和性，即同一個可用區的服務才能調用，同一個可用區的條件是調用端實例和提供端實例的元數據Metadata的zone配置值必須相等。缺失則默認為false

spring.application.zone.affinity.enabled=true

啟動和關閉可用區親和性失敗后的路由，即調用端實例沒有找到同一個可用區的提供端實例的時候，當開關打開，可路由到其它可用區或者不歸屬任何可用區，當開關關閉，則直接調用失敗。缺失則默認為true

spring.application.zone.route.enabled=true

外部參數Header

通過前端(Postman)方式傳入灰度路由策略，來代替配置中心方式，傳遞全鏈路路由策略。這樣就可以實現由測試人員自行選擇走哪些路徑。

注意：當配置中心和外部參數都配置后，會先從配置中心的規則會先過濾執行，然后外部參數再過濾的原則

-版本匹配策略，Header格式如下任選一個

n-d-version=1.0n-d-version={"discovery-guide-service-a":"2.0", "discovery-guide-service-b":"2.0"}

-版本權重策略，Header格式如下任選一個

n-d-version-weight=1.0=90;1.1=10n-d-version-weight={"discovery-guide-service-a":"1.0=90;1.1=10", "discovery-guide-service-b":"1.0=90;1.1=10"}

-區域匹配策略，Header格式如下任選一個

n-d-region=qan-d-region={"discovery-guide-service-a":"qa", "discovery-guide-service-b":"qa"}

-區域權重策略，Header格式如下任選一個

n-d-region-weight=dev=99;qa=1n-d-region-weight={"discovery-guide-service-a":"dev=99;qa=1", "discovery-guide-service-b":"dev=99;qa=1"}

-IP地址和端口匹配策略，Header格式如下任選一個

n-d-address={"discovery-guide-service-a":"127.0.0.1:3001", "discovery-guide-service-b":"127.0.0.1:4002"}n-d-address={"discovery-guide-service-a":"127.0.0.1", "discovery-guide-service-b":"127.0.0.1"}n-d-address={"discovery-guide-service-a":"3001", "discovery-guide-service-b":"4002"}

-環境隔離下動態環境匹配策略

n-d-env=env1

-服務下線實時性的流量絕對無損，全局唯一ID屏蔽策略

n-d-id-blacklist=e92edde5-0153-4ec8-9cbb-b4d3f415aa33;af043384-c8a5-451e-88f4-457914e8e3bc

-服務下線實時性的流量絕對無損，IP地址和端口屏蔽策略

n-d-address-blacklist=192.168.43.101:1201;192.168.*.102;1301

當外界傳值Header的時候，網關也設置并傳遞同名的Header，需要決定哪個Header傳遞到后邊的服務去。需要通過如下開關做控制：

# 當外界傳值Header的時候，網關也設置并傳遞同名的Header，需要決定哪個Header傳遞到后邊的服務去。如果下面開關為true，以網關設置為優先，否則以外界傳值為優先。缺失則默認為truespring.application.strategy.gateway.header.priority=false# 當以網關設置為優先的時候，網關未配置Header，而外界配置了Header，仍舊忽略外界的Header。缺失則默認為truespring.application.strategy.gateway.original.header.ignored=true# 當外界傳值Header的時候，網關也設置并傳遞同名的Header，需要決定哪個Header傳遞到后邊的服務去。如果下面開關為true，以網關設置為優先，否則以外界傳值為優先。缺失則默認為truespring.application.strategy.zuul.header.priority=false# 當以網關設置為優先的時候，網關未配置Header，而外界配置了Header，仍舊忽略外界的Header。缺失則默認為truespring.application.strategy.zuul.original.header.ignored=true

總結

整體灰度的功能還是挺多，不過實現的原理就是上面介紹的原理；這里也要感謝開源社區的nepxion discovery開源項目，借鑒了設計思路，以及一些代碼設計，簡化了實現。

分享、在看與點贊都在這兒點下給小編加點料

總結

以上是生活随笔為你收集整理的灰度值怎么降级_微服务生态的灰度发布如何实现？的全部內容，希望文章能夠幫你解決所遇到的問題。

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