第 19 章: MSDN の物理層と配置では、「分散配置」について説明しています (図 2 を参照)。すべて順調です。
私の経験では、私たちは常に Web ベースのシステムを「非分散展開」と呼ばれるものに従って展開してきました (図 1)。私の理解では、Microsoft の世界では、独立したものとしての「アプリケーション サーバー」は (Java の世界のように) 実際には存在しないということです。
私の質問は、UI とビジネス ロジック (BL) を異なるサーバー / 層に分散するとしたら、どのように通信するのでしょうか?
答えの 1 つは、「サービス レイヤー」を使用することです。実際にどうやってそれを行うのですか？コードの観点からはどのように見えるでしょうか?
最初に。やらないでください。ただしないでください。あなたは痛みの世界にいます。論理層と物理層は別物です。アプリケーション層を論理的に分離することをお勧めします。多くの場合、アプリケーション層を物理的に分離すると、障害が発生します。適切な展開理由 (別のボックスでの共有支払いプロセッサ) がある場合は、すぐに進んでください。WCF、MSMQ、HTTP など、誰もが知っていて愛用している標準のメカニズムを使用できます。ただし、MSDN のホワイト ペーパーの神話上の理想を実現するために、オーバーヘッドや複雑さを考慮しないでください。
アプリケーション サーバーは、希少なリソース、つまり中間層の計算能力を配給するためのアイデアとして考案されました。このアイデアは、当初、CPU が不足していて高価だったメインフレームの領域から生まれました。そのため、メインフレームの CPU をさまざまなユーザーに割り当て、ワークロードを調整し、データベースの負荷を軽減するために多大な時間と労力とお金が費やされました。 "数時間後に負荷が減少するまでトランザクションなど。当時、人々はメインフレーム上のトランザクションを追跡するソフトウェアに何百万ドルも費やし、「チャージバック」を実行できるようにしました。はい、メインフレームの使用料を社内部門に請求できるように、人々は大量のお金を費やしました。
問題は、Intel (およびその後の AMD)、Cisco (その他)、EMC、Microsoft、および Linux が、アイデア全体を無意味なものにしたことです。コンピューティングは安くなりました。本当に安い。中間層のコンピューティング リソースを配給する必要はまったくありません。最近のデュアル CPU サーバーとは何ですか? 1 人の IT 担当者の年収で、そのうちの何個を展開できますか? これは、コンピューティングが高価で希少なリソースであり、人々が比較的 (!!) 安かったメインフレーム コンピューティングの古い経済学の逆転です。現在、人は高価な部分であり、コンピューティングは安価です。
アプリサーバー、およびコンピューティングへのアクセスを制限したり、それを分割したり、スロットリングしたり、チャージバックのためにトランザクションを「監視」したりするためのすべての付属品....これらのことは、ラックがある場合は必要ありません安価な AMD サーバー。
アプリ サーバーが行ったもう 1 つのことは、データベースをワークロードから保護することでした。基本的に、db サーバーから作業をオフロードします。開発者がストアド プロシージャにビジネス ロジックを配置すると、アプリができました。しかし、このアプローチにはスケーラビリティの問題がありました。ただし、ストアド プロシージャは高速で効率的です。データベース サーバーは安価にスケールアップできます。おそらく、世界のトップ 100 のワークロード ボリュームのうち、ストアド プロシージャ ロジックを備えた Intel ハードウェアでは処理できないものはありません。
ただし、ストアド プロシージャ アプローチの主な問題の 1 つは、主流の言語 (Java、C#、VB など) でストアド プロシージャを作成して管理するのが依然として難しいことです。はい、DB によって管理される SQL CLR と Java VM について知っています。しかし、それらは主流のアプローチではありません。また、DB 管理者は、コード ジョッキーが使用率グラフを台無しにするのを好みません。これらの理由から、目的専用の別の言語でビジネス ロジックを記述したいという要望がまだあります。そして、そのロジックを専用のコンピューティング リソースで実行および管理したいという要望がまだあります。しかし... 従来の「アプリサーバー」?? いいえ、意味がありません。
すべてのロジックを Intel サーバーに配置して、リッピングしましょう。さらにスケールが必要な場合は、ボックスを複製します。すべてのビジネス ロジックはステートレス (そうですよね?) であるため、スケールアウトできます。3 台の「アプリ」サーバー マシン、または 4 台または 5 台、または必要な数を使用します。すべてがまったく同じコードを実行しています。お互いのクローン。ビジネス ロジック マシンの数に関係なく、ワークロードを物理的に分散しないでください。スケーラビリティを最大化するために、各トランザクションを 1 つのボックスに保持するように努めてください。これは、リソースを効率的に最適に使用するためのレシピです。
アプリケーション アーキテクチャで論理層を使用することをお勧めします。これにより、開発と保守が容易になります。ただし、論理的な分離が物理的な分離を暗示したり、推奨したりする必要があるとは考えないでください。そうではありません。