spring cloud 實踐
源碼地址：https://github.com/charlesvhe/spring-cloud-practice
項目結構
config 配置中心
端口：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來做測試，至此所有內容講解完畢，技術路線拉通，剩下的就是根據需求來完善你自己的路由策略啦。
