3 層アーキテクチャの概要
3 層アーキテクチャは、インターネット上で最も一般的な対話アーキテクチャです。これは、2 層のサーバー部分が 2 つの部分 (ロジック層とデータ層)に分割されたときに現れました。
次のような感じでした。
クライアント層は、ユーザー対話を担当する「分散アプリケーション」の一部です。この層にはビジネス ロジックを含めることはできず、重要なデータを保存することもできません。また、データベース層と直接対話するのではなく、ビジネス ロジック層を介してのみ対話する必要があります。
ただし、ここにはまだいくつかのロジックがあります。まず、これはインターフェイスを介したユーザーとの対話、ユーザーが入力したデータの検証、ローカルファイルの操作です。これには、サーバーを操作するときのユーザー認証とデータ暗号化に関連するすべてのものも含まれます。
2 番目に、これは単純なビジネス ロジックです。たとえば、オンライン ストアから製品のリストが送信された場合、クライアント側でそれらを並べ替えたりフィルタリングしたりできます。また、キャッシュ、ログイン ユーザーの Cookie などの基本的なデータ ストレージもここにあります。
ビジネス ロジック層は2 番目のレベルにあり、ビジネス ロジックのほとんどがそこに集中しています。その外側には、クライアントにエクスポートされるフラグメントと、データベースに組み込まれる論理要素 (ストアド プロシージャとトリガー) のみが残ります。
ビジネス ロジック サーバーのほとんどの部分には、これと同じロジックが含まれているだけでなく、スケーリングの問題も解決されます。コードは複数の部分に分割され、異なるサーバーに分散されます。需要の高いサービスの中には、数十台のサーバーで実行できるものもあります。それらの間の負荷はロード バランサーによって管理されます。
サーバー アプリケーションは通常、サーバーの別のコピーを簡単に起動して、他のコピーと連携して動作できるように設計されています。つまり、サーバー コードを作成するプロセスであっても、静的クラスが単一のインスタンスで起動されるという保証はありません。
データ層はデータ ストレージを提供し、別のレベルに配置され、原則としてデータベース管理システム (DBMS) によって実装されます。このコンポーネントへの接続はアプリケーション サーバー レベルからのみ提供されます。
データ層を分離する理由
データ層を本格的な第 3 層に分離する理由はさまざまですが、主な理由はサーバーの負荷の増加です。
まず、データベースはデータ処理に大量のメモリとプロセッサ時間を必要とし始めました。そのため、それらはどこでも別のサーバーに配置されるようになりました。
負荷が増加すると、バックエンドは簡単に複製でき、1 台のサーバーのコピーを 10 個作成できますが、データベースを複製することは不可能でした。データベースは依然としてシステムの単一の分割不可能なコンポーネントのままでした。
第二に、データベースはスマートになり、独自のビジネス ロジックを備えています。ストアド プロシージャ、トリガー、PLSQL などの独自の言語のサポートを開始しました。そして、DBMS 内で実行されるコードを書き始めたプログラマーも現れました。
データに関連付けられていないロジックはすべてバックエンドに取り出され、数十台のサーバーで並行して起動されました。データに関連する重要なものはすべて DBMS 内に残り、負荷の増加の問題はすでに独自の方法を使用して解決する必要がありました。
- データベース クラスターは、同じデータを保存し、特定のプロトコルを使用して同期するデータベース サーバーのグループです。
- シャーディング - データは論理ブロックに分割され、異なるデータベース サーバーに分散されます。このアプローチではデータベースの変更を維持するのが非常に困難です。
- NoSQL のアプローチは、膨大な量のデータを保存するために構築されたデータベースにデータを保存することです。これらは多くの場合、データベースではなく、特定のファイル ストレージです。リレーショナル データベースと比較すると機能が非常に劣ります。
- データのキャッシュ。データベース レベルの単純なキャッシュの代わりに、結果をメモリのみに保存する全体のキャッシュ DBMS が登場しました。
このサーバー テクノロジの動物園を管理するには、別の人やチーム全体が必要だったことは明らかです。そのため、データ レイヤーが別のレイヤーに削除されました。
重要！すべての高度なテクノロジーは、古いアプローチでは新しい課題に対処できなくなったときに、大規模な IT 企業の奥深くで生まれます。データベースを別個のレイヤーにすることは、プログラマーによって発明されたのではなく、Oracle または IBM の奥深くにいるエンジニアのグループによって発明されました。
面白い！ザッカーバーグが Facebook を書き始めたとき、彼は単純に PHP + MySQL に取り組みました。ユーザーが何百万人もいたとき、彼らはすべての PHP コードを C++ に翻訳し、それをネイティブ マシン コードにコンパイルする特別なトランスレーターを作成しました。
また、MySQL は何十億ものユーザーのデータを保存することができないため、Facebook は NoSQL データベースの概念を開発し、強力なサーバーサイド NoSQL DBMS - Cassandra を作成しました。ちなみに完全にJavaで書かれています。
アプリケーションロジックの場所の曖昧さ
また、3 層アーキテクチャでは、その部分間で役割がほぼ明確に分散されますが、ビジネス ロジックの新しい部分 (新しいコード) をシステム内のどこに追加する必要があるかを正確に判断できるとは限りません。
このような曖昧さの例を以下の図に示します。
サーバー部分は灰色の背景で塗りつぶされ、クライアント部分は白で塗りつぶされます。後者のアプローチ (右端) の良い例は、最新のモバイル アプリです。クライアント側 (電話上) には、ビュー (表示)、ロジック、およびデータが含まれます。そして、このデータがサーバーと同期されるのは時々だけです。
一番左のオプションの例は、サーバー上にすべてのロジックを備え、クライアントにすでに静的な HTML を提供する典型的な PHP サーバーです。プロジェクトはこれら 2 つの両極端の間のどこかに位置します。
プロジェクトに慣れた後、作業の開始時に、次のタスクのロジックを実装する方が良い場所について、プロジェクトに取り組んでいるプログラマーと相談する必要があります。
ご自由にどうぞ。第一に、彼らは憲章を持って他人の修道院に登ることはありません。第 2 に、誰にとっても (そしてあなたも) 必要なコードを、予想される場所で簡単に見つけられるようになります。