どのようにサービスをオフラインのリアルタイムAPI Gatewayの知覚を達成するために

記事「ユーレカキャッシュメカニズムは、」リアルタイムAPI Gatewayの認識サービスをオフラインを達成するためにどのようにこの記事を詳述、私たちはユーレカのより良い理解を持っていると信じて、ユーレカキャッシュメカニズムを説明しています。

I.はじめに

動的に割り当てられたマイクロネットワーク・ロケーション・サービス・インスタンスにクラウドベースのサービスアプリケーション。そして、自動スケーリング、障害およびアップグレードするため、サービスインスタンスは、多くの場合、動的に変化します。そのため、クライアントコードは、より複雑なサービス発見メカニズムを使用する必要があります。

クライアント側のサービス探索と発見：現在、主に2つのモードで見つけあります。

サーバー検出：サービスレジストリ要求、ロードバランサ照会サービスレジストリにロードバランサによって開始され、クライアント、各要求は、利用可能なサービスインスタンスにルーティングされます。
クライアントディスカバリー：クラスタ内で使用可能なサービスのデータベースで、クライアントは、サービスインスタンスの利用可能なネットワークアドレスを決定するための責任がある、と要求の負荷分散、クライアントアクセスサービスの登録フォーム、し、クライアントが選択するために、ロード・バランシング・アルゴリズムを使用していますその後、利用可能とするサービスの例は、要求を開始します。

発見の最大の違いに関しては、クライアント側のサービス発見は次のとおりです。クライアントは、（キャッシュ）サービス利用可能レジストリ情報を知っています。クライアント側のキャッシュでない場合は、サーバーからのタイムリーなアップデート、そして一貫性のないクライアントとサーバーのキャッシュデータが発生する可能性があります。

第二に、組み合わせゲートウェイとユーレカ

NetflixのOSSは、クライアント・サービス・ディスカバリの良い例を提供します。ユーレカサーバーのレジストリとして、ユーレカServerへのZuulの相対ユーレカクライアントで、ZuulユーレカServerは、ローカルキャッシュリストにサービスを終了し、サービスのリストを更新する定期的なタスクの形、および他のサービスで地元zuul通じますが、リストを見つけ、リボンを使用しますクライアントの負荷分散を実装します。

通常の状況下では、呼び出し側は即時応答を取得することができますゲートウェイへの要求を開始します。生産者が組立ラインオフ減容、状況のアップグレード、これによるマルチレベルのキャッシュ・アーキテクチャの設計にユーレカとメカニズムは、定期的に更新を行うときには、Bのサービスのリストのロードバランスの終わりには、前回の記事で（状況が更新されない存在します」ユーレカのキャッシュメカニズムは「見ることができ、最長提供する消費者は無限240Sに近づい時間を知覚）消費者がゲートウェイに要求を開始した場合、その後、ロードバランスは、存在しないサービスの開始要求を持っている、リクエストがタイムアウトします。

第三に、ソリューション

アイデアの実現3.1

組立ラインオフ生産した後、最初はreadWriteCacheMapにおけるユーレカServerは、最終的にコアロードバランスにおけるゲートウェイの知覚を得るという認識を取得します。しかし、ロードバランスは、ロードバランス、ローカルに保持されるリスト内の生産者に発見しました。

組立ラインオフプロデューサーのリアルタイムゲートウェイの知覚を達成するためにそう、あなたがこれを行うことができます：まず、プロデューサーや展開プラットフォーム事前通知ユーレカServer用、およびその後はユーレカマルチレベルのキャッシュ間の更新時間をスキップし、ユーレカクライアントで直接通知Zuul、最後に、サービスユーレカクライアントのリストは、リボンに更新されます。

しかし、もし生産上のオフライン通知ロジックコード、公害問題、言語の違いが発生しますコード。

有名なことわざを借りて：

「コンピュータサイエンスの任意の問題は、間接的な中間層を追加することによって解決することができます」

オフラインのため、外部のREST APIを提供し、プロキシサービスのゲートウェイ-SynchSpeed同等で、状態はユーレカサーバーとゲートウェイのコアの生産に同期される一方、呼び出し側の要求に応答同期状態と柔らかいものの役割を果たしています。

アイデア：行うには生産量の減少を、組立ラインオフ、アップグレード 前に、クモのプラットフォーム（クモコンテナ管理プラットフォーム）をゲートウェイ-SynchSpeedはユーレカに通知されます、ダウンしているゲートウェイ・SynchSpeedプロデューサーのインスタンスを通知するためのイニシアチブをとるだろうプロデューサーServerのインスタンスが停止しています。ユーレカサーバーオフライン成功場合は、ゲートウェイ・SynchSpeedコアゲートウェイは直接通知されます。

デザインの特徴

非侵襲的な、使いやすいです。限り、ゲートウェイ-SynchSpeedは論理の真の実現に基づいていますが、達成するために、エージェントへの呼び出し側に侵入しませ休むHTTPへの要求を開始するとどのような言語の呼び出し元、呼び出し元気にしないでください。
アトミック。最初のユーレカServerの呼び出し側がオフラインの場合、次の行は、サービスをオフラインある程度のアトミックな性質を保証するために、関連するすべてのコアゲートウェイ、「柔らかいもの」のゲートウェイ・SynchSpeed同等で最小動作実行ユニットです。

3.2実装の手順

手順説明

