分散システムサービスの登録と検出の原理を徹底的に理解するための13枚の写真

[[349916]]

この記事はWeChatの公開アカウント「笑い好きの建築家」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、笑いが大好きな建築家の公開アカウントまでご連絡ください。

マイクロサービス アーキテクチャや分散環境では、サービス登録および検出テクノロジが不可欠です。これは、プログラマーが昇進の過程で習得しなければならないコアテクノロジーの 1 つでもあります。この記事では、簡単に習得できるようにグラフィックイラストを使用しています。

サービス登録および検出コンポーネントを導入する理由

まず質問を見てみましょう。今からショッピングモールのプロジェクトを実施する場合、建築家としてシステムアーキテクチャをどのように設計すればよいでしょうか?あなたはこう思っているに違いありません。「これは簡単ではない、Taobao のアーキテクチャをコピーするだけではだめなのだろうか?」しかし、実際の起業環境では、プロジェクトは生死を賭けた戦いになる場合があります。最初に膨大な人的資源と資金を投資すると、プロジェクトが失敗した場合の損失は莫大なものになります。

経験豊富なアーキテクトとして、企業の財務資源、人材投資予算などに基づいて、現状に最も適したアーキテクチャを選択することが最善です。大規模な Web サイトはすべて小規模な Web サイトから進化しており、アーキテクチャについても同様です。

大規模な Web サイトのアーキテクチャは最初から静的なものではなく、ユーザー数とデータ数の増加に伴って継続的に反復および進化した結果です。

アーキテクチャの継続的な反復と進化の過程では、多くの問題に遭遇することになります。技術開発の本質は、常に問題を発見して解決し、問題を解決して新たな問題を発見することです。

モノリシックアーキテクチャ

システムが最初に構築されたときは、ユーザー数は多くない可能性があります。すべてのビジネスはアプリケーション パッケージにパッケージ化され、データベースとサーバーを共有しながら Tomcat コンテナーで実行されます。このアーキテクチャは一般にモノリシック アーキテクチャと呼ばれます。

モノリシックアーキテクチャ - アプリケーションとデータベースが一緒に展開される

初期段階では、このアーキテクチャは非常に効率的であり、ユーザーからのフィードバックに基づいて迅速に反復して起動できます。しかし、ユーザー数が増えると、サービスのメモリと CPU が逼迫し、ボトルネックが発生しやすくなります。新たな問題をどうやって解決するか？

アプリケーションとデータの分離

ユーザーリクエストの数が増えると、サーバーのメモリと CPU の使用量が急増し、ユーザーリクエストへの応答時間が遅くなります。このとき、アプリケーションとデータベースを分離し、それぞれサーバーを使用することを検討できます。ご覧の通り、問題は解決しました。

モノリシックアーキテクチャ - アプリケーションとデータベースの分離

ある日突然、掃除婦が誤って電線に触れ、サーバーの 1 つに電源が入らなくなってしまいました。すべてのユーザーリクエストでエラーが報告され、その後に一連の苦情の電話が続きました。

クラスターの展開

単一のインスタンスは、サーバー障害やサービス容量のボトルネックなど、単一の問題ポイントを簡単に引き起こす可能性があります。何をすべきでしょうか?賢い人なら、クラスターを使うことを考えたはずです。

アプリケーション クラスタの展開

クラスター展開とは、アプリケーションを複数のサーバーまたは仮想マシンに展開することを意味します。ユーザーはサービス バランシングを通じてインスタンスの 1 つにランダムにアクセスし、複数のインスタンスのトラフィックのバランスをとります。インスタンスに障害が発生した場合、そのインスタンスはオフラインにすることができ、他のインスタンスは影響を受けず、外部にサービスを提供し続けることができます。

ユーザー数が急増したため、上司は投資を増やしてチームを拡大することを決定しました。開発チームが拡大した後も、効率は大幅に向上していません。以前は、小規模なチームで週に 1 回繰り返して新製品をリリースできましたが、現在は少なくとも 2 ～ 3 週間かかります。

ビジネス ロジックはますます複雑になり、コード間の結合が非常に深刻になっています。 1 行のコードを変更すると、オンラインで複数の問題が発生する可能性があります。建築家は、アーキテクチャのリファクタリングが必要であることを認識しました。

マイクロサービスアーキテクチャ

モノリシック アーキテクチャが特定の段階に進むと、開発とテストの複雑さによってコストが増加します。チーム規模の拡大により、各作業の連携もより一層深まることになります。これは、1 つの動きが体全体に影響を及ぼすシナリオです。

モノリシック アーキテクチャがボトルネックに遭遇したとき、マイクロサービス アーキテクチャが誕生しました。マイクロサービスは、ビジネスの側面に応じて、従来のモノリシック サービスを分割します。分割の粒度は大きくも小さくもでき、分割のタイミングもリズムに合わせて行うことができます。ベストプラクティスは、まずモノリスからいくつかの独立した機能を分離し、それらを 1 つ以上のマイクロサービスに抽出して、ビジネスの継続性と安定性を確保することです。

