2

多くのアプリケーションは、回復力のために HTTP 呼び出しと JDBC 呼び出しの両方に接続プールを使用します。ただし、これら 2 種類のプールの使用と構成は大きく異なります。これにより、タイムアウト、再試行、キャッシング/アラート フォールバック、サーキット ブレーカー、監視など、両方に共通する回復力パターンを実装する複雑さが倍増します。

私の考えでは、 Hystrixは、HTTP 呼び出しと JDBC 呼び出しの両方に対して、これらと同じ回復力パターンを構成および実装するための共通のアプローチを提供します。

私の質問は次のとおりです。

  1. Hystrix は、理論的に既存の HTTP および JDBC 接続プールを完全に置き換えることができますか?
  2. もしそうなら、そうすることの長所と短所は何ですか？

それらを完全に置き換えると、これらの接続プールを取り巻く複雑さの世界が軽減されます-付随するタイムアウトや検証クエリプロパティなど.これらのタスクに特化した既存のライブラリに委譲します。

コンテキストとして、JDBC 接続プールに Tomcat DBCP を使用し、HTTP 接続プールに Apache HttpClient を使用する DropWizard アプリがあります。

4

1 に答える 1

1

いいえ、Hystrix は接続プールを置き換えることはできません。

Hystrix の主な機能は次のとおりです。

  1. 限定されたスレッド プールまたはセマフォを使用して、サービスへの呼び出しの数を制限します。
  2. 遅い/ハングしたサービスを待ってアプリケーションスレッドがロックされるのを避けるために、サービスへの呼び出しをタイムアウトにする可能性。
  3. 1 つの遅いサービスがアプリケーションの残りの部分に最小限の影響を与えるように、隔壁を追加します。
  4. サーキット ブレーカーが遅い/ハングしたサービス。

は接続のプーリングをサポートしていません。

最初のポイントは、Hystrix と接続プールの両方が他のシステムに対する負荷を制限できるという点で、接続プールに多少関連していると主張できると思います。ただし、接続プールを使用する主な理由は、接続のプールによるパフォーマンスの向上です。この負荷制限動作は、基本的に接続プールのボーナスです。

ただし、Hystrix は、質問で示唆されているように、接続プールの前に追加された場合、フェイルファスト タイムアウト動作とバルクヘッドを提供することで、接続プールを補完できます。

于 2015-06-21T17:24:00.717 に答える