マイクロサービスデザイン研究（C）サービスの登録と発見サービスガバナンス

序文

過去のシリーズへようこそ：

今日の人気のマイクロサービスでは、サービスの粒度の株式分割は、非常に細かい、サービスの数の急速な増加が続きます。クラウドネイティブの波では、より頻繁に一緒に、コンテナ管理プラットフォームと組み合わせたサービス管理は、ワンストップの自動化派遣管理プラットフォームを形成します。

もちろん、コンテナベースのスケジューリングシステムの使用かどうかにかかわらず、変更のサービスガバナンス原則と範囲は発生しませんが、それを達成するためのさまざまな方法インチ

サービス検出、ロードバランシング、電流制限、ヒューズ、タイムアウト、リトライ、追跡やその他のサービスを含むサービス管理。私たちの物語は、今日では、コンテンツサービスの発見です。

この章のまとめ

この章では、次の内容について説明します。

サービスの発見とは何ですか？（何）
マイクロサービスの枠組みの下で、なぜあなたはサービスがそれを見つける必要があるのですか？（なぜ）
サービス発見は、それが動作しない方法ですか？（どのように）
CAP定理
導入されたいくつかの既存のソリューション（実装）

さて、今、この旅を始めましょう。

サービスの発見は何ですか（何）

サービス発見は、サービスプロバイダーのネットワークの場所の情報を見つけることを指します。

具体的に他のサービスが急速にこれらのサービスが登録されている見つけることができるように、分散型システムサービスのすべての情報を記録するために、レジストリを使用することを意味します。

サービス発見は、通知のためのサービス登録、サービスの発見、サービスの健康診断やサービスを持っているキーを変更するために大規模なSOAサービスとマイクロアーキテクチャコアモジュールのニーズを支援しています。

なぜあなたはサービス検出が必要なのでしょうか？（なぜ）

いかなるサービス発見モジュールが存在しないので、維持するのが困難システムを引き起こし、消費者の間で特定のサービス構成に接続されたコンフィギュレーションサービスネットワークの位置情報です。

そのような基本的な質問を考える：どのようにサービス利用者は、サービスプロバイダーのIPとポート、それを認識しているのですか？

単純なアーキテクチャでは、（などDNS、Nignxロードバランシング設定、など）静的な構成は、この問題を解決する良い方法であることができます。各サービスは、同じ位置に配備され、ほとんど変更ありません。いいえ弾性伸縮需要ません。確率変動の伝統的なモノリシックなアプリケーションのネットワーク・アドレスを手動で更新する操作および保守員の変化の場合には、コンフィギュレーションファイルをロード、小さいです。

しかし、マイクロサービスアーキテクチャでは場合、ないマイクロサービス更新、頻繁に、そして多くの場合、負荷に応じて弾力性と弾性になり、サービスのマイクロ応用例におけるネットワークアドレスの変更は非常に正常なものですので、我々はそれ以前の静的な構成を述べましたこうしたについては明らかに適切ではないソリューション、非常にダイナミックなシーン。だから、我々は、メカニズム（モジュール）を提供する必要があるので、サービス利用者に迅速かつサービスプロバイダのIPアドレスを変更した時点での最新情報をタイムリーにアクセスすることができます。

サービス発見は、それが動作しない方法ですか？（どのように）

前述したように、レジストリを使用すると、他のサービスはすぐにこれらのサービスが登録されている見つけることができるように、分散型システムサービスのすべての情報を記録します。

のは、サービス発見メカニズム（簡易版）の動作を説明するために2つの例を使用してみましょう：

biz serviceサービスセンターは、書かれた、完全な、そのサービス情報サービスセンターを伝える開始します
admin serviceスタート、リクエストへのサービスセンターbiz serviceサービス情報
に戻り、サービスに対応するサービスセンターの位置情報を検索しますadmin service
admin service実際のアドレスを取得した後、biz service要求を開始します

ときbiz serviceクラスタアーキテクチャを使用する場合は、ライン上の複数のノードがあり、全体のワークフローはどのようにそれのようなものでしょうか？

新しいノードのサービス登録・ディスカバリー・センターは、独自のサービス情報を伝える起動し、書かれたサービス・センターの完全な
admin service更新する要求開始biz serviceアドレスリストサービスを

情報要求を更新するために、クライアント側の主導権を与えるためには、「プル」の方法です。クライアント側は、通知サービスセンターを待って、コールバックを登録があり、される「プッシュ」方式）

CAP定理

全体の操作機構の「サービス検出」は理解するのは簡単ですが、サービスのコアマイクロアーキテクチャー・システムとして配布実際の場面では、我々は間違いなく、ビルドクラスタへの道を必要としますが、高可用性を確保。今回は、分散システムが発生する可能性のある問題のいくつかを検討する必要があります。

分散コンピュータシステムでは、唯一の整合性（一貫性）を満たすことができ、可用性（アベイラビリティ）とパーティションのフォールトトレランス（寛容パーティション）の三つの基本的な特性の2が、これは有名なCAP定理です。

