1.1 アプリケーションのアーキテクチャ
このコースは、本格的なアプリケーションのアーキテクチャを長期間設計するわけではないため、初心者向けに設計されています。ただし、心配しないでください。優れたアーキテクチャは原則ではなく例外です。アプリケーションを構築する前に、適切なアプリケーション アーキテクチャを選択することは非常に困難です。
大規模サーバー アプリケーションの一般的なアーキテクチャの例:
- 階層化アーキテクチャ (階層化アーキテクチャ)。
- 階層型アーキテクチャ。
- サービス指向アーキテクチャ (SOA)。
- マイクロサービス アーキテクチャ (マイクロサービス アーキテクチャ)。
それぞれに長所と短所があります。しかし、それらを勉強しても何も得られません。アーキテクチャは、「システム内の何千ものオブジェクトの相互作用をどのように組織するか」という質問に対する答えです。そして、問題の複雑さを完全に体験するまでは、解決策の多様性を完全に理解することはできません。
すべてのアプリケーションは、何らかのアーキテクチャを使用しているか、少なくともそのように見せかけています。したがって、アプリケーション設計の一般的なアプローチについての知識があれば、アプリケーションがどのように動作するかを迅速かつより深く理解できるようになります。つまり、必要な場所に正確に変更を加えることができます。
「必要に応じて変更を加える」とはどういう意味ですか? 変更する必要のない場所はありますか? その通り。
具体的に言うと、中規模のバックエンド プロジェクトに取り組んでいるとします。この本は20人のチームによって5年間かけて書かれました。このプロジェクトには 100 人年かかり、約 10 万行のコードが含まれています。合計 2,000 のクラスで構成され、異なるサイズの 10 個のモジュールに分割されています。
そして厳しい現実も加わります。一部のタスクのロジックは、複数のモジュールにまたがっています。また、ビジネス ロジックはフロントエンド (JavaScript で記述) に含めることも、ストアド プロシージャとしてデータベースに直接記述することもできます。正確に変更を加えるべき場所をすぐに判断できると確信していますか?
これはあなたを怖がらせるために私が作った悪夢ではありません。これは典型的なプロジェクトです。さらに悪いことが起こります。なぜこうなった？理由はいくつも考えられますが、ほとんどの場合、次のような理由が考えられます。
- 多くの人がプロジェクトに取り組んでいますが、それぞれが少しずつ異なる見方をしています。
- 5年間で10人も入れ替わったプロジェクトで、新人はあまり理解できませんでした。
- ソフトウェアの作成では、常に変更を加え、すべてを常に変更します。
- 5 年前、私たちがアーキテクチャを決定したとき、プロジェクトのアイデアは多少異なりました。
しかし重要なことは、プロジェクトのアーキテクチャに関係なく、それに取り組んでいるすべてのプログラマーが、このプロジェクトがどのように機能するかについて同じ理解を固守していたということです。最も単純な概念であるクライアントサーバーアーキテクチャから始めましょう。
1.2 クライアントとサーバーの対話の概念
ここで、クライアント サーバーアーキテクチャの基礎となる概念を理解し、インターネット上の何百万ものプログラムの相互作用がどのように構成されているかをよりよく理解できるようにします。
名前が示すように、この概念にはクライアントとサーバーの2 つの関係者が関係します。ここでの生活はすべて同じです。クライアントは特定のサービスの顧客であり、サーバーはサービスプロバイダーです。クライアントとサーバーは物理的にはプログラムです。たとえば、典型的なクライアントはブラウザです。
サーバーとしては次の例が挙げられます。
- Tomcat などの Web サーバー。
- MySQL などのデータベース サーバー。
- Stripe のような決済ゲートウェイ。
クライアントとサーバーは通常、インターネット経由で通信します (ただし、同じローカル エリア ネットワーク内や、一般に他の種類のネットワーク内でも動作できます)。通信は、HTTP、FTP などの標準プロトコル、または TCP や UDP などの下位レベルのプロトコルを介して行われます。
プロトコルは通常、サーバーが提供するサービスの種類に応じて選択されます。たとえば、ビデオ通話の場合、通常は UDP が使用されます。
Tomcat とそのサーブレットがどのように機能するかを覚えていますか? サーバーは HTTP メッセージを受信し、それを解凍し、そこから必要な情報をすべて抽出して、処理のためにサーブレットに渡します。その後、処理結果は HTTP 応答にパッケージ化されてクライアントに送信されます。
これは典型的なクライアントとサーバーの対話です。ブラウザは Web クライアントであり、Tomcat は Web サーバーです。Tomcat は Web サーバーとも呼ばれます。
しかし、よく考えてみると、重要なのは名前ではなく、プログラム間の役割の配分という本質です。HTML ページ内で実行される JS スクリプトはクライアント、サーブレットはサーバーと呼ぶことができます。結局のところ、これらはクライアント/サーバーの概念の枠組み内でペアで動作します。
1.3 重要なニュアンス
また、クライアントとサーバーの対話は、そのような対話はクライアントによって開始されるという原則に基づいていることにも注目してください。サーバーはクライアントに応答し、クライアントにサービスを提供できるかどうか、提供できる場合はどのような条件であるかを報告するだけです。 。
クライアントが物理的にどこにあるか、サーバーがどこにあるかは関係ありません。クライアント ソフトウェアとサーバー ソフトウェアは通常、別のマシンにインストールされますが、同じコンピュータ上で実行することもできます。
この概念は、複雑なシステムを簡素化するための最初のステップとして開発されました。彼女には次のような強みがあります。
- ロジックの単純化: サーバーは、クライアントについても、クライアントが将来そのデータをどのように使用するかについても何も知りません。
- 弱いクライアントが存在する可能性があります。リソースを大量に消費するすべてのタスクがサーバーに転送される可能性があります。
- クライアント コードとサーバー コードの独立した開発。
- Tomcat やさまざまなブラウザなど、さまざまなクライアントがたくさんあります。
クライアントとサーバー間の対話の最も基本的なバージョンを次の図に示します。
ここで 2 つの詳細に注意することが重要です。まず、この図は、多数のクライアントが 1 つのサーバーにアクセスできることを示しています。第二に、同時にアクセスできるということです。これもサーバーの重要な部分です。
通常、1 つのクライアントは 1 人のユーザーと対話するため、多くの場合、そこでは承認さえ必要ありません。ただし、サーバーは何千ものクライアントからのリクエストを処理するため、そのコードを開発するときは、認可と認証を区別できる必要があります。
サーバーが数千のリクエストを並行して処理することも重要です。これは、バックエンド コードを開発するときに、リソースへの同時アクセスのタスクについて常に考える必要があることを意味します。また、サーバー コードでは、競合状態 (スレッド競合)、デッドロック (スレッドの相互ブロック) が発生する可能性が非常に高くなります。
重要なオブジェクトのライフサイクルを監視する必要があります。
を介してサーバー上で新しいスレッドを開始することはできませんnew Thread().start()。代わりに、すべてのサービス スレッド間で共有する ThreadPool が必要です。
また、非同期タスクは別のスレッドでも実行されるため、単に開始することはできません。このようなタスクを作成するときは、どのスレッドのプールがそれを実行しているのか、またそのようなプールがオーバーフローした場合に何が起こるのかを常に知っておく必要があります。
ファイルとディレクトリのすべての作業は、try-with-resources を通じて実行する必要があります。通常のアプリケーションでストリームまたはファイルを閉じるのを忘れた場合、それは問題ですか? プログラムを終了すると自動的に閉じられます。しかし、コードのどこかでサーバー上のファイルを閉じるのを忘れ、サーバーが何ヶ月も稼働し続けた場合...すぐに、そのような閉じられていないファイルが何千も蓄積され、OS は読み取り用に新しいファイルを開くことを停止します (ファイルの操作) OSによって制御されます）。チームリーダーはあなたの頭を撫でてくれません...
1.4 クライアントサーバーアーキテクチャ
もう一つの重要な点。クライアント/サーバー アーキテクチャは、コンピュータ間の対話の一般原則のみを定義し、対話の詳細はさまざまなプロトコルによって決定されます。
この概念 (クライアント - サーバー) は、ネットワーク上のマシンを、常に何かを必要とするクライアント マシンと、必要なものを提供するサーバー マシンに分割する必要があることを示しています。この場合、クライアントは常に対話を開始し、対話が発生するルールはプロトコルによって記述されます。
クライアント/サーバー対話アーキテクチャには 2 つのタイプがあります。1 つ目は2 層クライアント/サーバーアーキテクチャと呼ばれ、2 つ目は多層クライアント/サーバー アーキテクチャ ( 3 層アーキテクチャまたは 3 層アーキテクチャと呼ばれることもあります)ただし、これは特殊な場合です）。
クライアントとサーバーの対話の 2 層アーキテクチャの動作原理は、リクエストの処理が、その処理の過程で他のサーバーを参照せずに 1 つのサーバー上で行われることです。
2 層のクライアント/サーバー対話モデルは、単純な図として描くことができます。
ここでは、最初のレベルがクライアントに関するすべてであり、2 番目のレベルがサーバーに関するすべてであることがわかります。