領事の基礎的な理論的知識

Consul は HashiCorp によって発売されたオープン ソース ソフトウェアです。GO 言語で書かれており、サービスの登録と検出、構成、および複数のデータ センター向けの高可用性ソリューションなどの機能を提供します。分散整合性は raft アルゴリズムを使用して実装されており、 Spring Cloud などのマイクロサービスと簡単に統合でき、フレーム統合は非常に使いやすく、シンプルさ、使いやすさ、プラグイン可能性の特徴を備えています。つまり、Consul は完全なサービス メッシュ ソリューションを提供します

領事機能

●サービス検出: Consul クライアントは、API サービスや mysql サービスなどのサービスを Consul に登録でき、他のクライアントは Consul を使用してサービス プロバイダーを検出できます。Consul は、DNS または HTTP を使用したサービスの登録と検出をサポートしています。
● ランタイム ヘルス チェック: Consul クライアントは、特定のサービス (「Web サーバーが 200 OK を返しているか」) またはノードに対してローカル (「メモリ使用率が 90% 未満」) に関連付けられたヘルス チェック メカニズムを、任意の数で提供できます。この情報はクラスターの健全性を監視するために使用でき、サービス検出コンポーネントはこの監視情報を使用して、トラフィックを異常なサービスから遠ざけることができます。
KV ストレージ: アプリケーションは、動的構成、機能のマーキング、調整、リーダーの選出など、あらゆるニーズに合わせて Consul のキー/値ストアを使用できます。HTTP APIを採用し、使いやすくなりました。
● 安全なサービス通信: Consul は、相互 TLS 接続を確立するためにサービスの TLS 証明書を生成および配布できます。
●複数のデータセンター: Consul は複数のデータセンターをサポートします。これは、Consul のユーザーが、複数の領域に拡張するために追加の抽象化レイヤーを構築することを心配する必要がないことを意味します。

領事の一般的な執行プロセスと原則

サービスを提供する各ノードは Consul エージェントを実行します。エージェントの実行には、サービスの検出や、設定された KV キーと値のペアの取得は必要ありません。エージェントは監視と確認のみを行います。エージェント ノードは 1 つ以上の Consul サーバーと通信できます。Consul サーバーは、データが保存および複製される場所です。サーバー自体がリーダーを選出します。Consul は 1 台のサーバーで実行できますが、データ損失につながる障害シナリオを避けるために 3 ～ 5 台のサーバーで実行することをお勧めします。データセンターごとに一連の Consul サーバーを使用することをお勧めします。

コンポーネントがサービスを検出する必要がある場合、コンポーネントは任意の Consul Server または任意の Consul クライアントにクエリを実行でき、Consul クライアントはそのクエリを Consul Server に自動的に転送します。

他のサービスまたはノードを検出する必要があるインフラストラクチャ コンポーネントは、任意の Consul サーバーまたは任意の Consul エージェントにクエリを実行できます。プロキシはクエリをサーバーに自動的に転送します。各データセンターは Consul サーバーのクラスターを実行します。データセンター間のサービス検出または構成リクエストが発生すると、ローカル Consul サーバーはリクエストをリモート データセンターに転送し、結果を返します。

用語

✓エージェント エージェント: Consul クラスターの各メンバーで常に実行されるデーモン プロセスです。まずは consul エージェントを実行します。エージェントはクライアント モードまたはサーバー モードで実行できます。他のエージェント インスタンスがない限り、ノードをクライアントまたはサーバーとして指定することは非常に簡単です。すべてのエージェントは DNS または HTTP インターフェイスを実行でき、実行時のチェックとサービスの同期の維持を担当します。

✓クライアント クライアントは、すべての RPC をサーバーに転送するプロキシです。このクライアントは比較的ステートレスです。クライアントによって実行される唯一のバックグラウンド アクティビティは、LAN ゴシップ プールに参加することです。これにより、リソースのオーバーヘッドが最小限に抑えられ、ネットワーク帯域幅の消費も少量のみになります。

