モノリシックアプリケーションアーキテクチャの問題
アーカイブパッケージ（war形式など）には、通常はモノリシックアプリケーションと呼ばれるすべての機能アプリケーションが含まれています。アーキテクチャモノリシックアプリケーションの方法論は、モノリシックアプリケーションアーキテクチャです。
映画のチケットシステムを例にとると、アーキテクチャが図に示されています。
アプリケーションはモジュール化されていますが、UIといくつかのサービスモジュールは最終的にwarパッケージにパッケージ化され、システム全体のすべてのビジネス機能が含まれます。このようなアプリケーションシステムはモノリシックアプリケーションと呼ばれます。
多くのプロジェクトは単一のアプリケーションから始まると思います。モノリシックアプリケーションは、展開とテストが簡単です。プロジェクトの初期段階では、モノリシックアプリケーションを適切に実行できます。しかし、需要が増え続けるにつれて、開発チームに参加する人が増え、コードベースも急速に拡大しています。ゆっくりと、単一のアプリケーションがますます肥大化し、保守性と柔軟性が徐々に低下し、保守コストがますます高くなっています。以下にリストされているのは、モノリシックアプリケーションの問題の一部です。
- 非常に複雑：100万行の単一のアプリケーションを例にとると、プロジェクト全体に多くのモジュールが含まれ、モジュールの境界がぼやけ、依存関係が明確でなく、コードの品質が不均一で、無秩序に積み重なっています。 ...プロジェクト全体は非常に複雑です。コードを変更するたびに怖がります。単純な関数を追加したり、バグを変更したりしても、隠れた欠陥が発生します。
- 技術的負債：時間の経過、要件の変化、人員の離職に伴い、アプリケーションの技術的負債が徐々に形成され、蓄積されます。「壊れていない、修正しない」。これはソフトウェア開発で非常に一般的であり、モノリシックアプリケーションではさらに一般的です。使用されているシステム設計またはコードは、アプリケーション内の他のモジュールが予期しない方法で使用する可能性があるため、変更が困難です。
- デプロイの頻度が低い：コードが増えると、ビルドとデプロイにかかる時間も長くなります。モノリシックアプリケーションの場合：各機能の変更または欠陥の修復により、アプリケーション全体を再デプロイする必要が生じます。完全な展開方法は、時間がかかり、影響範囲が広く、リスクが高いため、単一のアプリケーションプロジェクトのオンライン展開の頻度は比較的低くなります。展開頻度が低いため、2つのリリース間で多数の機能変更と欠陥修復が行われ、エラーの可能性が比較的高くなっています。
- 信頼性の低さ：無限ループ、OOMなどのアプリケーションのバグにより、アプリケーション全体がクラッシュする可能性があります。
- 制限されたスケーラビリティ：単一のアプリケーションは全体としてのみ拡張でき、ビジネスモジュールのニーズに応じて拡張することはできません。たとえば、アプリケーションの一部のモジュールは計算量が多く、強力なCPUを必要とします。一部のモジュールは、IOを多用し、より多くのメモリを必要とします。これらのモジュールは一緒に展開されるため、ハードウェアの選択には妥協が必要です。
- 技術革新の妨げ：統一された技術プラットフォームまたはソリューションを使用してすべての問題を解決する単一のアプリケーションが生まれます。チームのすべてのメンバーが同じ開発言語とフレームワークを使用する必要があります。新しいフレームワークまたは新しい技術プラットフォームを導入することは非常に困難です。 。たとえば、100万行のコードを含むStruts 2で構築されたモノリシックアプリケーションの場合、Spring MVCに切り替える場合、切り替えのコストは間違いなく非常に高くなります。
要約すると、ビジネス要件の開発と機能の継続的な増加により、単一のアーキテクチャがインターネット時代の急速なビジネス変化のニーズを満たすことは困難です。