spring cloud 實踐
源碼地址：https://github.com/charlesvhe/spring-cloud-practice
項目結(jié)構(gòu)
config 配置中心
端口：8888，方便起見直接讀取配置文件，生產(chǎn)環(huán)境可以讀取git。application-dev.properties為全局配置。先啟動配置中心，所有服務(wù)的配置（包括注冊中心的地址）均從配置中心讀取。
consumer 服務(wù)消費者
端口：18090，調(diào)用服務(wù)提供者，為了演示header傳遞。
core 框架核心包
核心jar包，所有微服務(wù)均引用該包，使用AutoConfig實現(xiàn)免配置，模擬生產(chǎn)環(huán)境下spring-cloud的使用。
eureka 注冊中心
端口：8761，/metadata端點實現(xiàn)metadata信息配置。
provider 服務(wù)提供者
端口：18090，服務(wù)提供者，無特殊邏輯。
zuul 網(wǎng)關(guān)
端口：8080，演示解析token獲得label并放入header往后傳遞
實踐：降級、限流、滾動、灰度、AB、金絲雀等等等等
我本人是從dubbo轉(zhuǎn)過來的，經(jīng)常看到社區(qū)里面拿dubbo和spring-cloud做對比，一對比就提到dubbo所謂的降級、限流功能。spring-cloud默認沒有這個能力，讓我們來擴展spring-cloud，使她具備比dubbo更牛逼的各種能力。
所謂的降級、限流、滾動、灰度、AB、金絲雀等等等等，在我看來無非就是擴展了服務(wù)路由能力而已。這里說的服務(wù)降級，說的是服務(wù)A部署多個實例，實例級別的降級限流。如果要做整個服務(wù)A的降級，直接采用docker自動擴容縮容即可。
我們先來看應(yīng)用場景：
服務(wù)A 發(fā)布了1.0版，部署了3個實例A1、A2、A3，現(xiàn)在要對服務(wù)A進行升級，由1.0升級到2.0。先將A1服務(wù)流量關(guān)閉，使A2、A3負擔；升級A1代碼版本到2.0；將A1流量調(diào)整為1%，觀察新版本運行情況，如果運行穩(wěn)定，則逐步提升流量5%、10%直到完全放開流量控制。A2、A3重復上述步驟。
在上述步驟中，我們想讓特別的人使用2.0，其他人還是使用1.0版，穩(wěn)定后再全員開放。
我們想不依賴sleuth做鏈路跟蹤，想自己實現(xiàn)一套基于ELK的鏈路跟蹤。
我們還有各種千奇百怪的想法。。。
實現(xiàn)思路
要實現(xiàn)這些想法，我們需要對spring-cloud的各個組件、數(shù)據(jù)流非常熟悉，這樣才能知道該在哪里做擴展。一個典型的調(diào)用：外網(wǎng)-》Zuul網(wǎng)關(guān)-》服務(wù)A-》服務(wù)B。。。
spring-cloud跟dubbo一樣都是客戶端負載均衡，所有調(diào)用均由Ribbon來做負載均衡選擇服務(wù)器，所有調(diào)用前后會套一層hystrix做隔離、熔斷。服務(wù)間調(diào)用均用帶LoadBalanced注解的RestTemplate發(fā)出。RestTemplate-》Ribbon-》hystrix
通過上述分析我們可以看到，我們的擴展點就在Ribbon，Ribbon根據(jù)我們的規(guī)則，選擇正確的服務(wù)器即可。
我們先來一個dubbo自帶的功能：基于權(quán)重的流量控制。dubbo自帶的控制臺可以設(shè)置服務(wù)實例粒度的半權(quán)，倍權(quán)。其實就是在客戶端負載均衡時，選擇服務(wù)器帶上權(quán)重即可，spring-cloud默認是ZoneAvoidanceRule，優(yōu)先選擇相同Zone下的實例，實例間采用輪詢方式做負載均衡。我們的想把基于輪詢改為基于權(quán)重即可。接下來的問題是，每個實例的權(quán)重信息保存在哪里？從哪里取？dubbo放在zookeeper中，spring-cloud放在eureka中。我們只需從eureka拿每個實例的權(quán)重信息，然后根據(jù)權(quán)重來選擇服務(wù)器即可。具體代碼LabelAndWeightMetadataRule（先忽略里面的優(yōu)先匹配label相關(guān)代碼）。
放入核心框架
LabelAndWeightMetadataRule寫好了，那么我們?nèi)绾问褂盟怪?？?種方式。
1）寫個AutoConfig將LabelAndWeightMetadataRule聲明成@Bean，用來替換默認的ZoneAvoidanceRule。這種方式在技術(shù)驗證、開發(fā)測試階段使用短平快。但是這種方式是強制全局設(shè)置，無法個性化。
2）由于spring-cloud的Ribbon并沒有實現(xiàn)netflix Ribbon的所有配置項。netflix配置全局rule方式為：ribbon.NFLoadBalancerRuleClassName=package.YourRule，spring-cloud并不支持，spring-cloud直接到服務(wù)粒度，只支持SERVICE_ID.ribbon.NFLoadBalancerRuleClassName=package.YourRule。我們可以擴展org.springframework.cloud.netflix.ribbon.PropertiesFactory修正spring cloud ribbon未能完全支持netflix ribbon配置的問題。這樣我們可以將全局配置寫到配置中心的application-dev.properties全局配置中，然后各個微服務(wù)還可以根據(jù)自身情況做個性化定制。但是PropertiesFactory屬性均為私有，應(yīng)該是spring cloud不建議在此擴展。參見https://github.com/spring-cloud/spring-cloud-netflix/issues/1741。
3）使用spring cloud官方建議的@RibbonClient方式。該方式僅存在于spring-cloud單元測試中（在我提問后，現(xiàn)在還存在于spring-cloud issue list）。具體代碼參見DefaultRibbonConfiguration、CoreAutoConfiguration。
實際測試
依次開啟 config eureka provide（開兩個實例，通過啟動參數(shù)server.port指定不同端口區(qū)分） consumer zuul
訪問 http://localhost:8761/metadata.html 這是我手寫的一個簡單的metadata管理界面，分別設(shè)置兩個provider實例的weight值（設(shè)置完需要一段2分鐘才能生效），然后訪問 http://localhost:8080/provider/user 多刷幾次來測試zuul是否按權(quán)重發(fā)送請求，也可以訪問 http://localhost:8080/consumer/test 多刷幾次來測試consumer是否按權(quán)重來調(diào)用provide服務(wù)。
進階，基于標簽
基于權(quán)重的搞定之后，接下來才是重頭戲：基于標簽的路由。入口請求含有各種標簽，然后我們可以根據(jù)標簽幻化出各種各樣的路由規(guī)則。例如只有標注為粉絲的用戶才使用新版本（灰度、AB、金絲雀），例如標注為中國的用戶請求必須發(fā)送到中國的服務(wù)器（全球部署），例如標注為寫的請求必須發(fā)送到專門的寫服務(wù)實例（讀寫分離），等等等等，唯一限制你的就是你的想象力。
實現(xiàn)思路
根據(jù)標簽的控制，我們當然放到之前寫的Ribbon的rule中，每個實例配置的不同規(guī)則也是跟之前一樣放到注冊中心的metadata中，關(guān)鍵是標簽數(shù)據(jù)如何傳過來。權(quán)重隨機的實現(xiàn)思路里面有答案，請求都通過zuul進來，因此我們可以在zuul里面給請求打標簽，基于用戶，IP或其他看你的需求，然后將標簽信息放入ThreadLocal中，然后在Ribbon Rule中從ThreadLocal拿出來使用就可以了。然而，按照這個方式去實驗時，發(fā)現(xiàn)有問題，拿不到ThreadLocal。原因是有hystrix這個東西，回憶下hystrix的原理，為了做到故障隔離，hystrix啟用了自己的線程，不在同一個線程ThreadLocal失效。那么還有什么辦法能夠?qū)撕炐畔⒁粋鞯降啄兀胂胫坝袥]有人實現(xiàn)過類似的東西，沒錯sleuth，他的鏈路跟蹤就能夠?qū)pam傳遞下去，翻翻sleuth源碼，找找其他資料，發(fā)現(xiàn)可以使用HystrixRequestVariableDefault，這里不建議直接使用HystrixConcurrencyStrategy，會和sleuth的strategy沖突。代碼參見CoreHeaderInterceptor。現(xiàn)在可以測試zuul里面的rule，看能否拿到標簽內(nèi)容了。
這里還不是終點，解決了zuul的路由，服務(wù)A調(diào)服務(wù)B這里的路由怎么處理呢？zuul算出來的標簽如何往后面依次傳遞下去呢，我們還是抄sleuth：把標簽放入header，服務(wù)A調(diào)服務(wù)B時，將服務(wù)A header里面的標簽放到服務(wù)B的header里，依次傳遞下去。這里的關(guān)鍵點就是：內(nèi)部的微服務(wù)在接收到發(fā)來的請求時（zuul-》A，A-》B都是這種情況）我們將請求放入ThreadLocal，哦，不對，是HystrixRequestVariableDefault，還記得上面說的原因么：）。這個容易處理，寫一個spring mvc攔截器即可，代碼參見CoreHeaderInterceptor。然后發(fā)送請求時自動帶上這個里面保存的標簽信息，參見RestTemplate的攔截器CoreHttpRequestInterceptor。到此為止，技術(shù)上全部走通實現(xiàn)。
總結(jié)一下：zuul依據(jù)用戶或IP等計算標簽，并將標簽放入header里向后傳遞，后續(xù)的微服務(wù)通過攔截器，將header里的標簽放入RestTemplate請求的header里繼續(xù)向后接力傳遞。標簽的內(nèi)容通過放入類似于ThreadLocal的全局變量（HystrixRequestVariableDefault），使Ribbon Rule可以使用。
測試
參見PreFilter源碼，模擬了幾個用戶的標簽，參見LabelAndWeightMetadataRule源碼，模擬了OR AND兩種標簽處理策略。依次開啟 config eureka provide（開兩個實例，通過啟動參數(shù)server.port指定不同端口區(qū)分） consumer zuul
訪問 http://localhost:8761/metadata.html 設(shè)置第一個provide 實例 orLabel為 CN,Test 發(fā)送請求頭帶入Authorization: emt 訪問http://localhost:8080/provider/user 多刷幾次，可以看到zuul所有請求均路由給了第一個實例。訪問http://localhost:8080/consumer/test 多刷幾次，可以看到，consumer調(diào)用均路由給了第一個實例。
設(shè)置第二個provide 實例 andLabel為 EN,Male 發(fā)送請求頭帶入Authorization: em 訪問http://localhost:8080/provider/user 多刷幾次，可以看到zuul所有請求均路由給了第二個實例。訪問http://localhost:8080/consumer/test 多刷幾次，可以看到，consumer調(diào)用均路由給了第二個實例。
Authorization頭還可以設(shè)置為PreFilter里面的模擬token來做測試，至此所有內(nèi)容講解完畢，技術(shù)路線拉通，剩下的就是根據(jù)需求來完善你自己的路由策略啦。