一貫性は：同時にデータの更新されたコピーを返すことが可能であるすべてのノードを指します。
可用性は、各要求に応答して返すことができる非エラーを指します。
フォールトトレランスをゾーニング：サーバー間の通信を意味し、特定の時間に実行し続け、それがシステムに影響を与えない場合でも開いたままにすることはできません。

分散システムでは、フォールトトレランスのパーティションを満たしている必要があります。したがって、それはトレードオフの一貫性と可用性の間で、「選択APはCPに選んだ」と呼ばれている必要があります。

CAP上の定理は、子供用の靴に慣れていない、あなたが読んで拡張することができます- CAP定理を

使いやすさを犠牲にして整合性を選択した場合、サービス発見および登録センタークラスターについては、（CPを選択し）、次いで、マルチサービスセンターに一貫性のあるデータ、ダウン一度サービスセンター、必要のクラスタポイントのサービスセンターを確保するために外国データのサスペンションは、サービスを提供するために書かれています。書かれたサービスの可用性を犠牲にし、同時に、一貫性のあるデータサービスセンタークラスターを確保。あなたが一貫性の費用（APを選択）で利用可能に選択した場合、サービスの中心点がダウンしているときに中断のないサービスを確保するために、まだ生きサービスセンターノードは、ローカルストアに直接書き込むデータを選択することができ、その後、クライアントに返します両端が、これは順番に、複数のノード間で一貫性のないデータになります。

サービス発見システムの登録のために提供するために、業界では、基本的に満たすようにしているAPか、CPシステム。

既存のソリューション（実装）

分散型サービスシステムでは、サービス提供者と消費者のすべてが[中央]に依存している、問題がある場合は、サービスセンターは、状態認識サービスは、このような現象に敏感ではなく、システム全体への広がりがあるでしょう。そのため、サービスの発見のための重要なレジストリの可用性を確保します。レジストリの可用性を確保するために、マルチノード展開を確実にするために、背景は通常、レジストリはまだシングルルームの場合にサービスを提供できることを保証するために、複数の部屋全体に展開することが大規模なサイトである場合は使用できません。高可用性とサービス・センターは、次の機能を持っている必要があります特徴：

これは、マルチノード展開する能力を持っています
ウツボグサ属する能力を持っているし、分散シナリオで調整
ノードの健康状態をチェックする機能は、ノードへのアクセスのタイムアウトが現在のクラスタから削除することができ、あなたは再び現在のクラスタに参加するために、アクセスノードに能力を回復することができます

次のセクションでは、我々はいくつかの一般的なレジストリは、製品として直接使用することができます紹介します。

飼育係

飼育係は、分散データの一貫性ソリューションである厳密なシーケンシャルアクセス制御システムと高可用性と分散協調を提供することを約束されています。

ZooKeeperのは、分散通知との連携、構成管理、ネーミングサービス、プライマリノードの選挙、分散ロック、分散キュー完璧なソリューションを提供します。これは、広くサービス発見のための通知との連携を分散されています。これまでのところ、それは最古のサービス発見フィールド、最も広く使用されている製品があります。

この記事では、などの特定の知識飼育係・コヒーレンシ・プロトコル、データ構造を、導入しない、興味を持っている飼育係の前の記事を読むことができます

飼育係学習シリーズ[A]は、飼育係あなたにいくつかの基本的な概念を教える飼育係飼育係[3]学習シリーズは、クラスタ化されたアーキテクチャ、読み書きと一貫性の原則（ZAB協定）のためのメカニズム

飼育係は、読み取り及び書き込み機構とコヒーレンス・プロトコルは、CPシステムであると判断します。

長所と短所

ZooKeeperの最も広く分散協調構成要素として、利点は多いです。広範な使用はまた、技術的な建築家の選択でのZooKeeperを利用することが容易になり、その最大の利点です。しかし、明らかサービスが飼育係ディスカバリフィールド、選挙での分散強い一貫シーンや分散ロックのためにその主な利点のために最良の選択ではないと述べています。選挙をトリガするため、ネットワーク障害やシステム内の他のノードとの失われた接触のZooKeeperのノードマスターは、クラスタが使用できない場合、これは選挙の時に登録されたサービスシステムの麻痺につながります。

さらに読書アリババなぜZooKeeperのないサービス検出を行いますか？

データの一貫性の要件が非常にリアルタイムの感覚を達成するために要求するだけでなく、困難されていないため、サービスセンターがダウンした（遅延が発生します）、それがより重要なのは、自分自身を癒すことができることです。クライアント側のキャッシュ機能により、飼育係は、キュレーターのZooKeeperは、サービスの分野における適応度の高いを発見したことができますが、これはZooKeeperのネイティブ容量と設計されていません。

etcd

オープンソースコミュニティでますます熱いCoreOSとKubernetes他のプロジェクトでは、高可用性、サービスの発見の強力な倉庫の一貫として使用されているetcdプロジェクトコンポーネントは、開発者のビジョンに入ります。

