0602-Zuul構建API Gateway-Zuul Http Client、cookie、header

1、Zuul Http Client

　　zuul使用的默認HTTP客戶端如今由Apache HTTP Client支持，而不是已棄用的Ribbon RestClient。要使用RestClient或使用okhttp3.OkHttpClient，請分別設置ribbon.restclient.enabled = true或ribbon.okhttp.enabled = true。若是您想定製Apache HTTP客戶端或OK HTTP客戶端提供ClosableHttpClient或OkHttpClient類型的Bean。

2、Cookies和敏感header頭

2.一、基礎使用

　　在同一個系統中的服務之間共享header是能夠的，但你可能不但願敏感的header向下遊泄漏到外部服務器中。您能夠指定一個忽略的header列表做爲路由配置的一部分。Cookie扮演着特殊的角色，由於他們在瀏覽器中具備明肯定義的語義，而且始終將其視爲敏感。若是代理的用戶是瀏覽器，那麼下游服務的cookie也會給用戶帶來問題，由於它們都混亂了（全部下游服務看起來都是來自同一個地方）。

　　若是您對服務的設計很是當心，例如，若是隻有一個下游服務設置了cookie，那麼您可能會讓它們從後端一路流向調用者。另外，若是您的代理設置了Cookie而且全部後端服務都屬於同一個系統，那麼簡單地共享它們（例如使用Spring Session將它們連接到某個共享狀態）多是很天然的。除此以外，任何由下游服務設置的cookie均可能對調用者不是頗有用，所以建議您將（至少）「Set-Cookie」和「Cookie」製做爲不屬於您的域的路由的敏感header。即便對於屬於您的域名的路由，也要儘可能仔細考慮它們在容許Cookie與代理之間流動以前的含義。

　　敏感header能夠配置爲每一個路由以逗號分隔的列表，例如，

 zuul:
  routes:
    users:
      path: /myusers/**
      sensitiveHeaders: Cookie,Set-Cookie,Authorization
      url: https://downstream

其中sensitiveHeaders：未傳遞到下游請求的敏感header列表。默認爲一般包含用戶憑據的一組「安全」的報頭。若是下游服務是與代理相同的系統的一部分，那麼它們就能夠從列表中刪除這些文件，所以它們正在共享認證數據。若是在本身的域以外使用物理URL，那麼一般泄漏用戶憑據將是一個壞主意。

注意：這是sensitiveHeaders的默認值，因此你不須要設置它，除非你想讓它不一樣。注：這是Spring Cloud Netflix 1.1中的新功能（在1.0中，用戶沒法控制header和全部cookie在兩個方向上流動）。

2.二、空header

sensitiveHeaders是一個黑名單，默認不是空的，因此爲了讓Zuul發送全部的頭文件（除了「被忽略」的頭文件），你必須明確地將它設置爲空列表。

 zuul:
  routes:
    users:
      path: /myusers/**
      sensitiveHeaders:
      url: https://downstream

敏感header也能夠經過設置zuul.sensitiveHeaders進行全局設置。若是sensitiveHeaders在路由上設置，這將覆蓋全局sensitiveHeaders設置。

2.三、忽略header

　　除了每一個路由敏感報頭以外，您還能夠爲zuul.ignoredHeaders設置一個全局值，以便在與下游服務交互期間應丟棄的值（包括請求和響應）。默認狀況下，若是Spring Security不在類路徑中，它們是空的，不然它們被初始化爲Spring Security指定的一組衆所周知的「安全」頭文件（例如涉及緩存）。在這種狀況下，假設下游服務可能也會添加這些header，而且咱們須要來自代理的值。爲了避免丟棄這些衆所周知的安全性頭文件，以防Spring Security在類路徑中，您能夠將zuul.ignoreSecurityHeaders設置爲false。若是您在Spring Security中禁用了HTTP安全響應頭而且須要下游服務提供的值，這會頗有用

3、Manager Endpoint

若是您在Spring Boot Actuator中使用@EnableZuulProxy，您將啓用（默認狀況下）兩個附加端點：

• Routes
• Filters

注意：關閉驗證或者開啓：management.security.enabled=false

3.一、Routes Endpoint

　　GET / routes路由端點將返回映射路由列表：

{
  /stores/**: "http://localhost:8081"
}

能夠經過將？format = details查詢字符串添加到/ routes來請求其餘路由詳細信息。這將產生如下輸出：GET /routes?format=details. 

{
  "/stores/**": {
    "id": "stores",
    "fullPath": "/stores/**",
    "location": "http://localhost:8081",
    "path": "/**",
    "prefix": "/stores",
    "retryable": false,
    "customSensitiveHeaders": false,
    "prefixStripped": true
  }
}

POST將強制刷新現有routes（例如，若是服務目錄中有更改）。您能夠經過將endpoints.routes.enabled設置爲false來禁用此端點。

注意：路由應該自動響應服務目錄中的更改，但POST /路由是強制更改當即發生的一種方式。

3.二、Filters Endpoint

GET / filters中的過濾器端點將按類型返回Zuul過濾器的映射。對於地圖中的每種過濾器類型，您能夠找到該類型的全部過濾器的列表及其詳細信息。

4、絞殺者模式和本地轉發

絞殺者模式：參看博客https://martinfowler.com/bliki/StranglerApplication.html

　　遷移現有應用程序或API時常見的模式是「扼殺」舊的端點，並慢慢地用不一樣的實現替換它們。Zuul代理是一個有用的工具，由於您可使用它來處理來自舊端點客戶端的全部流量，但會將某些請求重定向到新端點。

application.yml. 

zuul:
  routes:
    first:
      path: /first/**
      url: http://first.example.com
    second:
      path: /second/**
      url: forward:/second
    third:
      path: /third/**
      url: forward:/3rd
    legacy:
      path: /**
      url: http://legacy.example.com

　　在這個例子中，咱們扼殺了映射到與其餘模式不匹配的全部請求的「遺留」應用程序。/ first / **中的路徑已被提取到具備外部URL的新服務中。而且/ second / **路徑被轉發，以便它們能夠在本地處理，例如，與一個正常的Spring @RequestMapping。/ third / **中的路徑也被轉發，但具備不一樣的前綴（即/ third / foo被轉發到/ 3rd / foo）。

　　被忽略的模式不會被徹底忽略，它們只是不被代理處理（因此它們也被有效地本地轉發）。