端口：8888，方便起見直接讀取配置文件，生產環境可以讀取git。application-dev.properties為全局配置。先啟動配置中心，所有服務的配置（包括注冊中心的地址）均從配置中心讀取。
consumer 服務消費者
端口：18090，調用服務提供者，為了演示header傳遞。
core 框架核心包
核心jar包，所有微服務均引用該包，使用AutoConfig實現免配置，模擬生產環境下spring-cloud的使用。
eureka 注冊中心
端口：8761，/metadata端點實現metadata信息配置。
provider 服務提供者
端口：18090，服務提供者，無特殊邏輯。
zuul 網關
端口：8080，演示解析token獲得label並放入header往后傳遞
實踐：降級、限流、滾動、灰度、AB、金絲雀…
我本人是從dubbo轉過來的，經常看到社區里面拿dubbo和spring-cloud做對比，一對比就提到dubbo所謂的降級、限流功能。spring-cloud默認沒有這個能力，讓我們來擴展spring-cloud，使她具備比dubbo更牛逼的各種能力。
所謂的降級、限流、滾動、灰度、AB、金絲雀等等等等，在我看來無非就是擴展了服務路由能力而已。這里說的服務降級，說的是服務A部署多個實例，實例級別的降級限流。如果要做整個服務A的降級，直接采用docker自動擴容縮容即可。
我們先來看應用場景：服務A 發布了1.0版，部署了3個實例A1、A2、A3，現在要對服務A進行升級，由1.0升級到2.0。先將A1服務流量關閉，使A2、A3負擔；升級A1代碼版本到2.0；將A1流量調整為1%，觀察新版本運行情況，如果運行穩定，則逐步提升流量5%、10%直到完全放開流量控制。A2、A3重復上述步驟。
在上述步驟中，我們想讓特別的人使用2.0，其他人還是使用1.0版，穩定后再全員開放。
我們想不依賴sleuth做鏈路跟蹤，想自己實現一套基於ELK的鏈路跟蹤。
我們還有各種千奇百怪的想法。。。
實現思路
要實現這些想法，我們需要對spring-cloud的各個組件、數據流非常熟悉，這樣才能知道該在哪里做擴展。一個典型的調用：
外網 --> Zuul網關 --> 服務A --> 服務B --> ...
spring-cloud跟dubbo一樣都是客戶端負載均衡，所有調用均由Ribbon來做負載均衡選擇服務器，所有調用前后會套一層hystrix做隔離、熔斷。服務間調用均用帶LoadBalanced注解的RestTemplate發出。
RestTemplate --> Ribbon --> hystrix
通過上述分析我們可以看到，我們的擴展點就在Ribbon，Ribbon根據我們的規則，選擇正確的服務器即可。
我們先來一個dubbo自帶的功能：基於權重的流量控制。dubbo自帶的控制台可以設置服務實例粒度的半權，倍權。其實就是在客戶端負載均衡時，選擇服務器帶上權重即可，spring-cloud默認是ZoneAvoidanceRule，優先選擇相同Zone下的實例，實例間采用輪詢方式做負載均衡。我們的想把基於輪詢改為基於權重即可。接下來的問題是，每個實例的權重信息保存在哪里？從哪里取？dubbo放在zookeeper中，spring-cloud放在eureka中。我們只需從eureka拿每個實例的權重信息，然后根據權重來選擇服務器即可。具體代碼LabelAndWeightMetadataRule（先忽略里面的優先匹配label相關代碼）。
放入核心框架
LabelAndWeightMetadataRule寫好了，那么我們如何使用它，使之生效呢？有3種方式。
1）寫個AutoConfig將LabelAndWeightMetadataRule聲明成@Bean，用來替換默認的ZoneAvoidanceRule。這種方式在技術驗證、開發測試階段使用短平快。但是這種方式是強制全局設置，無法個性化。
2）由於spring-cloud的Ribbon並沒有實現netflix Ribbon的所有配置項。netflix配置全局rule方式為：ribbon.NFLoadBalancerRuleClassName=package.YourRule，spring-cloud並不支持，spring-cloud直接到服務粒度，只支持SERVICE_ID.ribbon.NFLoadBalancerRuleClassName=package.YourRule。我們可以擴展org.springframework.cloud.netflix.ribbon.PropertiesFactory修正spring cloud ribbon未能完全支持netflix ribbon配置的問題。這樣我們可以將全局配置寫到配置中心的application-dev.properties全局配置中，然后各個微服務還可以根據自身情況做個性化定制。但是PropertiesFactory屬性均為私有，應該是spring cloud不建議在此擴展。參見 https://github.com/spring-cloud/spring-cloud-netflix/issues/1741。
3）使用spring cloud官方建議的@RibbonClient方式。該方式僅存在於spring-cloud單元測試中（在我提問后，現在還存在於spring-cloud issue list）。具體代碼參見DefaultRibbonConfiguration、CoreAutoConfiguration。
實際測試
依次開啟 config eureka provide（開兩個實例，通過啟動參數server.port指定不同端口區分） consumer zuul
訪問 http://localhost:8761/metadata.html 這是我手寫的一個簡單的metadata管理界面，分別設置兩個provider實例的weight值（設置完需要一段2分鍾才能生效），然后訪問 http://localhost:8080/provider/user 多刷幾次來測試zuul是否按權重發送請求，也可以訪問 http://localhost:8080/consumer/test 多刷幾次來測試consumer是否按權重來調用provide服務。
進階，基於標簽
基於權重的搞定之后，接下來才是重頭戲：基於標簽的路由。入口請求含有各種標簽，然后我們可以根據標簽幻化出各種各樣的路由規則。例如只有標注為粉絲的用戶才使用新版本（灰度、AB、金絲雀），例如標注為中國的用戶請求必須發送到中國的服務器（全球部署），例如標注為寫的請求必須發送到專門的寫服務實例（讀寫分離），等等等等，唯一限制你的就是你的想象力。
實現思路
根據標簽的控制，我們當然放到之前寫的Ribbon的rule中，每個實例配置的不同規則也是跟之前一樣放到注冊中心的metadata中，關鍵是標簽數據如何傳過來。權重隨機的實現思路里面有答案，請求都通過zuul進來，因此我們可以在zuul里面給請求打標簽，基於用戶，IP或其他看你的需求，然后將標簽信息放入ThreadLocal中，然后在Ribbon Rule中從ThreadLocal拿出來使用就可以了。然而，按照這個方式去實驗時，發現有問題，拿不到ThreadLocal。原因是有hystrix這個東西，回憶下hystrix的原理，為了做到故障隔離，hystrix啟用了自己的線程，不在同一個線程ThreadLocal失效。那么還有什么辦法能夠將標簽信息一傳到底呢，想想之前有沒有人實現過類似的東西，沒錯sleuth，他的鏈路跟蹤就能夠將spam傳遞下去，翻翻sleuth源碼，找找其他資料，發現可以使用HystrixRequestVariableDefault，這里不建議直接使用HystrixConcurrencyStrategy，會和sleuth的strategy沖突。代碼參見CoreHeaderInterceptor。現在可以測試zuul里面的rule，看能否拿到標簽內容了。
這里還不是終點，解決了zuul的路由，服務A調服務B這里的路由怎么處理呢？zuul算出來的標簽如何往后面依次傳遞下去呢，我們還是抄sleuth：把標簽放入header，服務A調服務B時，將服務A header里面的標簽放到服務B的header里，依次傳遞下去。這里的關鍵點就是：內部的微服務在接收到發來的請求時（zuul-》A，A-》B都是這種情況）我們將請求放入ThreadLocal，哦，不對，是HystrixRequestVariableDefault，還記得上面說的原因么：）。這個容易處理，寫一個spring mvc攔截器即可，代碼參見CoreHeaderInterceptor。然后發送請求時自動帶上這個里面保存的標簽信息，參見RestTemplate的攔截器CoreHttpRequestInterceptor。到此為止，技術上全部走通實現。
總結一下：zuul依據用戶或IP等計算標簽，並將標簽放入header里向后傳遞，后續的微服務通過攔截器，將header里的標簽放入RestTemplate請求的header里繼續向后接力傳遞。標簽的內容通過放入類似於ThreadLocal的全局變量（HystrixRequestVariableDefault），使Ribbon Rule可以使用。
測試
參見PreFilter源碼，模擬了幾個用戶的標簽，參見LabelAndWeightMetadataRule源碼，模擬了OR AND兩種標簽處理策略。依次開啟 config eureka provide（開兩個實例，通過啟動參數server.port指定不同端口區分） consumer zuul
訪問 http://localhost:8761/metadata.html 設置第一個provide 實例 orLabel為 CN,Test 發送請求頭帶入Authorization: emt 訪問 http://localhost:8080/provider/user 多刷幾次，可以看到zuul所有請求均路由給了第一個實例。訪問 http://localhost:8080/consumer/test 多刷幾次，可以看到，consumer調用均路由給了第一個實例。
設置第二個provide 實例 andLabel為 EN,Male 發送請求頭帶入Authorization: em 訪問 http://localhost:8080/provider/user 多刷幾次，可以看到zuul所有請求均路由給了第二個實例。訪問 http://localhost:8080/consumer/test 多刷幾次，可以看到，consumer調用均路由給了第二個實例。
Authorization頭還可以設置為PreFilter里面的模擬token來做測試，至此所有內容講解完畢，技術路線拉通，剩下的就是根據需求來完善你自己的路由策略啦。
http://www.tuicool.com/articles/3ymY3er
1.2 金絲雀發布
實踐要點
1、金絲雀發布一般先發 1 台，或者一個小比例，例如 2% 的服務器，主要做流量驗證用，也稱為金絲雀 (Canary) 測試（國內常稱灰度測試）。以前曠工開礦下礦洞前，先會放一只金絲雀進去探是否有有毒氣體，看金絲雀能否活下來，金絲雀發布由此得名。簡單的金絲雀測試一般通過手工測試驗證，復雜的金絲雀測試需要比較完善的監控基礎設施配合，通過監控指標反饋，觀察金絲雀的健康狀況，作為后續發布或回退的依據。
2、如果金絲測試通過，則把剩余的 V1 版本全部升級為 V2 版本。如果金絲雀測試失敗，則直接回退金絲雀，發布失敗。
優勢：
用戶體驗影響小，金絲雀發布過程出現問題只影響少量用戶
不足：
發布自動化程度不夠，發布期間可引發服務中斷
適用場合：
1、對新版本功能或性能缺乏足夠信心
2、用戶體驗要求較高的網站業務場景
3、缺乏足夠的自動化發布工具研發能力
2.1 藍綠發布（雙服務器組）
藍綠發布僅適用於雙服務器組發布，可以認為是對蠻力發布的一種簡單優化發布方式。
1、V1 版本稱為藍組，V2 版本稱為綠組，發布時通過 LB 一次性將流量從藍組直接切換到綠組，不經過金絲雀和滾動發布，藍綠發布由此得名；
2、出現問題回退也很直接，通過 LB 直接將流量切回藍組。
3、發布初步成功后，藍組機器一般不直接回收，而是留一個待觀察期，視具體情況觀察期的時間可長可短，觀察期過后確認發布無問題，則可以回收藍組機器。
優勢：
（1）升級切換和回退速度非常快
不足：
（1）切換是全量的，如果 V2 版本有問題，則對用戶體驗有直接影響；
（2）需要兩倍機器資源；
適用場合：
（1）對用戶體驗有一定容忍度的場景
（2）機器資源有富余或者可以按需分配（AWS 雲，或自建容器雲）
（3）暫不具備復雜滾動發布工具研發能力
https://www.cnblogs.com/apanly/p/8784096.html