0

クライアント/サーバー ソリューションを構成する最善の方法を見つけようとしています。簡単に言えば、私のソリューションには、ロジックを実行するバックエンドが必要であり、イントラネットで複数のクライアントをサポートできる必要があります。ここで重要なのは、数千の同時リクエストが発生しないことです...数百ユーザーに制限される可能性が高いため、スケーラビリティは実際には問題になりません. (ローカル ネットワーク上のオフィス ビルで実行されているサービスを想像してください)。これがどのように機能するか、どのテクノロジーを使用する必要があるかという全体的な流れに苦労しています。

コンポーネントは次のとおりです。

  • サーバー上にあるロジック部分
  • データベース
  • 複数のデスクトップ、モバイル、および Web クライアント

これまでのところ、私が思いついたのは次のとおりです。

  1. ロジックからの API 呼び出しと DB アクセスを管理するアプリケーション サーバーが必要です。
  2. その上にある Web サーバーで、着信要求を管理します。
  3. ロジック部分。
  4. 私たちが定義する API に準拠するクライアント。

ですから、これらすべてがどのように結びついているのかわかりません...「ロジック」はアプリケーションサーバーとどのようにやり取りするのでしょうか? 「ロジック」はサーバーのように書く必要がありますか?

私が見るのは次のようなものです：

        req  
client ----> web server ----> app server -----> Logic

                                |-----> DB

           response 
app server ---------> web server ----> client

では、小規模な商用ソリューションを展開したい場合、これはそれを構成する方法でしょうか?

不明な点がある場合、またはさらに情報が必要な場合はお知らせください。

4

1 に答える 1

1

あなたの質問は非常に一般的です。あなたが提案した解決策も一般的です。特定の要件を引き出さない場合は、平均的なユーザー向けの平均的なパフォーマンスを備えた汎用システムを作成します。モバイル、デスクトップ、および Web クライアントの両方があると仮定すると、フロントエンドに Web サーバーを配置するという考えは適切です。しかし、その場合の問題は、すべてのビジネス ロジックを AppServer 側に保持することです。大量のデータ操作とパフォーマンス要件がある場合に備えて、データベースにいくつかのロジックを含めることができますが、これはルールというよりはむしろ例外です。とにかく、特定の要件が必要です。それ以外の場合、設計プロセスは風水のように見えます。また、テクノロジーを選択してスタックを構築する必要があります。

于 2012-06-15T04:49:06.600 に答える