✓サーバー: サーバーは、拡張された一連の機能を持つエージェントです。これらの機能には、Raft 選挙への参加、クラスター ステータスの維持、RPC クエリへの応答、WAN ゴシップでの他のデータ センターとの対話、リーダーまたはリモート データ センターへのクエリの転送などが含まれます。 。

✓データセンター データセンターの定義は明らかですが、考慮する必要がある微妙な詳細がいくつかあります。たとえば、EC2 では、複数のアベイラビリティーゾーンがデータセンターを構成すると考えられますか? 私たちはデータセンターを、プライベートで低遅延、高帯域幅のネットワーク環境として定義します。これにはパブリック ネットワークへのアクセスは含まれませんが、この目的では、同じ EC2 内の複数のアベイラビリティ ゾーンは 1 つのデータセンターの一部とみなすことができます。

✓コンセンサス: 私たちのドキュメントでは、リーダーの選出とトランザクションの順序に関する合意を示すためにコンセンサスを使用します。これらのトランザクションは有限状態マシンに適用されるため、コンセンサスは複製された状態マシンの一貫性を意味します。

✓Gossip: Consul は Serf 上に構築されており、マルチキャスト目的の完全なゴシップ プロトコルを提供します。Serf は、メンバーシップ、障害検出、イベント ブロードキャストを提供します。詳細については、ゴシップドキュメントで説明されています。ゴシップが UDP に基づいたランダムなポイントツーポイント通信を使用していることを知るには、これで十分です。

✓LAN ゴシップ 同じ LAN またはデータセンターにあるすべてのノードが含まれます。

✓WAN ゴシップ: サーバーのみが含まれます。これらのサーバーは主にさまざまなデータ センターに分散されており、通常はインターネットまたは WAN を通じて通信します。RPC リモート プロシージャ コール。これは、クライアントがサーバーに要求できるようにする要求/応答メカニズムです。
この図を分解して各部分を説明してみましょう。まず、「1」と「2」というラベルが付いた 2 つのデータ センターがあることがわかります。Consul は複数のデータセンターに対する第一級のサポートを提供しており、これが一般的なシナリオであると予想しています。

各データセンターにはクライアントとサーバーが混在しています。通常は 3 ～ 5 台のサーバーを使用することをお勧めします。これは、参加するマシンが増えるほどコンセンサスが遅くなるため、障害が発生した場合の可用性とパフォーマンスの間のトレードオフに基づいています。ただし、クライアントの数に制限はなく、数千、数万まで簡単に拡張できます。

同じデータセンター内のすべてのノードはゴシップ プロトコルに参加する必要があります。これは、ゴシップ プロトコルが特定のデータ センター内のすべてのノードをカバーすることを意味します。これにはいくつかの目的があります。 まず、クライアントでサーバー アドレスを設定する必要がありません。検出はすべて自動的に行われます。2 番目に、ノード障害の検出作業はサーバーに配置されず、分散されます。この障害検出は、ハートビート機構よりも拡張性が高くなります。3 番目: リーダー選出の発生時などのイベントを通知するためのメッセージング レイヤーとして使用されます。

各データセンターのサーバーは、Raft ノードのコレクションの一部です。これは、彼らが協力してリーダー、つまり追加の仕事を担うサーバーを選出することを意味します。リーダーは、すべてのクエリとトランザクションの処理を担当します。整合性プロトコルの一部として、トランザクションは他のすべてのノードにも複製される必要があります。この要件のため、非リーダー サーバーは RPC 要求を受信すると、その要求をクラスター リーダーに転送します。

サーバー ノードは WAN ゴシップ プールの一部でもあります。このプールは、インターネットの高い遅延を最適化するように設計されており、他の Consul サーバー ノードのみを含むという点で LAN プールとは異なります。このプールの目的は、データセンターがロータッチ方式で相互に検出できるようにすることです。これにより、新しいデータセンターが既存の WAN ゴシップに簡単に参加できるようになります。すべてのサーバーはこのプール内で実行されるため、データセンター間のリクエストもサポートされます。サーバーは、別のデータセンターからリクエストを受信すると、そのリクエストを正しいデータとともにサーバーに転送します。その後、サーバーはそれをローカル リーダーに転送します。

