A、ユーレカ原則

1、チャート

ユーレカの公式マップの構造を初めて目

　　ユーレカクライアントの相互作用とユーレカサーバー、サービスプロバイダ登録情報などのすべてのアプリケーションはユーレカサーバー、更新にサービスを提供し、独自のIP、ポートを起動して、定期的にその状態を更新します。

　　ユーレカServer検出を介してサービスの消費者が希望する情報サービスプロバイダのアドレスを取得した後、リモートサービスプロバイダへのコールを開始します。

　　高可用性ユーレカレジストリを確保するためには、他のサーバーノードに通知、展開をクラスタ化することができたときにノード情報やアップデート、複製経由ユーレカデータ同期の異なるノード。

2、基本原理

ユーレカ応答の過程では、3つの役割、すなわちユーレカ、サービスプロバイダ、サービスコンシューマがあります。

サービスが開始した後、サービスプロバイダは、などの呼び出しアドレス、サービス情報、として、ユーレカ自身の情報が登録します
情報サービスプロバイダを記録し、管理を担当、そのアドレスを公開、サービスセンターのためのユーレカを登録するだけでなく、サービスプロバイダーの要件を満たすアドレスリストサービスの消費者を返します
ユーレカへのサービス消費者のサブスクリプションサービス、彼らのニーズを表明した後、メッセージ・サービス・プロバイダを取得し、あなたがリモートで呼び出すことができます

次のような役割があり、ユーレカサーバーユーレカクライアント：エウレカは、二つの成分を含みます：

ユーレカクライアントはJavaクライアントであり、主にユーレカサーバーの相互作用を簡素化するために使用されます
ユーレカServerは、個々のマイクロは、ユーレカクライアント、サービスに関するサーバーの情報が格納されてユーレカサーバーに自分の情報を登録する際にサービスが開始されると、発見にサービスを提供する機能を提供します
サービスは、自分の情報を更新するためには、タイムアウト（デフォルトは90年代である）のハートビートを受信しなかった、サーバーにハートビート情報を送信する（デフォルトは30代です）、定期的にマイクロを開始した後、サーバーは、サービスノードをログオフします
ユーレカServerは、サービス・プロバイダ・ノードからログオフし、加入者がローカルキャッシュ情報を更新するために、他の加入者にサービスを公開するために設定した後
クラスタでは、各ユーレカServerがあるためユーレカハングのノードを回避し、全体のマイクロサービスアーキテクチャハングを引き起こすために、サービスレジストリメッセージの同期を完了するために、互いへの登録、またユーレカクライアントであります
ユーレカのクライアントサーバーは、キャッシュに関する情報は、ローカルキャッシュは定期的に更新されているかどうかを確認する最初の、サービスを呼び出す前に情報をキャッシュします

3、自己保護メカニズム

　　ハートビート更新情報サービス提供後のタイムアウト（デフォルト90年代）を受け付けていないので、クロスプロセスサービスへユーレカインスタンスの取消のためのサーバが、しばしば、このようなミクロのように、マイクロ間により大きな衝撃ネットワークトラフィック状況にさらさ呼び出しサービスは正常ですが、ネットワークパーティションが失敗した場合、サービスインスタンスをログオフほとんどのマイクロサービスは、このような状況、ユーレカの自己保護メカニズムの導入を避けるために、利用できないでしょう。短時間でユーレカServerノードは、クライアントノードのあまりに多くを失ったとき、ノードは自己保護メカニズムに入り、自己保護メカニズムの原則、もはや、ネットワーク障害が正常に戻ったときに、任意のマイクロサービスインスタンスをオフに書きますノードは自動的に自己保護メカニズムを終了します。

　　ユーレカServerまたはユーレカクライアントサービスが得られ、問題を区別するために自己保護のしきい値に基づいて、自己保護メカニズムは時間に更新することができませんでした。

4、サービスメカニズム

　　　サービス登録プロセスによる本サービスは、定期的に通常のサービス停止は、そのサービスを停止する前に、登録センターにログアウト要求を送信した場合や新たなサービス、通常のノンストップ場合、送信されません、順次で、ユーレカサーバによるサービス主導権を除きます。

4.1、サービス登録メカニズム--register

登録サービス、およびサービスプロバイダーの時にプロバイダステータスの更新サービスのステータスの変更を開始します。

そして、自己保護のしきい値を更新するサービスを利用するためのメカニズムを除く;;、サービスの登録を受け付ける登録情報を保存するサーバーの後、最後の同期サービス情報、その他のユーレカServerノードにこのイベントを同期させます。

4.2、サービスリニューアルメカニズム--Renew

定期的にサービスプロバイダによって呼び出され、サービスサーバを更新するために、ハートビート情報を送信します。

レジストリの更新要求、最近の更新時間更新サービスオブジェクトは、同期サービスの情報を受信した後、他のユーレカServerノードにこのイベントを同期させます。

条件の一つは、現在の契約期間の満了最近の時間差が閾値よりも大きいということであれば私たちはまず、サービスを削除する前に、サービスの有効期限が切れたかどうかを判断します。

4.3、サービスキャンセル機構--Cancel

サービスプロバイダによって呼び出されたときに、あなたのサービスをキャンセルし、シャットダウン。

