ユーレカとは？
EurekaはDidi Chuxingのようなもので、サービスプロバイダーに関する情報の管理と記録を担当しています。
サービスの呼び出し元は自分でサービスを見つける必要はありませんが、ユーレカに自分のニーズを伝え、ユーレカはあなたのニーズを満たすサービスを教えてくれます。
同時に、サービスプロバイダーとEurekaは「ハートビート」メカニズムを通じて監視され、サービスプロバイダーに問題が発生すると、Eurekaがサービスリストから自動的に削除します。
これにより、サービスの自動登録、検出、およびステータス監視が可能になります。
ユーレカのインフラ
ユーレカアーキテクチャの3つの中心的な役割：
サービス登録センター：
Eurekaのサーバーアプリケーションは、サービスの登録および検出機能を提供します。
サービスプロバイダー：
このサービスを使用する必要があります。これは、SpringBootアプリケーションにすることも、Restスタイルのサービスを提供する限り、他のテクノロジーで実装することもできます。
サービス利用者：
コンシューマアプリケーションは、各サービスパーティの情報を知り、サービスパーティの呼び出し先を知るために、登録センターからサービスリストを取得します。
高可用性Eurekaサーバー
EurekaServerはサービスのレジストリです。EurekaServerをクラスターにして、可用性の高いEurekaセンターを形成できます。
複数のEurekaServerが相互にサービスを登録します。サービスプロバイダーがEurekaServerクラスター内のノードに登録されると、ノードはサービス情報をクラスター内の各ノードに同期して、データの同期を実現します。
したがって、クライアントがEurekaServerクラスター内のノードにアクセスしても、完全なサービスリスト情報を取得できます。
いわゆる高可用性登録センターは実際にはEurekaServer自体をサービスとして登録しているため、複数のEurekaServerがお互いを検出してクラスターを形成できます。
サービスプロバイダー
サービスプロバイダーは、EurekaServerにサービスを登録し、サービスの更新やその他のタスクを完了する必要があります。
サービスプロバイダーが起動すると、eureka.client.register-with-eureka = trueパラメーターが正しいかどうかが確認されます。実際、デフォルトはtrueです。
値がtrueの場合、EurekaServerへのRestリクエストが開始され、独自のメタデータ情報が送信されます。EurekaServerは、この情報を2層のマップ構造に格納します。
最初のレイヤーマップのキーは、サービスのIDです。通常、構成では、spring.application.nameプロパティです。
2番目のレイヤーマップのキーはサービスインスタンスIDであり、通常はホスト+ serviceld +ポートです。例：localhost：service-provider：8081
値はサービスのインスタンスオブジェクトです。つまり、サービスは複数の異なるインスタンスを同時に開始してクラスターを形成できます。
登録サービスが完了すると、サービスプロバイダーはハートビートを維持し（Rest要求はEurekaServerに定期的に送信されます）、サービスがまだ存在することをEurekaServerに通知します。この動作はサービスの更新と呼ばれます。
サービスの更新の動作を変更できる2つの重要なパラメーターがあります。
ユーレカ： インスタンス： lease -expiration-duration-in-seconds：90＃サービス障害の間隔、デフォルトは30秒 リース -renewal-interval-in-seconds：30＃サービスの更新時間、デフォルトは90秒
つまり、デフォルトでは、サービスは30秒ごとにレジストリにRestリクエストを送信して、それがまだ生きていることを証明します。
90秒以上送信されない場合、EurekaServerはサービスがダウンしていると見なし、サービスリストから削除されます。
本番環境ではこれらの2つの値を変更しないでください。デフォルトのみです。
開発環境では、この値は長すぎます。サービスをオフにすることがよくありますが、Eurekaはまだサービスがまだ有効であると考えているため、適切に調整できます。
消費者へのサービス
サービスコンシューマーが開始すると、eureka.client.fetch-registry = trueパラメーターの値を検出します。trueの場合、読み取り専用バックアップ用のEurekaServerサービスのリストをプルし、それをローカルにキャッシュします。
さらに、データは30秒ごとに取得および更新されます。これは、次のパラメーターで変更できます。
ユーレカ：
クライアント：
レジストリ -fetch-interval-seconds：5
本番環境では、この値を変更する必要はありません。
開発環境では、サービスのステータスをすばやく取得するために、サービスを小さく設定できます。
失敗の拒否
サービスが正常にシャットダウンすると、サービスのRest要求がオフラインでEurekaServerに送信され、サービス登録センターに「オフラインになります」と通知されます。
リクエストを受信すると、サービスセンターはサービスをオフラインステータスに設定します。
場合によっては、サービスプロバイダーが正常にオフラインにならず、メモリオーバーフローまたはネットワーク障害が原因でサービスが正しく機能しないことがあります。
EurekaServerは、このようなサービスをサービスリストから除外する必要があります。
したがって、EurekaServerはタイマーサービスを開始して、失敗したすべてのサービスを60秒ごとに削除します。
eureka.server.eviction-interval-timer-in-msパラメーターで変更できます。単位はミリ秒です。
本番環境は変更しないでください。
ただし、この速度では開発に大きな不便が生じ、サービスの再起動後、Eurekaは60秒で反応するため、開発段階で適切に調整できます。
自己防衛
サービスをシャットダウンすると、Eurekaパネルに警告が表示されます。
これがEurekaの自己保護メカニズムのトリガーです。サービスが時間どおりにハートビートを更新できなかった場合、Eurekaは過去15分間にハートビートエラーが発生したサービスインスタンスの割合が85％を超えているかどうかをカウントします。
本番環境では、ネットワークの遅延やその他の理由により、失敗したハートビートインスタンスの割合が標準を超える可能性がありますが、現時点ではサービスを除外することは適切ではありません。
サービスがダウンしていない可能性があるため、Eurekaは現在のインスタンスの登録情報を保護し、削除しません。
本番環境では非常に効果的であり、ほとんどのサービスが引き続き利用可能であることを保証しますが、開発に問題が発生します。
したがって、開発段階では自己保護モードがオフになります。
ユーレカ： サーバ： enable -self-preservation：false ＃自己保護モードを無効にします（デフォルトはオンです） eviction -interval-timer-in-ms：1000＃無効なサービスをスキャンする間隔時間（デフォルトは60 * 1000ms）