Spring Coud Zuulルーティング規則の動的更新解析

この文章は主にSpring Cloud Zuulルート規則の動的更新解析を紹介しています。ここでは例示コードによって紹介された非常に詳細で、皆さんの学習や仕事に対して一定の参考学習価値を持っています。必要な友達は下記を参照してください。
背景
Spring Cloud Zuulは、マイクロサービスのゲートウェイとして、zul経由で内部にルーティングする各serviceを要求しています。サービスの追加・修正・削除のためのルートルールの必要があります。zulのルーティングルールの動的変更機能が提供されます。
zulゲートウェイを再起動しなくても、リアルタイムで更新できます。以下のようないくつかの方法があります。
一、refresh+config-server事件に基づいて動的に更新する。
（1）spring bootはspring actuatが提供するrefresh機能を統合した後、congfig-serverのgit配置倉庫にzulのルートルールを追加し、
（2）post方式でrefreshエンドポイントを更新するhttp://127.0.0.1:8080/refresh（本機を例として）
(3)zulを再度訪問すると、ルーティングルールに新たなルールがあることが分かりました。
トリガーrefresh操作から->ZuulProptiesのroute更新の流れは以下の通りです。

Zuulゲートウェイのルーティングルールは、コアタイプのDiscoveryClientRoute LocatorとSimpleRoute Locatorをロードし、詳細はSpring Cloud Zuulソースを参照することができます。ここでは分析をしません。
ルート規則のロード機構は主にSimpleRoute LocatorによってZuul Propties中のルーティングルールをロードする。上の図は、refreshからプロパティにZuulProptiesを注入する全体の流れを示しています。
短所:
refresh後にまずロードされる配置センターの全てのzullの最新K/Vデータは、ロードされた属性K/V注入規則に従ってZuulPropties(Bean)に入りますが、Zuul Proptiesはrefsh前からBean容器にあります。
したがって、Zuulルーティング規則を追加または修正し、refresh後にZuul Proptiesの属性値を追加または上書きし、Zuul Proptiesのルーティングルールを削除することは依然として存在しますので、削除は無効です。
利点:
簡単に使用して、構成倉庫に基づいてルーティング規則をバージョン管理して、外部にrefshエンドポイントを露出するだけでいいです。
二、RefreshScopeによるダイナミックリフレッシュ
ZuulPropetiesを拡張してRefshScopeeを使って注釈を行い、配置センターのルート規則を修正した後、refsh操作のルート規則をトリガすると変更が発生します。
コード:

@Bean
 @ConfigurationProperties("zuul")
 @RefreshScope
 @Primary
 public ZuulProperties zuulProperties() {
  return new ZuulProperties();
 }

短所:
独自の拡張機能が必要です。RefreshScopeteの注釈を入れます。
利点:
RefreshScropeはcglibを使用してZuul Proptiesを生成するエージェントであり、1つのBeanオブジェクトの実装形態とは異なるので、ルーティングルールの削除に対しても有効である。
三、dbメモリに基づく動的リフレッシュ
Zuulゲートウェイのルーティングルールは、コアタイプのDiscoveryClientRoute LocatorとSimpleRoute Locatorをロードしても良いです。
SimpleRoute Locatorを拡張して、その中のlocateRoutes()を再ロードする方法で、カスタムでdbからルーティング規則をロードすることを実現して、トリガ条件は依然としてrefshです。
短所:
拡張が複雑で、定着開発が必要で、ルーティングルールのロードロジックを書き換えます。
利点:
ルートルールの変更を柔軟に制御し、業務シーンに合わせてより多くのカスタマイズ機能を追加することができます。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。