0

サーバー コンポーネントを使用して、既存のアプリケーション (SQL Server を使用した .NET) を拡張しています。このコンポーネントは 2 つの役割を果たします。バックグラウンド タスク (長時間実行される計算、および cron ジョブのようなタスク) を実行し、ローカル ネットワークで実行されているアプリケーションに API を提供することでアプリケーション サーバーとして機能します。

問題は、アプリケーション サーバー ビットを実装するために (.NET の世界で) どのテクノロジを使用するかということです。要件は次のとおりです。

  • 依存関係がほとんどなく、インストールが簡単なはずです。
  • サーバーとのすべての通信は、信頼性が高く、暗号化され、サーバーとクライアントが認証されている必要があります。
  • スループットは応答時間ほど重要ではありません (1 秒あたり 100 回未満の呼び出し)。各要求は遅滞なく応答する必要があります (TCP 接続を介して SELECT 1 を使用して SQL サーバーにクエリを実行する場合など)。これは、リクエストを送受信するテクノロジーによるオーバーヘッドをできるだけ少なくすることを意味すると思います。
  • 多くの呼び出しには重いバイナリ ペイロードがあります (基本的に、クライアントはファイルを要求または送信します。主に 1 ~ 5 MB です)。
  • 拡張可能で将来性のあるものであること。
  • 将来のある時点で API を「パブリック」にする機能を備えているため、別のサーバー コンポーネントを追加する必要なく (さらにファイアウォールで別のポートを開く必要なく)、サード パーティ アプリケーション (SOA スタイル) で API を使用できます。 )。

実際、このアプリケーション サーバーの (現時点での) 最大のタスクは、ファイルを提供し、これらのファイルのリビジョンをアップロードできるようにすることです。

私はかなりの時間をネットで調べて、可能なアプローチ/技術の次のリストを思いつきました:

  • 上に独自のプロトコルを持つ純粋な TCP。(私の場合、この方法はお決まりの反応です。) 利点: 将来性があり、柔軟性があり、効率的であり、SSL は追加が適度に簡単であり (ここで説明されています)、接続指向 (つまり、アプリケーションの開始時に TCP ソケットを開きます) 、アプリケーションの終了時に閉じる、SSLハンドシェイクと認証は1回のみ実行されます)。欠点: サードパーティが簡単に統合できる標準がなく、原始的な開発モデル。
  • ASMX ウェブサービス. 利点: WSDL/Soap に基づく標準インターフェース、SSL の追加が容易、コード生成により煩雑な実装の詳細が隠されます。欠点: 将来性がない、SOAP over HTTP のみ、ファイル転送に非効率 (XML の base64)、ホスティングに IIS が必要 (したがって、インストールが容易ではない)。
  • Windows コミュニケーション ファンデーション (WCF)。利点: サポートされている多くのバインディング (そのうちのいくつかは WSDL/Soap のようなオープン スタンダード)、複数のインターフェースを同時に公開する可能性、SSL の追加が容易、コード生成、任意の .NET プロセスでホスト可能 (したがってインストールが容易)、 NetTcpBinding WCF は非常に効率的であるように見えます (ただし、サードパーティはまったく使用できません)。欠点: 学習曲線。
  • ASP.NET Web API . 欠点: ホスティングには IIS が必要ですが、REST/HTTP のみが必要です。REST はファイルを提供するのに最適かもしれませんが、他のいくつかの機能にはよりリッチなインターフェイスが必要です。
  • .NET リモーティング. WCF に置き換えられました。

これに基づいて、WCF が進むべき道であるかのように見えます。

質問 1:上記のリストには、いくつかの重要なテクノロジ/欠点/利点がありませんか?

質問 2:この分野の専門家は、WCF が上記の要件を達成する方法であることに同意しますか?

質問 3: WCF の効率性について教えてください。このような質問を見ると、接続指向でないことがパフォーマンスの問題にならないのではないかと思います。この投稿では、一定時間非アクティブになった後、応答時間が数百ミリ秒のオーダーに増加する方法について説明しています。さらに、リクエストごとに SSL ハンドシェイクを作成するのは非常に非効率的です。

4

3 に答える 3

1

独自のプロトコルを使用することは、それをサポートできるのはあなただけであるため、将来の保証にはなりません。また、必要以上に多くの作業が必要です。

WCF は、ほぼすべてのサービス ニーズに対応できる、実証済みの真のフレームワークです。単一のサービス (クラス / インターフェース) を作成し、要件に応じてさまざまな方法で公開できます。つまり、同じサービスを外部クライアントの Https 外部エンドポイント、tcp.net 内部エンドポイント、および REST エンドポイントにすることができます。いくつかの追加構成だけで時間を短縮できます。

WCF は長い間存在しており、どこにも行きません。その上、ネット上にはたくさんのサポート/情報があります。

于 2013-07-30T13:40:13.907 に答える
0

純粋な TCP にはさらに欠点があります。おそらく、独自のホストを作成する必要があります。再配置についてはどうですか?最初にシャットダウンする必要があり、ダウンタイムがあります。

私の見解では、次のステップは、WCF 構成をテストし、レイテンシーを下げることができるかどうかを確認することです。明らかに、数百ミリ秒は「通常」ではありません。接続プールを使用すると、通常のネットワーク遅延に加えて、リクエストを処理するための少量の CPU 時間が予想されます。おそらく1ミリ秒未満です。

WCF を機能させることができれば、他のすべてのポイントは無意味になります。なぜなら、WCF は明らかにパフォーマンス要件以外の最良の選択だからです。

于 2013-07-30T13:43:18.057 に答える
0

Web サービスは忘れてください。遅すぎます。

UDP または TCP の上に独自のプロトコルを使用します。高速で、軽量で、拡張が容易です。プロトコルを適切に文書化するだけです。ソケット通信が標準!

使ったことのないWCF。

于 2013-07-30T13:45:53.630 に答える