登録レジストリに受信された要求を取り消す、と同様のメカニズム、最初のメッセージを削除し、更新（サービスを除く）の閾値の後、最後のイベントは、他のユーレカサーバーノードを同期させます。

4.4、サービスメカニズムを除く--Eviction

　　除くサービスは、最初に、最終的な実装サービスを除く、期限切れのサービスを見つけ、サービスは条件が満たされているかどうかを判断拒否、3つのステップから構成されています。

サービスは、条件が満たされている拒否かどうかを判断し、主に自己保護メカニズムユーレカを開くかどうかを確認するために-

　　ケースは、次のステップに直接自己保護メカニズムを閉じました。

　　オープン自己保護機構の場合は、唯一の実際の契約は自己保護のしきい値の数よりも大きい、サービスカリングプロセスを入力します（ほとんどのサービスは、クライアントを決定するために利用可能であることを示すことは問題外反する判断サーバー上、問題となっています）。

　　セルフサービスの保護スレッショルド=合計*（60代/クライアントの更新間隔）*自己保護スレッショルド係数。

期限切れのサービスを探します

　　すべてのサービスを通じて、時間差の現在値、設定されたしきい値よりも大きいから最新の更新時間を決定し、期限切れとしてマークされ、すべての期限切れのサービスセットを保存しています。

除くとサービス

　　期限切れのすべてのサービスを通じ、アルゴリズムをシャッフルすることにより、すべての時間はあなたがサービスの公正な選択を排除することを保証し、そして最終的に削除されます。

4.5、プルサービス--Fetchレジストリ

サービス消費者によって呼び出され、同じ名前の登録サービスリストの中心を見つけます。

サービスプロバイダは、通常のローカルキャッシュにアドレス情報を一覧表示し、デフォルトのキャッシュ情報は、一度30秒ごとに更新されます。

4.6は、サービスが--replicate同期します

サーバのみ登録上のサーバークラスタの情報を更新することができますサーバーの同期サービスプロバイダ間のサービス情報を実装するために使用されます。

ノードが登録要求を受け入れ、再び繰り返されるアイソクロナス複製を避けるために、isReplicate = trueをマークしたものを除いて、他のサーバノード、インターフェース、などの同一の呼び出しパラメータに要求を転送します。

非同期モードへの情報の同期が完了すると、すべてのノードが唯一の最終合意することを確実にすることができる情報の強い一貫性を保証するものではありません。

4.7、追加する新しいノード（新規サーバーの初期化）

新しいサーバノードの参加、消費者はすべての登録情報を引っ張るとしての地位を起動し、自ノード、マークisReplicate = trueの場合、完全に初期化する各サービスを登録します。

4.8、ストレージの構造 - 2つのハッシュ地図

選択の第二に、サービスレジストリ

1、CAPの原則

　　CAP定理：分散システムでは、一貫性（整合性）、アベイラビリティ（可用性）、フォールトトレランスパーティション（パーティション公差）、3つを同時に得ることができます。

一貫性：分散システムでは、すべてのデータが同時にバックアップされ、同じ値か
可用性：クラスタノードの障害の一部、クラスタの正常な応答は、クライアントに要求を読み書きすることができます
区のフォールトトレランス：すなわち、高可用性、他のノードには影響しません、ノードに障害が発生した後にハングアップ

　　CAP理論は、それらのうちの2つの最大を達成しながら、分散システムにおいて説明したが、起因する問題への現在のネットワークハードウェアの損失が発生することがバインドされて遅延されたので、パーティションのフォールトトレランスが非常にのみ一貫性と可用性の中間に、必要ですトレードオフ。

2、レジストリの選択

　　現在主流の登録センターユーレカように、飼育係、領事と、それらの異なる強調。

2.1、飼育係の保証CP

　　ネットワークは、他のノードとの接触を失ったため、飼育係は、マスターノードに障害が発生した後、残りのノードは、再選挙のリーダーノードになりますが、サービスは最終的に回復することができますが（30〜120秒）選挙の際に、ZKクラスタ全体では、使用できません。しかし、選挙登録センターの長いリードタイムは、長期間の使用が許容されていないことが多いです。

2.2、領事保証CP

　　領事は強い一貫性があります：エウレカより遅いサービス登録、いかだの領事プロトコルは、ノードの過半数を必要とするため、登録が成功とみなされた成功を書かれている必要があります。ノードがリーダーをハングアップすると、全体の非領事の再選時にクラスタの可用性を犠牲にして。

2.3、Eureka保证AP

　　Eureka在设计时优先保证可用性，其中各个节点都是平等的，几个节点挂掉，剩余节点仍能提供注册和查询服务，只要有一台Eureka还在，就能保证服务可用（保证可用性），但不保证查询到的信息时最新的（不保证强一致性）；除此之外，由于自我保护机制不再剔除服务实例的节点，仍能接受新服务的注册和查询请求，但不会被同步到其他节点上。

　　同时，Eureka还提供客户端（Eureka客户端程序负责向外提供注册与发现服务接口）缓存功能，所以极端情况下，客户端无法访问任何一个Server节点，消费者仍能通过客户端查询与获取注册服务信息。

　　因此，Eureka可以很好地应对因网络故障导致部分节点失联的情况，尽可能地保证整个集群的可用性。