その結果、データ センター間の結合は低くなりますが、障害検出、接続のキャッシュ、再利用により、データ センター間のリクエストは比較的高速で信頼性が高くなります。

サービスの検出とガバナンス

●サービス登録

✓Producerサービスが開始されると、Consulにリクエストを送信して自身の情報(IPとPort)を通知し、ConsulはサービスのProducer情報を保存します
✓登録方法

1. HTTP API (ポート 8500)
2. 設定ファイル

●サービスディスカバリ
✓ Consul は、Producer の登録情報を受信後、Producer に定期的にヘルスチェックリクエストを送信し、Producer が健康であるかどうかを確認します。
●サービスコール✓
Consumer が Product をリクエストすると、まず Consul から一時テーブルを取得し、その一時テーブルからProducer 情報（IP と Port）を選択し、その IP と Port に基づいてアクセスリクエストを送信します。

✓ 温度テーブル

1. ヘルスチェックに合格したプロデューサー情報のみが含まれます
   1. IPやポートなどの情報
2. 随時更新していきます

領事ノードの対話プロセス

1. リーダーの選出: Consul Server はそれぞれサーバー Server1、Server2、および Server3 にデプロイされ、Consule クラスターを形成します。raft 選出アルゴリズムを通じて、server2 がリーダー ノードになります。
2. サーバーは、Consul Client を呼び出して登録します: サーバー Server4 と Server5 は、Consul Client を通じてサービス A、B、および C をそれぞれ登録します
3. サーバー ノード情報の同期:

1. Consul Client は、RPC を通じて登録情報を Consul Server に転送します。
2. 情報はサーバーの各ノードに保存され、Raft を通じて強力な一貫性が実現されます。

4. サービス呼び出し: サーバー Server6 のプログラム D がサービス B にアクセスしようとしています
。 4.1HTTP API メソッド:

1. プログラム D は、まずローカル Consul クライアントによって提供される HTTP API にアクセスします。
2. Consul Client はリクエストを Consul Server に転送します。
3. Consul Server はサービス B にクエリを実行し、それをプログラム D に返します。
4. プログラム D は、サービス B のデプロイされたすべての IP とポートを取得します。負荷分散ポリシーに従って、サービス B の 1 つを選択し、それに対するリクエストを開始します。

基本的な理論的知識プロトコルは、Gossip プロトコルと Raft プロトコルに基づいています

Consul の分散型アイデアの実装:
✓consul は Serf に基づいて実装されます。
✓Consulはserfが提供するゴシッププロトコルを使用してメンバーを管理し、クラスターにメッセージをブロードキャストします。

農奴

1. ゴシッププロトコルに基づいて実装
2. Serf は、分散型のサービス検出およびオーケストレーション ツールであり、集中型構造のような統一された配布と管理を提供しません。
3. Serf は、メンバーシップ、エラー チェック、ブロードキャスト、その他の機能を提供します。

領事の噂話

1. Consul は、ゴシップ プロトコルを使用してメンバーとクラスターのブロードキャスト メッセージを管理します。これはすべて Serf ライブラリを使用することによって行われます。
2. Serf が使用するゴシップ プロトコルは、SWIM (Scalable Weakly Consistent Infection Mode Process Group Membership Protocol) に基づいており、若干の変更が加えられています。
3. Consul は 2 つの異なるゴシップ プールを使用します。LANプール、WANプールと呼ばれます。

●LANプール

1. Consul の各データ センターには LAN プールがあり、クライアントやサーバーを含むデータ センターのすべてのメンバーが含まれています。
2. LAN プールは、次のようないくつかの目的に使用されます。
   1. メンバーシップ情報により、クライアントはサーバーを自動的に検出できるため、必要な構成の量が削減されます。
   2. 分散型障害検出メカニズムにより、障害検出を少数のマシンに集中させるのではなく、クラスター全体で実行できるようになります。
   3. ゴシップ プールにより、リーダー選挙などのイベントが確実かつ迅速に行われます。

●WANプール

1. WAN プールはグローバルに一意であるため、サーバーがどのデータセンターにあるかに関係なく、すべてのサーバーが WAN プール内に存在する必要があります。
   1. WAN プールにより、データセンター間でのサーバー リクエストが可能になります
   2. 統合された障害検出機能により、Consul はデータセンター全体または個々のデータセンター内の単一サーバーへの接続の喪失を適切に処理できます。
