ディレクトリ
ユーレカとは
EurekaはNetflixのサブモジュールであり、コアモジュールの1つです。EurekaはRESTベースのサービスであり、クラウドの中間層サービスの検出とフェイルオーバーを可能にするサービスを見つけるために使用されます。
サービスの登録と検出はマイクロサービスアーキテクチャにとって非常に重要です。サービスの検出と登録では、サービス識別子を使用するだけで、サービス呼び出しの構成ファイルを変更せずにサービスにアクセスできます。この機能は、Zookeeperなどのダボの登録センターに似ています。
ユーレカの基本的なアーキテクチャ
Spring Cloudは、サービスの登録と検出を実装するためにNetflixによって開発されたEurekaモジュールをカプセル化します（Zookeeperと比較してください）。
Eurekaは、CSの設計アーキテクチャを使用しています。Eureka Serverはサービス登録機能のサーバーとして機能し、サービス登録センターです。
システム内の他のマイクロサービスは、Eurekaクライアントを使用してEurekaサーバーに接続し、ハートビート接続を維持します。このようにして、システムの保守担当者はEurekaサーバーを使用して、システム内の各マイクロサービスの通常の動作を監視できます。SpringCloudの他のいくつかのモジュール（Zuulなど）は、Eurekaサーバーを使用して、システム内の他のマイクロサービスを検出し、関連するロジックを実行できます。
Eurekaには、EurekaサーバーとEurekaクライアントの2つのコンポーネントが含まれています
Eureka Serverはサービス登録サービスを提供します
各ノードが起動すると、EurekaServerに登録されるため、EurekaServerのサービスレジストリは、利用可能なすべてのサービスノードの情報を格納します。サービスノードの情報は、インターフェースで直感的に確認できます。
EurekaClientは、Eurekaサーバーの相互作用を簡素化するために使用されるJavaクライアントであり、クライアントには、ラウンドロビンロードアルゴリズムを使用するロードバランサーが組み込まれています。アプリケーションの起動後、ハートビートがEurekaサーバーに送信されます（デフォルトの期間は30秒です）。Eurekaサーバーが複数のハートビートサイクル内にノードのハートビートを受信しない場合、EurekaServerはサービスレジストリからサービスノードを削除します（デフォルトは90秒）。
3つの役割
Eurekaサーバーはサービスの登録と検出を提供します
サービスプロバイダーサービスプロバイダーは、サービスをユーレカに登録して、サービスユーザーが見つけられるようにします。
サービスコンシューマーは、サービスを利用できるように、ユーレカから登録済みサービスのリストを取得します
自己保護モード
デフォルトでは、Eurekaサーバーがマイクロサービスインスタンスのハートビートを一定時間受信しない場合、EurekaServerはインスタンスをログオフします（デフォルトは90秒）。ただし、ネットワークパーティションに障害が発生すると、マイクロサービスとEurekaServerが正常に通信できなくなります。マイクロサービス自体は実際に正常であるため、上記の動作は非常に危険になる可能性があるため、このマイクロサービスをキャンセルしないでください。
Eurekaはこの問題を「自己保護モード」で解決します。EurekaServerノードが短期間に多くのクライアントを失うと（ネットワークパーティション障害が発生した可能性があります）、このノードは自己保護モードになります。このモードになると、EurekaServerはサービスレジストリの情報を保護し、サービスレジストリのデータを削除しなくなります（つまり、マイクロサービスは登録解除されません）。ネットワーク障害が回復すると、Eurekaサーバーノードは自動的に自己保護モードを終了します。
自己保護モードでは、Eurekaサーバーはサービスレジストリの情報を保護し、サービスインスタンスをキャンセルしなくなります。受信するハートビートの数がしきい値を超えて回復すると、Eurekaサーバーノードは自動的に自己保護モードを終了します。その設計理念は、考えられる正常なサービスインスタンスを盲目的にキャンセルするのではなく、間違ったサービス登録情報を保持することです。一文で説明：死ぬより生きるほうが良い
要約すると、自己保護モデルはネットワークの異常に対するセキュリティ保護手段です。そのアーキテクチャの哲学は、すべてのマイクロサービスを同時に保持する（正常なマイクロサービスと正常でないマイクロサービスは保持される）か、正常なマイクロサービスを盲目的にキャンセルすることです。自己保護モデルを使用すると、Eurekaクラスターをより堅牢で安定させることができます。
Spring Cloudでは、eureka.server.enable-self-preservation = falseを使用して自己保護モードを無効にすることができます。
よく知られているCAP理論では、分散システムはC（一貫性）、A（可用性）、およびP（パーティションのフォールトトレランス）を同時に満たすことができないとしています。分散システムではパーティションのフォールトトレランスを保証する必要があるため、AとCの間のトレードオフしかできません。ここでZookeeperはCPを保証しますが、EurekaはAPです。
エウレカと飼育係の違い
ZookeeperはCPを保証します
登録センターにサービスのリストを照会する場合、登録センターが数分前に登録情報を返したことは許容できますが、サービスを受け入れることができず、直接ダウンして利用できません。つまり、サービス登録機能には、一貫性よりも使いやすさが求められます。ただし、zkにはこのような状況があり、マスターノードがネットワーク障害のために他のノードとの接続を失うと、残りのノードがリーダーを再選します。問題は、リーダーの選挙時間が30〜120秒と長すぎ、選挙中はzkクラスター全体が利用できないため、選挙中に登録サービスが麻痺することです。クラウドデプロイメント環境では、ネットワークの問題が原因でzkクラスターがマスターノードを失う可能性が高くなります。サービスは最終的に復元できますが、登録の長期的な利用不可が原因で生じる長期の選挙時間は耐えられません。
ユーレカはこれを理解しているため、最初に可用性を確保するように設計されています。Eurekaの各ノードは同等であり、いくつかのノードで障害が発生しても、通常のノードの動作には影響しませんが、残りのノードは登録およびクエリサービスを提供できます。Eurekaへの登録時に接続が失敗したことがわかった場合、Eurekaクライアントは自動的に他のノードに切り替えます。Eurekaがまだ利用可能である限り、登録サービスが利用可能であることを保証できます（保証の可用性）が、見つかった情報のみ最新でない可能性があります（強い整合性は保証されません）。また、Eurekaには自己保護メカニズムもあります。85分以上のノードで15分以内に正常なハートビートがない場合、Eurekaはクライアントと登録センターの間にネットワーク障害があると見なします。このとき、次のタイプが表示されます。状況：
1. Eurekaは、長い間ハートビートを受信していないため、期限切れになるはずのサービスを登録リストから削除しません。2。Eurekaは
、新しいサービスの登録およびクエリ要求を受け入れることができますが、他のノードと同期しません（つまり、現在のノードは保証されます） （まだ利用可能）
3.ネットワークが安定すると、現在のインスタンスの新しい登録情報が他のノードと同期されます。
したがって、Eurekaは、zookeeperのような登録サービス全体を麻痺させる代わりに、ネットワーク障害のために一部のノードが接続を失う状況にうまく対処できます。
純粋なサービス登録センターとしてのユーレカは、飼育係よりも「プロフェッショナル」です。登録サービスはユーザビリティにとってより重要であるため、短期的な一貫性を受け入れることができます。