マイクロサービスアーキテクチャ

上の図に示すように、商用アプリケーションは 6 つの独立したマイクロサービスに分割されています。 6 つのマイクロサービスは、Docker コンテナ化を使用して複数のインスタンスにデプロイできます。

ここで、アーキテクチャの進化に問題が発生しました。すべてのユーザーの注文を照会する場合、ユーザー サービスは注文サービスに依存する可能性があります。ユーザー サービスは注文サービスとどのように対話しますか?注文サービスのインスタンスが複数ある場合、どれにアクセスすればよいですか?

通常、解決策はいくつかあります。

（１）サービスアドレスのハードコーディング

サービス アドレスはデータベースまたは構成ファイルにハードコードされており、アドレス指定とルーティングは DNS ドメイン名にアクセスすることによって実行されます。

サービスメタデータがハードコードされている

サービス B のアドレスは、データベースまたは構成ファイルにハードコードされています。サービス A は、まずサービス B のアドレスを取得し、次に DNS サーバー解決を通じてインスタンスの 1 つの実際のアドレスを取得し、最後にサービス B への要求を開始する必要があります。

大規模なプロモーションのためにサービス インスタンスを拡張する必要がある場合は、プロモーション後にそのインスタンスをオフラインにする必要があります。運用および保守担当者は多くの手作業を行う必要があり、エラーが発生しやすくなります。

（２）動的なサービス登録と発見

サービス アドレスをハードコーディングすると、別の致命的な問題が発生します。インスタンスがクラッシュした場合、運用・保守担当者がそれを時間内に検出できず、一部のユーザーのリクエストが異常になる可能性があります。

サービス登録および検出コンポーネントを導入すると、上記の問題を効果的に解決し、過度の手動操作を回避できます。

アーキテクチャの進化の概要

モノリシック アーキテクチャでは、アプリケーションはサービス パッケージです。パッケージ内のモジュールは関数メソッドを通じて相互に呼び出します。モデルは非常にシンプルで、サービスの登録や検出はまったくありません。

マイクロサービス アーキテクチャでは、アプリケーションは複数のマイクロサービスに分割されます。マイクロサービスは、異なるサーバー、異なるコンテナ、さらには複数のデータセンターにデプロイされます。マイクロサービスは相互に呼び出す必要があり、サービスの登録と検出は不可欠なコンポーネントになります。

サービス登録と検出の基本原則

サービスの登録と検出は、登録と検出という 2 つの主要なステップに分かれています。

サービス登録: サービス プロセスは、メタデータ情報を登録センターに登録します。通常はホストとポート番号が含まれますが、認証情報、プロトコル、バージョン番号、実行環境に関する情報が含まれる場合もあります。

サービス検出: クライアント サービス プロセスは、登録センターへのクエリを開始してサービス情報を取得します。サービス検出の重要な役割は、利用可能なサービスのリストをクライアントに提供することです。

サービス登録

サービス登録には、クライアント登録とプロキシ登録の 2 つの形式があります。

クライアント登録

クライアント登録は、登録と登録解除を行うサービス自体の仕事です。サービスが開始されると、登録スレッドは登録センターに登録し、サービスがオフラインになると登録を解除します。

クライアント登録

このアプローチの欠点は、登録および登録解除ロジックがサービスのビジネス ロジックと結合されることです。サービスが異なる言語で開発されている場合は、複数のサービス登録ロジック セットを調整する必要があります。

エージェント登録

プロキシ登録は別のプロキシサービスによって処理されます。サービス プロバイダーが起動されると、何らかの方法でプロキシ サービスに通知され、プロキシ サービスは登録センターへの登録を開始する責任を負います。

エージェント登録

この方法の欠点は、追加のプロキシ サービスを参照するため、プロキシ サービスの可用性を高く維持する必要があることです。

サービス検出

サービス検出は、クライアント検出とプロキシ検出にも分けられます。

クライアントの発見

クライアント検出とは、利用可能なサービス アドレスについて登録センターに問い合わせる責任がクライアントにあることを意味します。利用可能なすべてのインスタンス アドレスのリストを取得した後、クライアントは負荷分散アルゴリズムに基づいてインスタンスを選択し、要求呼び出しを開始します。

クライアントの発見

このアプローチは非常に直接的であり、クライアントは負荷分散アルゴリズムを制御できます。しかし、欠点も明らかです。インスタンス アドレスの取得と負荷分散のロジックは、サービスのビジネス ロジックと結合されます。サービス検出または負荷分散に変更があった場合は、すべてのサービスを変更してオンラインに戻す必要があります。

プロキシ検出