飼育係が触発されたプロジェクトで、etcd と同様の構造と機能を持っているより簡単いかだベースのプロトコルおよび言語の行くを達成するために。etcdまた、CPシステムは、一貫性、可用性の要件よりも強く求められています。etcd TTL（時間にライブ、生存時間）で、同様の機能飼育係の一時的なノードを実現するために、クライアントの必要性がetcd連続サービスのタイミング更新ノードの動作状態を決定します。

特定の拡張子は、次の記事を読むことができます。

また、読み取りetcd：シナリオからラウンド読書はの原則を実装します

公式サイト：etcd.io/

そして、記事の解釈の原則を実装etcd高品質をご紹介：分散ストレージetcdの利用可能性の原則を

飼育係を比較すると、etcdは、次のような利点があります。

シンプル。ゴー言語の使用デプロイを簡単に、インタフェースとして使用するHTTP 使いやすいように、そのユーザが容易に理解できるように、使用筏アルゴリズムは、強い一貫性を保証。
データの永続性。etcd持続性のデフォルトのデータに更新。
セキュリティ。etcdサポートSSLクライアントセキュリティ認証。

ユーレカ

ユーレカは、主に中間層のAWSサービスドメインを位置決めするため、ネットフリックスを開きます。ユーレカは、登録センター春の雲として使用するため、多くの注目を受けているので。サーバーとクライアントの両方のコンポーネントによってユーレカ。ユーレカは、一般的に簡略化され、サーバーと対話するためのサーバーのサービス登録サーバ、ユーレカクライアントとして使用され、ロードバランサとしてポーリングサービスのフェイルオーバーのサポートを提供します。

CPシステムの種類よりもユーレカのZooKeeperは、レジストリサービス発見システムとしてより適しています。可用性を確保するユーレカの優先順位は、それは設計思想に分散化を使用して、全体のサービスクラスタは、ZooKeeperのようマスタノードとピアノード、無選挙から成ります。ノードのクラスタノードの障害は、通常の外部サービスの登録サービスとクエリ機能には影響を与えません。ユーレカクライアントは、我々はユーレカサーバにサービスを登録するときに、接続が失敗した見つけた場合、それは自動的に他のノードに切り替わり、フェイルオーバーする能力を持っています。サーバ・ノードがある場合はそのため、ユーレカも正常に動作することができ、あなたは、レジストリの利用可能性を心配する必要はありません。しかし、必然的に情報へのクライアントクエリの損失につながるデータ可用性の一貫性を確保することは、必ずしも最新ではありません。

ユーレカ2.Xもはや維持が、その現在の関数を使用して、アップグレードしない場合でも、非常に安定している、これらの機能のサービスレジストリ/発見は十分にされていることを発表してきたが

領事

HashiCorp製品から領事、を含む、いくつかの列のプロパティを提供し、サービス発見、より広範なヘルスチェック（メモリ、ディスク使用量、およびその他のきめ細かいサービス状態検出機能）、キーと値のペアのストレージ機能、および複数のデータセンターに説明（公式サイト4つの主要な機能）。そして、「ワンストップ」の機能と比較して、他のプログラム。

領事は、囲碁の言語を使用し、そのため（Linuxでは、WindowsとMac OS Xのサポート）自然な可搬性があり、パッケージはシームレスに適合することができドッカーと他の軽量コンテナと展開を容易にするために実行可能ファイルが含まれています。

そして、複数のノードの半分以上のためのコールが登録の成功に基づいて書かれているように、領事いかだ契約は、再選挙の際に領事を通じて成功したリーダーハングと考えられていたetcdすることはできません。使いやすさを犠牲に強い整合性を確認してください。

著者は領事上の多くの研究はありませんが、興味のある読者は自分自身の学習に関連するドキュメントにアクセスすることができます。

公式サイト：www.consul.io/

ナコス

ナコスは国内アリババの新しいオープンソースプロジェクトである、コア位置は、「ヘルプのビルドに簡単に動的なサービス検出、設定、およびサービス管理プラットフォームのクラウドネイティブアプリケーション」です。（人気の理解、レジストリの設定+センター）

サービス（サービス）は、第一級市民ナコスの世界です。ナコスは、「サービス」の発見、構成および管理のほぼすべての主要なタイプをサポートしています。

Kubernetesサービス
gRPC＆ダボRPCサービス
春クラウドRESTfulなサービス

ナコスの主な機能は次のとおりです。

サービス検出および健康監視サービス
ダイナミック・コンフィギュレーション・サービス
ダイナミックDNSサービス
サービスとメタデータの管理

より多くのコンテンツ、ナコスは公式文書を拡張お読みください。

また、読み取りnacos.io/zh-cn/docs / ...

概要

この章では、あなたを刺激することを望んで、現在市場より人気のサービスレジストリに関連する知識発見サービス、および関連するプロパティのいくつかを説明します。

私たちの次の問題が再びになります。

参考記事

賞賛を見つけることを期待して、あなたにこの記事は参考になりました場合は、これは私にとって最大の駆動力です。