源碼：Service routing with Spring Cloud and Zuul
前言
同樣像之前一樣吧postgres開起來備用。配置服務記得改成本地的環境，尤其是組織服務，要配一下：
組織表也要創建。sql在組織服務裏找。
配置文件用本地查找模式：
一、在Zuul中配置路由
小筆記：一般用Zuul和Eureka集成時，用@EnableZuulProxy,還有個註解叫@EnableZuulServer，使用它將創建一個Zuul服務器，它不會加載任何Zuul反向代理過濾器，也不會使用Eureka進行服務發現，與其他服務發現引擎（比如Consul）集成時才用它。
二、在Zuul中配置路由
三種機制：
- 使用服務發現自動映射路由
- 使用服務發現手動映射路由
- 使用靜態URL手動映射路由
1.通過服務發現自動映射路由
這個不需要配置：URL/服務ID/具體路徑即可。
驗證一下，首先開啓Eureka，，然後配置服務，然後其他服務，然後開啓Zuul服務。
2.使用服務發現手動映射路由
小筆記：在使用自動路由映射時，Zuul只基於Eureka服務ID來公開服務，如果服務的實例沒有在運行，Zuul將不會公開該服務的路由。然而，如果手動配置的話，會產生路由，但是實際使用時路由過去可能會收到一個500錯誤。
可以用ignored-services從自動映射中排除想排除的服務。設爲*就是排除所有。
還可以用prefix來設置URL前綴。忽略的就不演示了。前綴的演示一下。
3.使用靜態URL手動映射路由
可以直接這樣配置死，繞過Eureka。
也可以在Ribbon中禁用Eureka，配置路由列表，就是一對多。
小筆記：在Ribbon中晉中Eureka意味着Eureka服務器將承受更多的負載。
4.動態重新加載路由配置
訪問/refresh端點即可。
5.服務超時
Hystrix默認一秒種是超時時間，可以通過配置配置各個服務的超時時間來進行超時設置，注意超過5s的配置，
三、Zuul的真正威力：過濾器
通過上面的學習可以知道，zuul的基本應用和Nginx差不多，概念也很容易理解，但是Zuul的真正的威力在於其過濾器。
其實理解過濾器，它就像理解Serverlet裏的Filter，修飾者模式，不影響原始編碼人員。
分爲前置，後置和路由，路由過濾器的使用：比如不同版本的服務。
先來一個前置過濾器：
注意對request進行操作的時候，不是用的http默認的request，而是zuul包裝的，添加的方法也是zuul包裝後的一個函數。
接下來要研究怎麼去在服務調用的過程中全程跟蹤這個id。
我們要定義三個類：
1.UserContextFilter：攔截傳入的http請求
它是一個Http serverlet過濾器。
2.UserContext：使服務易於訪問HTTP首部。
這個很簡單，定義一個pojo，然後把這個pojo存在ThreadLocal中。
3.自定義RestTemplate和UserContextInteceptor：確保關聯ID被傳播
小筆記：現在關聯ID就可以在全局傳播了，這樣日誌就可以有一個關聯主鍵了。在這裏先不討論日誌服務。
四、構建接收關聯ID的後置過濾器
驗證一下：
五、構建動態路由過濾器
SpecialRoutesFilter代碼：
驗證：
驗證之前，還得新建一個表：
另外檢查一下特殊路由服務的配置：
發現它並沒有從配置中心拉到配置文件，因爲我用的是native本地查找的，所以再給它添加個配置文件就可以了。
然後依次啓動Eureka->config->證書，組織，組織新，特殊路由->zuul路由服務。一共七個微服務。（端口設置不一樣，Eureka是自動發現的）
等30s,服務註冊完畢：
AB測試就可以用了。