最初のステップ：プロデューサーが行うアップグレード、減容化、オフラインに する前に、スパイダープラットフォームは、サービス・ゲートウェイ・SynchSpeed httpリクエストフォーム、通知サービスIPインスタンスコンテナの粒子サイズを通知します。
ステップ2：要求を受信した後、ゲートウェイ-SynchSpeed、IPの利用可能性を確認してから、ユーレカサーバーに通知します。
第三段階：ユーレカサーバがプロデューサ故障条件を設定し、その処理結果（二分割ユーレカオフライン形一つ直接サービスレジストリのリストから直接除去さを返すために、第二の状態は、オフラインであることは、プロデューサーであります状態セットOUT_OF_SERVICE。フォームが最初の組立ラインから外れている場合はユーレカサーバー、サービスに同期この期間プロデューサーのハートビートがユーレカサーバーに再登録されます場合は、スパイダープラットフォーム発行切断要求は、プロデューサーのプロセスがすぐに殺す保証することはできません）。
ステップ4：前のステップで得られたゲートウェイ-SynchSpeed結果結果が成功した場合、次のステップが実行され、そうでない場合、停止。
ステップ5：ユーレカクライアントとして、ゲートウェイ-SynchSpeed。IPプロデューサーアプリケーション名でサービスを取得するために、ローカルの登録リストによりゲートウェイは、SynchSpeed。
ステップ6：アプリケーション名コアライブラリへのオフラインサービス・ゲートウェイに関連するすべてのクエリによってゲートウェイ-SynchSpeed 。 网关组名字
ステップ7：を通じてゲートウェイ-SynchSpeed ローカルサービスリストに：（ポートIP）ゲートウェイアドレスIPADDRESSグループの下にあるすべてのサービスを見つけること。 网关组名字
ステップ8：関連するすべてのゲートウェイノードのゲートウェイ・SynchSpeed非同期通知。
第九ステップ：ゲートウェイ-Coreは、通知を受けた後、プロデューサーの状態はオフラインで行われ、キャッシュDownServiceCacheの成功例にすべてのオフラインステータス情報を記録します。
ステップテン：ゲートウェイコアリボンは、サービスのローカルリストを更新します。

第四に、補償機構

ユーレカは、セキュリティ・メカニズムを提供します。旧ユーレカServerの更新サービスのリストからユーレカClientは、（クライアントサービスのリストが変更され、ハッシュ値が変更されます）、関連するハッシュ値が変化するかどうかを確認し、変更された場合、（、更新から増分更新の全額を更新するための方法になるだろう「ユーレカキャッシングは、「 readOnlyCacheMap 30代とreadWriteCacheMapデータ）が異なる場合があります内のクライアント側のキャッシュのリストは、最終的には一貫性のないリボンエンドサービスリストreadWriteCacheMapデータにつながる場合、それはreadOnlyCacheMapに覆われていることを示しています。

ユーリカこのメカニズムについては、30代を超えていないキャッシュ・サービスのためのプルイベントのユーレカクライアント全額をリッスン補償機構としてEurekaEventListenerリスナーを導入し、そのステータスが再設定されます。 OUT_OF_SERVICE

五、APIのセキュリティ設計

アカウントにシステムのセキュリティ問題を取ると、悪意のある人物にアクセスすれば、ユーレカServerによって生産者を見つけることができない消費者で、その結果、ユーレカServerの組立ラインオフ理由もなく生産を行うことができます。

黒と白のリストフィルタを使用して、次のようなセキュリティは、基本的なプロセスがありません。

ゲートウェイ-Synchspeedにホワイトリストセグメント（IPネットワーク）
一方、濾過し、要求元IPサブネット、解放場合ゲートウェイSynchspeedは、要求者のためにオフラインIPチェックサムのために、フィルタに添加しました。

第六に、バックログ

ゲートウェイ・SynchSpeedとゲートウェイコアがドッカーコンテナに配備されているので、コンテナが再起動された場合、それは失われたログファイルが発生します。だから、Elasticsearchに書かれているゲートウェイ・SynchSpeedおよびゲートウェイコア関連のログに必要である、Kibana Elasticsearchクエリデータと表現する視覚的な方法のための最終的な責任です。

七、コードスニペットショー

ゲートウェイ・SynchSpeed状態の同期化を行います

EurekaEventListener処理キャッシュデータ

八、サプリメント

組立ラインオフリアルタイムゲートウェイサービスの現在の認識、Zuulと春の雲Zuul 1.3.6.RELEASE、春の雲ユーレカ1.4.4.RELEASEのユーレカバージョン。

現在のゲートウェイ下流サービスのリアルタイムゲートウェイ知覚の実装だけでなく、以下の条件を満たしている必要があります。

生産者はkubernetesコンテナ管理プラットフォームに展開する必要があります
生産者は、通常行うオフライン、アップグレードまたは体積の減少操作を。容器は、組立ラインオフ異常なサービスの停止やその他の非正規で、その結果、リソースの不足が原因である場合は、それがサポートされていません。

組立ラインオフゲートウェイサービスは、デフォルトでは、この機能を提供するビジネスゲートウェイ・ソリューションのオプションのリアルタイム知覚はクモのプラットフォームではオンになっていないが、この機能は、独自のビジネス・システムの要件に応じて、当事者でオンになっている特定の構成を決定し、どのように見APIゲートウェイへのアクセスに関するガイドライン 「蜘蛛のリアルタイムゲートウェイを意識した構成ドキュメント」インチ

作者：謝Guohui

出典：テクノロジーのCreditEase研究所