最近手頭的一個(gè)項(xiàng)目由于業(yè)務(wù)增長，原本一個(gè)應(yīng)用的大雜燴系統(tǒng)，無論功能迭代開發(fā)、發(fā)布還是回歸測試上，項(xiàng)目上線質(zhì)量越發(fā)難以控制。 于是想逐漸往Spring Cloud微服務(wù)架構(gòu)上轉(zhuǎn)型。
前后在Spring cloud技術(shù)棧上斷斷續(xù)續(xù)研究了1個(gè)多月，最終選擇了Netflix的一堆腳手架組件。選擇Netflix主要還是發(fā)現(xiàn)它夠簡單、容易上手。大概花了一周左右的時(shí)間研究了Eureka, Zuul的實(shí)現(xiàn)以及和Spring Cloud融合點(diǎn)（AutoConfiguration），但是，理論歸理論，實(shí)際實(shí)踐過程中還是踩了不少坑，于是就想到寫一些文章記錄下來，以便于自己以后翻閱和供大家參考。
由于是舊系統(tǒng)的架構(gòu)改造，服務(wù)拆分，不可避免的會涉及到服務(wù)從老應(yīng)用中遷移到新建應(yīng)用中，當(dāng)然你在遷移過程中不能讓服務(wù)停止或不兼容，尤其是APP端的應(yīng)用，用戶已經(jīng)在用的版本你總不能讓他不能用吧？這是個(gè)硬杠杠！這種場景zuul也想到了，它的「絞殺模式」就是為這種場景準(zhǔn)備的。
所謂「絞殺模式」我的理解是：將老系統(tǒng)中的服務(wù)，根據(jù)一定的基于uri的路由規(guī)則，逐漸分流到新系統(tǒng)中，從而將老服務(wù)逐漸替換掉。
ZUUL中有兩種方式可以構(gòu)建route（也就是轉(zhuǎn)發(fā)規(guī)則）
1. 手動配置，就是在properties文件中靜態(tài)配置轉(zhuǎn)發(fā)規(guī)則，詳細(xì)字段可以參考類 ZuulProperties
2. 依賴Eureka注冊中心中的ServiceId動態(tài)生成轉(zhuǎn)發(fā)規(guī)則
第二個(gè)方式中就有一個(gè)坑，個(gè)人覺得也是Zuul設(shè)計(jì)中的一個(gè)缺陷，通常老系統(tǒng)中，我們服務(wù)的訪問路徑是這么設(shè)計(jì)的：
https://myapp.goodcompany.com/appcontext/user/query_user
老系統(tǒng)的所有服務(wù)都以appcontext上下文起頭，后面根據(jù)不同的path來區(qū)分各個(gè)業(yè)務(wù)模塊，在新系統(tǒng)中我們會把會員相關(guān)（user）相關(guān)的服務(wù)拆分到新系統(tǒng)中，通常新會員系統(tǒng)的服務(wù)是這么訪問的：
https://user.googcompany.com/user/query_user
所以，從route角度來說，你需要把路徑 /appcontext/user/query_user 映射到/user/query_user中。但是如果你采用上面第二種方式來自動構(gòu)建route的話，這個(gè)路徑會映射到/query_user中，路徑中缺少了/user。原因是路徑遭遇了strip！！ 而且這種通過DiscoveryClient構(gòu)建的Route, 你沒法通過設(shè)置zuul相關(guān)配置把這個(gè)開關(guān)關(guān)掉！咱們看下代碼！
圖一中，route.isStripPrefix()被設(shè)置為true，直接把/user/**給干掉了??！
所以，盡量使用手動配置的route，同時(shí)可以控制每個(gè)route的stripPrefix屬性
還有一點(diǎn)是，只要是注冊到Eureka中的服務(wù)，通過DiscoveryClient都可以注冊到ZUUL的轉(zhuǎn)發(fā)路徑中，盡管有些服務(wù)是你不想要轉(zhuǎn)發(fā)的。雖然，ZuulProperties中有ignoredService屬性可以配置用來過濾掉一些serviceId，但是由于Eureka中可以動態(tài)加入服務(wù)實(shí)例，你也不可能每次有新服務(wù)加入的時(shí)候你修改代碼再發(fā)布你的ZUUL吧！
修正一下，剛剛在stackoverflow上查到，通過如下配置可以屏蔽掉來自DiscoveryClient的route,
zuul.ignored-services=*