2. これらの機能は Serf によって提供されるため、ユーザーはそれらを認識する必要はありません。

領事館のいかだ

用語

●ピアセット（ピアセット）

1. ログ レプリケーションに参加しているすべてのメンバーのセットです
2. Consul では、すべてのサーバー ノードがローカル データ センターのピア セットに配置されます。

● 7.1.2、クォーラム（定足数）

1. クォーラムはピアセットの主要メンバーです
2. サイズ n のコレクションの場合、クォーラムには少なくとも (n/2)+1 メンバーが必要です。

●7.1.3、FSM

1. 有限状態マシン。
2. FSM は、有限状態とそれらの間の遷移の集合です。新しいログを適用するときに、FSM が状態間を遷移できるようにします。同じログシーケンスのアプリケーションは同じ状態になる必要があり、これは動作が決定的である必要があることを意味します。

●7.1.4、ログエントリ

1. Raft システムの主な作業単位
2. 一貫性の問題は、ログのバックアップに分類できます。
3. log は、順序付けられた一連のエントリです。すべてのメンバーがエントリの内容と順序に同意した場合、ログは一貫していると見なされます。

● 7.1.5、コミットされたエントリ

1. エントリがノードのクォーラムに永続的に保存されると、エントリはコミットされたとみなされます。エントリーを送信すると、使用できるようになります。

● 7.1.6、リーダー

1. いつでも、ピア セットはノードをリーダーとして選択します。
2. リーダーは、新しいログ エントリを取得し、それをフォロワーにコピーする責任があります。

領事館のいかだ

✓. Consul のサーバー ノードのみが Raft アルゴリズムに参加し、ピア セットの一部になります。すべてのクライアント ノードはリクエストをサーバー ノードに転送します。この設計の理由としては次のようなものがあります。

1. ピア セットに追加されるメンバーが増えると、クォーラムのサイズが増加します。これにより、少数のマシンを待つのではなく、数百のマシンがエントリに同意するまで待つ必要があるため、パフォーマンスの問題が発生します。

2. 起動時の単一 Consul サーバーのモードはブートストラップです。

   1. このモードでは、ノードが自らをリーダーとして選出することができます。リーダーの選出が成功すると、一貫性とセキュリティを維持する方法で他のサーバーをピア セットに追加できます。
   2. いくつかのサーバーを追加したら、ブートストラップ モードを無効にします。

✓. すべてのサーバーはピア セット内にあるため、現在のリーダーが誰であるかをすべて知っています。RPC が非リーダー サーバーに到着すると、要求はリーダーに転送されます。PRC が読み取り専用リクエストの場合、リーダーは FSM の現在の状態に基づいて結果を生成します。RPC が状態変更要求である場合、リーダーは新しいログ エントリを生成し、それに Raft アルゴリズムを適用します。ログ エントリがコミットされて FSM に適用されると、変換リクエストは完了します。

✓. Raft のバックアップ機能により、そのパフォーマンスはネットワーク遅延の影響を非常に受けやすくなります。このため、各データセンターは独立したリーダーを選出し、独自の互いに素なピアのセットを維持します。データはデータセンターごとに分割されるため、各リーダーは自分のデータセンターでのデータの処理のみを担当します。リクエストがリモート データセンターで受信されると、そのリクエストは適切なリーダーに転送されます。

1. この設計により、一貫性を犠牲にすることなく、低レイテンシーのトランザクションと高可用性が可能になります。

●クォーラム ノードが有効である限り、Consensus はフォールト トレラントです。有効なノードの数がクォーラムに達しない場合、ログ エントリを処理したり、メンバーシップ関係を維持したりすることはできません。たとえば、ピアが A と B の 2 つだけであると仮定します。クォーラムも 2 です。これは、2 つのノードがログ エントリをコミットすることに同意する必要があることを意味します。A または B のいずれかが失敗すると、クォーラム ノードが有効であるという条件を満たすことができなくなります。これは、クラスターがノードを追加または削除したり、追加のログ エントリを送信したりできないことを意味します。その結果、クラスターは使用できなくなります。この時点で、A または B を削除し、残りのノードをブート モードで再起動するには、手動介入が必要です。

