（Spring Cloud微服務實戰-發佈篇）spring cloud zuul灰度發佈

一、灰度發佈解決線上什麼問題？

公司項目，每次發佈上線都是在晚上時間段進行發佈，這嚴重打亂了我的的做息，尤爲是下單業務，每次上線，都是驚心膽顫的，爲了消除這【心理】問題，在新項目時，須要把灰度發佈引入進來，從而達到，媽媽不再用擔憂個人做息了，想何時上線，看心情。

灰度發佈，我的理解，主要是採用一個切換流量的思路來上線或者用於其餘場景（自行百度）

 

二、灰度發佈歸類

網上大部分考慮的都不夠全面，有的說nginx+lua，有的說k8s，有的spring cloud zuul....太亂了

我的大總結：整個架構面臨以下幾種狀況的灰度發佈

    a、nginx+upstrem的tomcat的應用，須要實現，禁用流量到tomcat：nginx面臨控制灰度發佈

        實現思路：nginx+lua，openresty

    b、spring cloud zuul+通常的web服務/eureka上的服務（未註冊到eureka和註冊到eureka），須要實現，禁用流量到通常web服務，zuul面臨控制灰度發佈

    c、由於服務與服務之間也存在調用(不必定通過zuul網關)， 註冊到eureka的服務，須要實現，各個服務禁用流量，各個服務面臨灰度發佈

        實現思路：eureka的端點， 來禁用註冊中心上的實例，而後等待sleep 1-2分鐘，而後平滑的shutdown

 

三、但本文的重點描述，如上第二種(b)狀況，詳細實現

注意：網上有說採用ribbon-discovery-filter-spring-cloud-starter（https://github.com/jmnarloch/ribbon-discovery-filter-spring-cloud-starter）

請慎重，由於剛開始我也是採用ribbon-discovery-filter-spring-cloud-starter的方式來實現，當採用jemter進行併發測試時，坑坑無數 。

那麼怎麼來實現：

實現思路：實現自定義rule，經過重寫rule來實現灰度發佈，可是.......若是我部署多臺zuul，也會有問題，從而改進思路： 實現自定義rule，而後將須要禁用流量的服務信息，放於redis裏面，從而實現多個zuul實例的灰度發佈。每次須要上線一個服務時，經過sh腳本在將此實例信息放於redis，此時該服務實例就不會有流量進入，再進行發佈

實現代碼：

    a)、 實現自定義predicate，繼承AbstractServerPredicate

    b)、 實現自定義rule，繼承PredicateBasedRule

    c)、 在Configuration類裏面，注入自定義rule