マイクロサービス高可用性プログラム
マイクロサービスのまず、可用性
レジストリでは、レジストリの動作原理について学ぶための高可用性ソリューションセンターを設定する前に、1は、レジストリと、様々なマイクロサービスのレジストリとの同期を取得している、そして第二に、どのようにレジストリに、二つの部分に分けて説明レジストリのメンテナンス。
1.1、レジストリへのアクセスと同期
ユーレカServerとユーレカクライアントとの間の関係は、レジストリによって維持され、およびレジストリ、ユーレカサーバーの集中管理により、ローカルに各クライアントのキャッシュのレジストリは、定期的なタスクによる最新のレジストリ情報を引き出します。簡単な例を以下に示します。
フローチャートのショーによると、プロセスは、レジストリおよびマイクロサービスとの本質的なリンクを理解することができます。
1。サービスの開始時間、ユーレカServerにその関連情報を登録します
2。サービスBはユーレカサーバーに最新のレジストリを引くと、あなたは、マシン登録情報サービスAを得ることができます
3。他の二つのマシンのサービス登録情報は、サービスBの30代が再びプルするとき、あなたが買ってあげる3つのマシンにサービスを提供する登録に行きます
4。サービスAは、ユーレカServerにハートビートメッセージを30秒ごとに送信し、その登録情報がまだ有効であることを示します
これらは、特に練習、ユーレカServerは、レジストリマルチレベルキャッシュ、取得および同期情報を提供し、微妙な違いがあるでしょう、一般的に、レジストリおよびマイクロサービス間の相互作用のプロセスです。
1。直接メモリ内のデータ構造を維持して、純粋なメモリに基づいて、ユーレカServerレジストリ。
2。登録、組立ラインオフサービス、サービスの障害各サービスは、すべてが維持され、メモリにレジストリを更新します。
3。各サービスユーレカServerはその上にそれらへのレジストリデータの変更のメモリに直接格納され、レジストリを引っ張って、30秒ごと。
4。同様に、30秒ごとにハートビートを開始するために、ハートビートが今回、純粋なメモリマップのデータ構造で更新されます。
readWriteCacheMapとreadOnlyCacheMapが頻繁に読み取りと書き込みのキャッシングん提供することが紛争を保護するものではありませんがレジストリユーレカServerは、すぐに純粋なメモリ処理で、処理速度。以下の図。
図ユーレカServerは、マルチレベル・キャッシュの原則が導入されています。
1。最初のサービスAが登録された場合、あなたが適切な情報readWriteCacheMapを持っている場合ではないが、その後の操作をしない場合は、その登録情報は、日付のうち、レジストリのメモリに更新されます
2。サービスB、レジストリ情報を引き出しreadOnlyCacheMapに最初に行く、readWriteCacheMapを見つけられませんでした、何の登録情報は、メモリ、レジストリに行くん見るためには、readWriteCacheMapに更新されると、サービスB、レジストリサービスのBへの復帰を見つけました、マシンが登録されたサービスの情報を持っています
3。これは、タイミングreadWriteCacheMap readOnlyCacheMapとバックグラウンドタスク、一回30秒ごとの非同期化、キャッシュ同期タスク間の同期であります
4。第2の登録デスクサービス、レジストリのメモリを更新し、readWriteCacheMap日のうちながら、
5。タスクは、レジストリを引っ張ってキャッシュの同期化サービスBの前に実行されている場合は、サービスBを取得しないように、readOnlyCacheMap、新しいレジストリからデータを取得することです
6.30s後、同期readWriteCacheMapデータキャッシュ同期タスクとでreadOnlyCacheMap、レジストリ内の日付のうちreadOnlyCacheMap、その後、サービスBはメモリキャッシュからデータを取得readWriteCacheMap、データを取るreadWriteCacheMap見つける、サービスに戻りましたB、Bのレジストリサービス、2つのサービス登録済みのコンピュータ情報があるだろう
7。次の30代では、readWriteCacheMap readOnlyCacheMapを同期するためのキャッシュの同期タスクの前に、readOnlyCacheMapは、第二のキャッシュサービスAを登録していないので、最新のデータreadWriteCacheMapから取得されます
注意：
readOnlyCacheMapキャッシュの更新インターバルタイマ、デフォルトは30秒です
readWriteCacheMapキャッシュの有効期限は、デフォルトは180秒です
DELAYの30代の力に最新のレジストリエントリながら、上記のプロセス記述からは、ユーレカServerは、マルチレベルのキャッシュ戦略を取ります。マルチレベルキャッシュメカニズムの利点は何です。
1。可能な限りのレジストリデータメモリを読み、頻繁に競合せずに書くことを確認します。
2。そしてさらには、多数の要求ユーレカServerは、純粋なメモリ、高性能から行くために迅速であることを確認します。
1.2、マイクロレジストリ保守サービスレジストリ
次のようにユーレカクライアントのレジストリ関連の動作は次のとおりです。
1。サービス登録（レジストリ） - 登録し、その情報サービスインスタンスノードがPOST要求に基づいて、サーバにIP、ポート、インスタンス名などが含まれ、初期化時間を実行します。
2。サービス契約（更新） - サーバ障害を除外してはならない、リアルタイムで更新され、現在のサービスノードのステータス情報を確実に、30秒ごとに時間をPUTサーバーにデフォルト設定。
3。アップデートは、サービスリスト（fetchRegistry）登録されている - 地元が他のノードに最新の登録情報を得ることができることを保証するために、一度サーバーGETから30秒ごとの増分バージョン情報をデフォルトして、比較し、ローカルマージします。
4。サービスオフライン（キャンセル） - サービスのシャットダウン、そのエンドへのタイムリーな通知サービスの必要性は、クライアントは、サービスがオフラインになった呼び出しを防ぐために除去。
ユーレカクライアントは、サービスのお問い合わせを、ジャージークライアント、サービス契約を登録することにより、サービスと対話サービスをキャンセルするために、HTTPプロトコルユーレカサーバーに基づいています。インスタンスが更新されておらず、90年代には、すべての障害が取り除かれたため、同時に、サーバー側のサービスも、例のリストを維持します。
ユーレカServerは、ネットワークに障害が発生したときに、自己保護メカニズムを持ち、クライアントとサーバに障害が発生し、ユーレカサーバーの自己保護メカニズムを開始する必要があるネットワークが回復したときに、これは、退出自己保護をサービスを排除しません。自己保護は、2つのパラメータ、直前（更新（最終分））を受信した心拍数を有する心拍の所望の数が（閾値を更新）を受信し、更新閾値は>更新した場合（最後の分）、自己保護モードに入ります。
更新（前回分）=インスタンスの数のインスタンスの数が2＃カウントユーレカサーバーの自己登録サービスを*
しきい値=更新（前回分）* 0.85＃0.85設定可能な更新
図では、登録の10件のインスタンスがあります。
より多くのユーレカServerの展開、オープン自己保護を推薦
eureka.client.register-with-eureka = true1.3、分散レジストリ
レジストリの動作原理を理解し、あなたは、分散、マルチレジストリ、マルチサービス・インスタンスリサーチサービスを開始することができます。
登録のみの中心部、レジストリが失敗したときに、新しいサービスは、登録まで、旧サービスの登録情報を続行することができませんでしたマイクロ・サービスの登録は、他のレジストリとクライアントでのキャッシュが、まだ使用可能な場合は、再起動後に、レジストリに登録することはできませんが、また、使用することはできません。
そのため、サーバーの両方として、クロス登録が必要な、各登録センターを高可用性レジストリを構築し、そして時にマイクロサービスは、レジストリ自分で、各登録センターに登録する必要がありながら、クライアントは、他の登録センターに自分自身を登録するときマイクロリスタートサービスが利用できないその上に登録するだけで、レジストリを引き起こした単一故障を防ぐために、相互支援を濾過しました。図に示すように。
現在、レジストリや設定センターが一緒に、レジストリを設定するために、全体的な分割に取り外し可能な、ほとんど影響を分割しないと、互いの中心には影響を与えません。gitlabは、すべての一般的な設定の理由は、分散CONFIG障害リスクのシングルポイントの存在で、その結果、gitlab、マシンのいずれかに配備します。各設定はそれぞれ独立したgitlabは、運用・保守は偉大な不便を引き起こしました。データベースストレージ構成、障害の問題単一点を解決するために、代替gitlabの分散データベースを使用する利点とアポロの後期採用。
1.4、レジストリの圧力測定
圧力測定調査、ユーレカサーバの8コア4G 1000個のサービス・インスタンスを処理する場合、何ら圧力が存在しないは、デフォルトで、7,000インスタンスを処理することができ、Tomcatの構成を変更した後、タイムアウトエラーを超え、運ぶためにアップ例8000と、実質的に完全なCPU。
考慮事項をアップグレードします。
図1に示すように、ユーレカサーバ間で互いに登録、ユーレカクライアントのニーズはサーバのそれぞれの側に登録されています
2、ユーレカサーバーオープン自己保護
3、インスタンスユーレカクライアントの数は、1000年以上ではありません
参考：
[1] https://www.jianshu.com/p/ae4f0c8b8135
[2] https://www.cnblogs.com/xishuai/p/spring-cloud-eureka-safe.html