springcloud 微服務的 Zuul 配置

一、路由配置 

a、單例serverId映射

zuul:
  routes:
    client-a:
      path: /client/**
      serviceId: client-a

意思是，以/client/**爲端點路徑的服務都映射到client-a，這種配置還能夠簡寫成下面的格式，兩者效果徹底一致：

官網 www.1b23.com
zuul:
  routes:
    client-a: /client/**

還有一種更粗暴的方式，就是映射的serverId都不用寫，以下：

zuul:
  routes:
    client-a:

這種配置，zuul會爲client-a添加一個默認的映射規則，即：/client/**，至關於上面的第一種配置方式。

b、單例URL映射

這種配置意思就是，網關路由到具體的服務地址，即：將serverId替換成url，以下：

zuul:
  routes:
    client-a:
      path: /client/**
      url: http://localhost:7070 #client-a的地址

c、多實例路由

默認狀況下zuul會使用eureka中集成的負載均衡功能，若是要使用ribbon的負載均衡，就須要指定serverId，這個操做必定要禁用掉ribbon使用eureka，具體操做以下：

zuul:
  routes:
    ribbon-route:
      path: /ribbon/**
      serviceId: ribbon-routeribbon:
  eureka:
    enabled: false  #禁止Ribbon使用Eurekaribbon-route:  ribbon:
    NIWSServerListClassName: com.netflix.loadbalancer.ConfigurationBasedServerList #定義獲取服務列表方法
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule     #Ribbon LB Strategy 使用隨機負載策略
    listOfServers: localhost:7070,localhost:7071     #client services for Ribbon LB 指定服務地址

d、forword本地跳轉

假如在網關服務中，須要作一些邏輯處理，能夠在配置url時，添加forword選項：

zuul:
  routes:
    client-a:
      path: /client/**
      url: forward:/client #跳轉到網關服務中@GetMapping("/client")端點

e、相同路徑加載

zuul:
  routes:    client-b:
      path: /client/**
      serviceId: client-b    client-a:
      path: /client/**
      serviceId: client-a

從上面的配置文件，能夠看出，配置了兩個工程的路由，即：client-a工程，client-b工程，可是兩者的path路徑是一致的，這種狀況下，在加載訪問的時候，後者會覆蓋前者。

f、路由通配符

規則	說明	示例
/**	匹配任意數量的路徑與字符	/client/add, /client/update, client/a, client/add/a, client/update/a/b
/*	匹配任意數的字符	/client/add, /client/update, client/a
/?	匹配單個字符	/client/a

二、功能配置

a、屏蔽服務、屏蔽路徑

zuul:  ignored-services: client-b    #忽略的服務，防止服務侵入  ignored-patterns: /**/div/**  #忽略的接口，屏蔽接口
  routes:
    client-a: /client/**

加上 ignored-services 與 ignored-patterns 以後，zuul在拉取服務列表的時候，建立映射規則的時候，就會忽略掉client-b服務和/**/div/**接口。

b、過濾掉敏感請求頭

正常咱們使用HTTP請求服務，在header添加值進行傳遞，是很正常的一件事，協議的一些基本認證也都在header，好比cookie，或者把登陸認證經過後的用戶信息base64編碼後，放在authorization裏面，在系統內這種傳遞是沒有問題的，可是若是系統與外部進行交互，這種可能就會出現異常，畢竟也要防患於未然，這時能夠在zuul裏邊指定敏感頭信息，切斷它與下游的交互，以下：

zuul: routes: client-a: path: /client/** sensitiveHeaders: Cookie,Set-Cookie,Authorization serviceId: client-a

c、重定向

在實際企業級項目中，不少操做都是須要用戶登陸後，才能夠進行操做的，爲了防止用戶登陸成功後，在重定向的時候，將對應的服務地址暴露給用戶，能夠設置一個頭，以下：

zuul:
  add-host-header: true         #重定向header問題
  routes:
    client-a: /client/**

d、重試機制

在生產環境中，可能因爲各類緣由，致使偶然請求失敗，可使用zuul結合ribbon作重試操做，以下：

zuul: retryable: true #開啓重試 ribbon: MaxAutoRetries: 1 #同一個服務重試的次數(除去首次) MaxAutoRetriesNextServer: 1 #切換相同服務數量

可是，這個功能要慎用，由於有些接口須要保證冪等性。