エウレカと比較

Eureka はサービス検出ツールです。アーキテクチャは主にクライアント/サーバーであり、データセンターごとに一連の Eureka サーバー (通常は可用性ゾーンごとに 1 台) を備えます。通常、Eureka のクライアントは組み込み SDK を使用してサービスの登録と検出を行います。ネイティブに統合されていないクライアントの場合は、リボンなどのサイドカーを使用して、Eureka を通じてサービスを透過的に検出します。

Eureka はベストエフォート型のレプリケーションを使用して、サービスの弱一貫性のあるビューを提供します。クライアントがサーバーに登録すると、サーバーは他のサーバーへの複製を試みますが、保証はありません。サービス登録の有効期間 (TTL) は非常に短いため、クライアントはサーバー上でハートビート検出を実行する必要があります。異常なサービスまたはノードはハートビートを停止し、タイムアウトになり、レジストリから削除されます。検出リクエストは、ベストエフォート型レプリケーションにより、古いデータまたは欠落しているデータを提供できる任意のサービスにルーティングできます。この簡素化されたモデルにより、簡単なクラスター管理と高い拡張性が可能になります。

Consul は、より充実したヘルスチェック、キー/値ストレージ、マルチデータセンター認識などの優れた機能を多数提供します。Consul では、リボンのようなサイドカーを使用する場合と同様に、各データ センターに一連のサーバーが必要で、各クライアントにプロキシが必要です。Consul プロキシを使用すると、ほとんどのアプリケーションが Consul を認識せず、構成ファイルを介してサービス登録を実行し、DNS またはロード バランサー サイドカーを介して検出を実行できます。

Consul は、サーバーが Raft プロトコルを使用して状態を複製するため、強力な一貫性を保証します。Consul は、TCP、HTTP、Nagios/Sensu 互換スクリプト、または Ture ベースの Eureka を含む豊富なヘルスチェックをサポートしています。クライアント ノードはゴシップ ベースのヘルス チェックに参加します。これは、スケーラビリティの課題となる集中型のハートビートとは異なり、ヘルス チェックの作業を分散します。検出リクエストは選出された領事リーダーにルーティングされるため、デフォルトで強力な一貫性が保たれます。古い読み取りを許可するクライアントでは、任意のサーバーがリクエストを処理できるため、Eureka のような線形スケーラビリティが可能になります。

Consul の強力な一貫性は、リーダーの選出とクラスターの調整のためのロック サービスとして使用できることを意味します。Eureka は同様の保証を提供しておらず、通常、調整を実行する必要があるサービスやより強力な一貫性要件があるサービスに対して ZooKeeper を実行する必要があります。

Consul は、サービス指向アーキテクチャをサポートするために必要な機能のツールキットを提供します。これにはサービス ディスカバリが含まれますが、豊富なヘルス チェック、ロック、キー/値、マルチ データセンター フェデレーション、イベント システム、ACL も含まれます。Consul および consul-template や envconsul などのエコシステム ツールはすべて、SDK を介したネイティブ統合の必要性を回避するために、統合に必要なアプリケーションの変更を最小限に抑えようとします。Eureka は、より大規模な Netflix OSS スイートの一部であり、アプリケーションが比較的均一で緊密に統合されることが期待されています。したがって、Eureka は問題の限られた部分のみを解決し、ZooKeeper などの他のツールを同時に使用できることが期待されます。
上記の段落を要約すると、次のようになります。

●Consul は Raft プロトコルを通じて強い一貫性を提供しますが、Eureka は弱い一貫性を提供します。
●Consul は、Eureka の集中型ハートビート (クライアントが常にサーバーを要求する必要がある) ではなく、Gossip プロトコルを介してヘルスチェック作業をより適切に分散します。 ● Raft によって提供される強力な一貫性により、Consul はリーダーの選択とクラスター プロトコルのロック サービスに使用できます
。 、エウレカが頼れるのは動物園の飼育員だけです。