19

最近、いくつかのサービス検出ツールが人気/「主流」になりました。私は、従来のロード バランサの代わりにどのような主なユース ケースでそれらを採用すべきか疑問に思っています。

LB を使用すると、バランサーの背後に多数のノードをクラスター化してから、クライアントがバランサーにリクエストを送信し、バランサーが (通常) それらのリクエストをクラスター内のすべてのノードにラウンド ロビンします。

サービス ディスカバリ ( Consul、ZKなど) を使用すると、集中型の「コンセンサス」サービスが特定のサービスのどのノードが正常であるかを判断し、サービスが正常であると判断したノードにアプリが接続します。したがって、サービス ディスカバリと負荷分散は 2 つの別個の概念ですが、サービス ディスカバリは便利な副作用として負荷分散を提供します。

しかし、ロード バランサー ( HAProxyやnginxなど) にモニタリングとヘルス チェックが組み込まれている場合は、ロード バランシングの副作用としてサービス ディスカバリーを取得できます。つまり、私の LB がそのクラスター内の異常なノードにリクエストを転送しないことを知っている場合、それはコンセンサス サーバーが私のアプリに異常なノードに接続しないように指示するのと機能的に同等です。

したがって、私にとって、サービス検出ツールは、ロード バランサーと同等の「1 つに 6 つ、もう 1 つに 6 つ」のように感じられます。ここで何か不足していますか？負荷分散されたマイクロサービスに完全に基づいたアプリケーション アーキテクチャを使用している場合、サービス ディスカバリ ベースのモデルに切り替えることの利点 (または利点) は何ですか?

4

3 に答える 3

19

通常、ロード バランサーには、トラフィックの負荷を分散するリソースのエンドポイントが必要です。マイクロサービスとコンテナー ベースのアプリケーションの成長に伴い、ランタイムで作成された動的コンテナー (Docker コンテナー) は一時的なものであり、静的なエンドポイントはありません。これらのコンテナー エンドポイントは一時的なものであり、スケーリングやその他の理由で削除および作成されると変化します。Consul などのサービス検出ツールは、動的に作成されたコンテナー (Docker コンテナー) のエンドポイント情報を格納するために使用されます。コンテナ ホストで実行される consul-registrator などのツールは、consul などのサービス検出ツールにコンテナ エンドポイントを登録します。Consul-template のようなツールは、consul のコンテナー エンドポイントへの変更をリッスンし、トラフィックを送信するためのロード バランサー (nginx) を更新します。

フォローアップ: エフェメラル ノード (出入りし、生きて死ぬノード) と従来の VM のような「永続的な」ノードの利点は何ですか?

[DDG]: すぐに思いつくこと: Docker コンテナのようなエフェメラル ノードは、API などのステートレス サービスに適しています (外部ボリューム (ボリューム ドライバなど) を使用する永続コンテナには牽引力があります)。

  1. 速度: 一時的なコンテナー (イメージからの Docker コンテナー) の起動または破棄にかかる時間は、従来の VM の起動に数分かかるのに対し、500 ミリ秒未満です。

  2. エラスティック インフラストラクチャ: クラウドの時代には、ユーザーの要求に応じてスケールアウトおよびスケールインしたいと考えています。これは、本質的に一時的なコンテナーが存在することを意味します (IP を保持できないなど)。トラフィック TPS が 200% 増加すると予想される 1 週間のマーケティング キャンペーンを考えてみてください。コンテナーですばやくスケーリングし、キャンペーンを投稿して破棄します。

  3. リソースの使用率: データ センターまたはクラウドは現在、1 つの大きなコンピューター (コンピューティング クラスター) であり、コンテナーはリソースの使用率を最大化するためにコンピューティング クラスターをパックし、需要が低い場合は請求額/リソースの使用率を下げるためにインフラストラクチャを破壊します。

これの多くは、一時的なコンテナーとの結合が失われ、consul などのサービス検出ツールを使用してランタイム検出が行われるために可能になります。従来の VM と IP のタイト バインディングは、この機能を抑圧する可能性があります。

于 2015-09-03T18:25:40.393 に答える