--p219
Spring Cloud Zuul提供了一套過濾器機制    
開發者可以通過使用Zuul來建立各種校驗過濾器機制.....

簡述通過Zuul實現的API閘道器服務的構建過程?
 --p220
1,建立一個基礎的Spring Boot工程,命名為api-gateway,並在pom.xml裡引入spring-cloud-starter-zuul依賴

2,建立應用主類,使用@EnableZuulProxy註解開啟Zuul的API閘道器服務功能.

3,在application.properties中配置Zuul應用的基礎資訊,如應用名,服務埠號等

 請求路由(Spring Cloud Zuul的一個核心功能)
  --p222
  面向服務的路由
    為了與Eureka整合,我們需要在api-gateway的pom.xml裡引入spring-cloud-starter-eureka依賴
    在api-gateway的application.properties配置檔案中指定Eureka註冊中心的位置,並配置服務路由.
    zuul.routes.api-a.path=/api-a/**
    zuul.routes.api-a.serviceId=hello-service

    zuul.routes.api-b.path=/api-b/**
    zuul.routes.api-b.serviceId=feign-consumer
    
    eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

    好處:通過面向服務的路由配置方式,我們不需要再為各個路由維護微服務應用的具體例項的位置,而是通過簡單的path與serviceId的對映組合,
    使得維護工作變得非常簡單. 
 
 請求過濾(Spring Cloud Zuul的另一個核心功能)
  --p224
  Zuul允許開發者在API閘道器上通過定義過濾器來實現對請求的攔截與過濾,實現方法:extends ZuulFilter(抽象類) 並實現它定義的4個抽象方法就可以
  完成對請求的攔截和過濾了.
  
  --p225
  filterType:過濾器型別,它決定過濾器在請求的那個生命週期執行.如:pre代表在請求被路由之前執行
  filterOrdr:過濾器執行順序
  shouldFilter:判斷該過濾器是否需要被執行.true   過濾器的有效範圍
  run:過濾器的具體邏輯
    
  在實現了自定義過濾器之後,它並不會直接生效,還需要為其建立具體的Bean才能啟動該過濾器,如:在應用主類中增加如下內容:
  @Bean
  public AccessFilter accessFilter(){
      return new AccessFilter();
  } 

 簡述API閘道器服務對微服務的重要性?(Spring Cloud Zuul的優點)
 1,它作為系統的統一入口,......
 2,它可以與服務治理框架結合,實現自動化的服務例項維護以及負載均衡的路由轉發.
 3,它可以實現介面許可權校驗與微服務業務邏輯的解耦
 4,通過服務閘道器中的過濾器,在各個生命週期中去校驗請求的內容,將原本在對外服務層做的校驗前移,......

路由詳解
 --p229
 大部分的路由配置規則幾乎都會採用服務名作為外部請求的字首,如下:
 zuul.routes.user-service.path=/user-service/**
 zuul.routes.user-service.serviceId=user-service
 對於這樣具有規則性的配置內容,可以自動化完成
  

 zuul.ignored-services=*的時候,Zuul將會對所有的服務都不自動建立路由規則.

 預設情況下,Zuul自動為服務建立的路由表示式會採用服務名(serviceId)作為字首.                   10:52 2018-12-28

 自定義路由對映規則
 路由匹配:/v1/userservice/**   服務版本標識  服務名
 實現步驟如下: ......
 PatternServiceRouteMapper物件可以讓開發者通過正則表示式來自定義服務與路由對映的生成關係.
   
 路徑匹配
 由於properties的配置內容無法保證有序,所以當出現這種情況的時候,為了保證路由的優先順序,我們需要使用YAML檔案來配置,如:
 zuul: 
  routes: 
   user-service-ext:
    path:/user-service/ext/**
    serviceId:user-service-ext
   user-service:
    path:/user-service/**
    serviceId:user-service
 
 忽略表示式
 如果不希望/hello介面被路由,設定如下:
 zuul.ignored-patterns=/**/hello/**
 
 路由字首
 務必避免讓路由表示式的起始字串與zuul.prefix引數相同
  
 本地跳轉
 
 --p235
 Cookie與頭資訊
 我們在開發Web專案時常用的Cookie在Spring Cloud Zuul閘道器中預設是不會傳遞的,這就會引發一個常見問題:如果我們使用了Spring Security,Shiro等
 安全框架構建的Web應用通過Spring Cloud Zuul構建的閘道器來進行路由時,由於Cookie資訊無法傳遞,我們的Web應用將無法實現登入和鑑權.
 解決方法如下:
 #方法1:對指定路由開啟自定義敏感頭
 zuul.routes.<router>.customSensitiveHeaders=true
 #方法2:將指定路由的敏感頭設定為空
 zuul.routes.<router>.sensitiveHeaders=

 重定向問題
 登入成功後,我們跳轉到的頁面URL是具體Web應用例項的地址,而不是通過閘道器的路由地址.這個問題很嚴重,因為使用API閘道器的一個重要原因就是要將閘道器
 作為統一入口,從而不暴露所有內部服務細節.
 原因:
 請求頭資訊中的Host指向了具體的服務例項IP地址和埠   
 沒將最初的Host資訊設定正確
 解決方法:
 zuul.addHostHeader=true
 由於Spring Cloud版本原因,目前Brixton版本採用了Spring-cloud-netflix-core-1.1.x,只有Camden版本採用Spring-cloud-netflix-core-1.2.x.
 所以重定向的問題如果要在Zuul中解決,最簡單的方法使用Camden版本

 Hystrix和Ribbon支援
 spring-cloud-starter-zuul依賴自身就包含了對spring-cloud-starter-hystrix和spring-cloud-starter-ribbon模組的依賴,所以Zuul天生就擁有執行緒
 隔離和斷路器的自我保護功能,以及對服務呼叫的客戶端負載均衡功能.
 注意:當使用path與URL的對映關係來配置路由規則時,對於路由轉發的請求不會採用HystrixCommand來包裝,所以這類路由請求沒有執行緒隔離和斷路器的保
 護,且也不會有負載均衡的能力.因此,我們在使用Zuul時儘量使用path和serviceId的組合來進行配置

--p238
過濾器詳解
 過濾器
 路由功能負責將外部請求轉發到具體的微服務例項上,是實現外部訪問統一入口的基礎
 過濾器功能負責對請求的處理過程進行干預,是實現請求校驗,服務聚合等功能的基礎
 filterType:過濾器型別,它決定過濾器在請求的那個生命週期執行.
            如:pre代表在請求被路由之前執行
               routing代表在路由請求時被呼叫
               post代表在routing和error過濾器之後被呼叫
               error代表處理請求時發生錯誤時被呼叫
               
 filterOrdr:通過int值來定義過濾器執行順序,數值越小優先順序越高
 shouldFilter:判斷該過濾器是否需要被執行.true   過濾器的有效範圍
 run:過濾器的具體邏輯   自定義的過濾邏輯,來確定是否攔截當前的請求   或在請求路由返回結果之後,對處理結果做一些加工等

 
 請求生命週期
 第一個階段pre
 第二個階段routing
 第三個階段post 通過post過濾器將最終結果返回給請求客戶端
 特殊階段error
 
 核心過濾器
 ......

 --p244
 異常處理