1

私は、2 つのことを行う独自の単一エントリ ポイント「ゲートウェイ」を実装するというアイデアに夢中になっています。

まず、SOA サーバーによって処理された要求の数を記録し、次の要求を最も利用可能なサーバーに循環させます。負荷分散ロジックを完全に制御できることは魅力的です。

第 2 に、この「ゲートウェイ」は、セキュリティを含むすべてのサービスへの単一の連絡窓口になります。クライアントがユーザー名とパスワードの組み合わせを送信すると、それらがセキュリティ サービスに渡され、認証が成功するとトークンが付与されます。クライアントがトークンを送信すると、ゲートウェイはセキュリティ サービスによってこのトークンを実行し、コーシャの場合は、要求をビジネス サービスの 1 つに渡します。ゲートウェイ以外のすべてのサービスを非表示またはカプセル化することが望ましいと思われます。

私の質問は次のとおりです。これが「物事を行う正しい方法」ではない理由はありますか? 上記で説明したことを実行するフレームワークが既にある場合、車輪を再発明しているのでしょうか? 私のスタックは .NET と WCF です。

4

1 に答える 1

1

良い質問ですが、sweetfa のコメントに同意する必要があります。99% の場合、既製のロード バランサーが最適なオプションです。オプションのより完全なリスト:

  1. ハードウェア ロード バランサ/ゲートウェイ (IBM XML Gateway など) - 非常にスケーラブルで高価
  2. サービス バス ソフトウェア (Oracle Service Bus など) は、セキュリティと負荷分散も行いますが、非常に構成可能で高価です。ハードウェア ソリューションよりスケーラブルではない
  3. オープン ソースのロード バランサー ソフトウェア (Apache HTTPD Proxy モジュールなど) には、フォーラムを介してセットアップを支援する多数のユーザーがいます。ソリューションの多くは非常にスケーラブルで堅牢ですが、オプション 1 および 2 よりも構成方法が複雑になります。
  4. サービス レジストリ (UDDI v3) に基づく負荷分散。サービス コンシューマは呼び出しごとにプロバイダ URI を検索します。レジストリは、異なる URI を返すことによって、要求の負荷を分散します。このソリューションはセキュリティ ゲートウェイとして機能せず、消費者はそれを完全に無視する可能性があります
  5. 高度な適応負荷分散アルゴリズムが必要な場合、または非標準のセキュリティ層が必要な場合は、独自に構築してください。非標準のセキュリティについては忘れましょう。それが良い考えであることはめったにありませんが、適応型の負荷分散が望ましい場合があります。オプション 1 ～ 3 は、応答時間に基づいてラウンド ロビン、加重ラウンド ロビン、または適応型ラウンド ロビンを実行し、応答のないインスタンスを検出します。オプション 1 と 3 は、実装が難しいもう 1 つの機能である HTTP セッション スティッキーも提供しますが、SOAP または REST サービスには必要ありません。
于 2011-07-12T10:32:40.223 に答える