自己保護の背景
まず第一に、ユーレカの登録センターについて、ユーレカのすべてのノードは等しいことであり、ZKには役割の概念がないことを理解する必要があります。 N-1ノードが失われたとしても、他のノードの通常の動作には影響しません。
デフォルトでは、eurekaサーバーが特定の時間（デフォルト90秒）以内にマイクロサービスインスタンスからハートビートを受信しない場合、eurekaサーバーはインスタンスを削除します。ただし、ネットワークパーティションの障害が発生した場合、マイクロサービスはEurekaサーバーと正常に通信できず、マイクロサービス自体が正常に実行されています。このマイクロサービスは現時点では削除しないでください。したがって、自己保護メカニズムが導入されています。
自己保護メカニズム
自己保護メカニズムの公式定義：https：//github.com/netflix/eureka/wiki/understanding-eureka-to-peer-communication
自己保護モードは、異常なネットワークの変動のためのセキュリティ保護尺度です。自己保護モードを使用すると、ユーレカクラスターがより堅牢で安定して実行される可能性があります。
自己保護メカニズムの作業メカニズムは、クライアントノードの85％以上が15分以内に通常の心拍を持っていない場合、Eurekaはクライアントとレジストリにネットワーク障害があると考え、Eureka Serverが自動保護メカニズムに自動的に入力することです。現時点では、次の状況が発生します。
1. Eureka Serverは、長い間ハートビートを受け取っていないために期限切れになるはずのサービスを削除しなくなりました。 /
2。Eurekaサーバーは引き続き新しいサービスの登録およびクエリリクエストを受け入れることができますが、現在のノードがまだ利用可能であることを確認するために、他のノードに同期することはありません。 /
3.ネットワークが安定している場合、eurekaサーバーの新しい登録情報は他のノードに同期されます。
したがって、eurekaサーバーは、ネットワークの障害によりいくつかのノードが失われる状況に対処でき、それらの半分がZKのように麻痺することはありません。
自己保護スイッチ
eureka自己保護メカニズム、eureka.server.enable-self-preServationを構成することにより、/falseを有効にする/falseに忠実に、自己保護メカニズムを無効にします。デフォルトがオンになっています。この構成を生産環境で開くことをお勧めします。
開発環境構成
開発環境でサービスの障害を自動的に削除する場合は、次の構成を変更するだけです。
1.登録センターは、自己保護メカニズムを閉鎖し、無効なサービスをチェックする時間を変更します。
eureka：server：enable-self-straversion：false eviction-interval-timer-in-ms：3000
2。マイクロサービスの変更サービスのハートビートの時間を短縮します。
＃デフォルト90秒リース - エクスピレーション期間1秒：10＃デフォルト30秒リースRenewal-Interval-in-conds：3
上記の構成は、生産環境でデフォルトの時間構成を使用するために推奨されます。私はそれがすべての人の学習に役立つことを願っています、そして、私は誰もがwulin.comをもっとサポートすることを願っています。