Zuul構成springcloud

概要:zulの下部はservletに基づいており、一連のfilterチェーンから構成されています.
1、ルート構成
a、一例serverIdマッピング

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

つまり、/client/**をエンドポイントパスとするサービスはclient-aにマッピングされます.この構成は、次のフォーマットに簡単に書くこともできます.両者の効果は完全に一致しています.

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

もう1つの乱暴な方法は、マッピングされたserverIdを書く必要がありません.以下のようにします.

zuul:
  routes:
    client-a:

この構成では、zulはclient-aにデフォルトのマッピングルールを追加します.すなわち、上記の最初の構成に相当する/client/**です.
b、一例URLマッピング
この構成は、ゲートウェイが特定のサービスアドレスにルーティングされることを意味し、すなわち、serverIdをurlに置き換え、以下のようにする.

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

c、マルチインスタンスルーティング
デフォルトではzulはeurekaに統合されたロード・バランシング機能を使用します.ribbonのロード・バランシングを使用する場合はserverIdを指定する必要があります.この操作では、ribbonのeurekaの使用を無効にする必要があります.具体的な操作は次のとおりです.
zul:routes:ribbon-route:path:/ribbon/**serviceId:ribbon-routeribbon:eureka:enabled:false Ribbonの使用禁止Eurekaribbon-route:ribbon:NIWSServerListClassName:com.netflix.loadbalancer.ConfigurationBasedServer List#定義サービスリストの取得方法NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule#Ribbon LB StrategyランダムロードポリシーlistOfServer: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エンジニアリングの2つのエンジニアリングのルーティングが構成されているが,両者のpathパスは一致しており,この場合,アクセスをロードする際に後者は前者を上書きする.
f、ルーティングワイルドカード
ルール＃ルール＃
説明
例
/**
任意の数のパスと文字を一致させる
/client/add,/client/update, client/a, client/add/a, client/update/a/b
/*
任意の数に一致する文字
/client/add,/client/update, client/a
/?
1文字の一致
/client/a
2、機能構成
a、シールドサービス、シールドパス

zuul:  ignored-services: client-b    #     ，        ignored-patterns: /**/div/**  #     ，    
  routes:
    client-a: /client/**

ignored-servicesとignored-patternsを加えると、zulはサービスリストを引くときにマッピングルールを作成するときにclient-bサービスと/**/div/**インタフェースを無視します.
b、敏感要求ヘッドをフィルタする
通常、HTTPリクエストサービスを使用して、ヘッダに値を追加して転送するのは正常です.プロトコルの基本認証もヘッダ、例えばクッキー、またはログイン認証を通過したユーザー情報base 64を符号化した後、authorizationの中に置いて、システム内でこの転送は問題ありませんが、システムが外部とインタラクティブであれば、このような異常が発生する可能性があります.結局、未然に防ぐ必要があります.この場合、zulの中で敏感なヘッド情報を指定し、下流とのインタラクションを遮断することができます.以下のようにします.
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、再試行メカニズム
本番環境では、さまざまな理由で偶発的なリクエストに失敗する可能性があります.zulを使用してribbonと組み合わせて再試行操作を行うことができます.以下のようにします.
zull:retryable:true#再試行ribbon:MaxAutoRetries:1#同一サービス再試行回数(初回を除く)MaxAutoRetriesNextServer:1#同一サービス数を切り替える
しかし、この機能は慎重に使用しなければならない.一部のインタフェースではべき乗等性を保証する必要があるからだ.