プロキシ検出とは、サービス検出を担当し、利用可能なインスタンスのリストを取得するルーティング サービスを追加することを意味します。サービス コンシューマーがサービス A のインスタンスを呼び出す必要がある場合は、ルーティング サービスにリクエストを直接送信できます。ルーティング サービスは、構成された負荷分散アルゴリズムに基づいて、使用可能なインスタンスのリストからインスタンスを選択し、要求を転送します。インスタンスが使用できないことが判明した場合、ルーティング サービスはサービス コンシューマーに知られることなく独自に再試行できます。

プロキシルーティングサービスの登録

心拍の仕組み

サービスに複数のインスタンスが存在し、そのうちの 1 つがダウンした場合、登録センターはそれをリアルタイムで感知し、リストからインスタンス情報を削除します (オフフックとも呼ばれます)。

オフフックを実現するにはどうすればいいですか?業界で最も一般的な方法はハートビート検出によるもので、アクティブとパッシブの 2 つのモードがあります。

パッシブ検出とは、サービスが登録センターにハートビート メッセージをアクティブに送信することを意味します。時間間隔はカスタマイズ可能で、たとえば 5 秒ごとに 1 回送信するように設定できます。登録センターがインスタンスのハートビート メッセージを 3 サイクル以内 (たとえば 15 秒以内) に受信しない場合、インスタンスはリストから削除されます。

心拍メカニズム - 受動検出

上の図では、サービス A のインスタンス 2 がクラッシュしており、登録センターにハートビート メッセージをアクティブに送信できません。 15 秒後、登録によりインスタンス 2 が削除されます。

アクティブ検出は登録センターによって開始されます。数秒ごとにリスト内のすべてのサービス インスタンスにハートビート検出メッセージを送信します。メッセージが正常に送信されなかったり、複数のサイクル内で応答が受信されなかったりした場合は、インスタンスがアクティブに削除されます。

心拍メカニズム-アクティブ検出

業界で一般的に使用されているサービス登録および検出コンポーネントの比較

サービス登録と検出の基本原則を理解した後、プロジェクトでサービス登録と検出のコンポーネントを使用する場合、多数のオープンソース コンポーネントに直面したときにどのようにテクノロジを選択すればよいでしょうか。

インターネット企業の中でも、研究開発能力が強い大企業は、一般的に自社製品の開発やオープンソースコンポーネントをベースにした二次開発を選択しますが、中小企業にとっては、オープンソースソフトウェアを直接選択するのが良い選択でしょう。

よく使用される登録および検出コンポーネントには、eureka、zookeeper、consul、etcd などがあります。eureka は 2018 年にメンテナンスを中止すると発表されているため、ここでは推奨されなくなりました。

業界のオープンソースコンポーネント

さまざまな寸法と組み合わせてコンポーネントを比較してみましょう。

全体的に、領事の機能はより完全でバランスが取れています。次に、consul を例に挙げて詳しく説明します。

Consul - サービスの登録と検出に推奨されるオープンソースコンポーネント

Consulの簡単な紹介

Consul は、HashiCorp がリリースしたオープンソース ツールです。 Go 言語で開発されており、すぐに簡単に導入できます。 Consul は、分散システム向けの分散型、高可用性、水平スケーラブルなサービス検出および構成フレームワークです。

Consul の利点は何ですか?

• サービスの登録と検出: Consul は、DNS または RESTful インターフェースを通じてサービスを登録および検出する方法を提供します。実際の状況に応じてサービスをお選びいただけます。
• ヘルス チェック: Consul クライアントは、特定のサービスまたはローカル ノードに関連付けられた任意の数のヘルス チェックを提供できます。
• 複数のデータ センター: Consul は複数のデータ センターをサポートしているため、ユーザーは Consul 自体の高可用性の問題や、複数のデータ センターによって生じる拡張アクセスの問題について心配する必要がありません。

Consul アーキテクチャ図

領事建築

• Consul の複数のデータ センターの実装は、ゴシップ プロトコルに依存しています。その目的は次のとおりです。
• クライアントにサーバーのアドレスを設定する必要はありません。サービス検出は自動的に行われます。

ヘルスチェック失敗時の処理はサーバー上に置かれるのではなく、分散されます。

Consulの使用シナリオ

Consul のアプリケーション シナリオには、サービスの登録と検出、サービスの分離、サービスの構成などが含まれます。

サービスの登録および検出シナリオでは、consul が登録センターとして機能します。サービス アドレスが consul に登録されると、consul が提供する dns および http インターフェイスを使用してクエリを実行できるようになります。 consul はヘルスチェックをサポートします。

サービス分離シナリオでは、Consul はサービスごとにアクセス ポリシーを設定すること、従来のプラットフォームと新しいプラットフォームの両方をサポートすること、TLS 証明書の配布、およびサービス間の暗号化をサポートします。

サービス構成シナリオでは、Consul はキー値データ ストレージ機能を提供し、変更を迅速に通知できます。 Consul の助けを借りて、構成の共有を実現し、構成を読み取る必要があるサービスは Consul から正確な構成情報を読み取ることができます。