モノリスアーキテクチャ

• すべての機能を単一のプロジェクトで開発する場合、それはモノリス アーキテクチャ ベースのアプリケーションと呼ばれます。

• アプリケーションを jar/war としてパッケージ化してサーバーにデプロイします。

• モノリス アプリケーションにはすべての機能が含まれているため、fat jar/war になります。

利点
1) 開発と管理が簡単。
2) すべてが 1 か所で入手可能です。
3) 設定は 1 回だけ必要です。

短所
1) メンテナンスが難しい
2) 単一障害点
3) 変更を行った場合、プロジェクト全体が再デプロイされ、テストされます。
4) 開発者はモジュール全体の知識がない可能性があるため、問題の修正を開始するのは困難です。
5) 一部のモジュールの負荷が高くなった場合は、アプリケーション全体の複数のインスタンスを作成する必要があり、各モジュールが互いに緊密に結合されているため、多くのスペースが必要になります。

モノリシックの問題を克服するために、マイクロサービス アーキテクチャが市場に登場しました

マイクロサービスアーキテクチャ

• マイクロサービスは、プログラミング言語、フレームワーク、または API ではありません。マイクロサービスはアーキテクチャ設計パターンです。

• 疎結合でアプリケーション機能を開発することを提案するマイクロサービス。

• マイクロサービス アーキテクチャでは、すべての機能を 1 つのプロジェクトで開発するわけではありません。プロジェクトの機能をいくつかの REST API に分割します。

• Microservices は Java だけに関係するものではありません。プログラミング言語固有のプロジェクトはマイクロサービス アーキテクチャを使用できます。

マイクロサービスは、小規模なサービスを開発するアプローチです。各サービスは独自のコンテナ/プロセス/サーバー上で実行され、サービスは軽量で独立してデプロイ可能である必要があります。これにより、より迅速な開発、展開、スケーラビリティが可能になります。

ご覧のとおり、モノリス アプリケーションの従業員モジュール、顧客モジュール、住所モジュール、およびコース モジュールが小規模なサービスに変換されたため、ここでは従業員サービス、顧客サービス、住所サービス、コース サービスのようなものになります。モノリス アプリケーションでは単一のデータベースが使用されますが、マイクロサービス アプリケーションでは各サービスが独自のデータベースを持ちます。そしてそれらは今では相互に依存しています。各サービスは相互に通信し、残りの呼び出しをスローします。

利点

• テクノロジーの独立性 (Python、Go などの複数のテクノロジーを使用してバックエンド API を開発できます)

• データベースの独立性。

• 各サービスは互いに独立しているため (疎結合)、各サービスを個別にデプロイできます。

• いずれかのサービスで変更を実行する場合、すべてのサービスをデプロイする必要はなく、1 つのサービスのみを 1 つだけデプロイします。

• 1 つのサービスに取り組む開発者は、アプリケーション全体の知識を必要としません。

• 単一のマイクロサービスの障害はアプリケーション全体に影響を与えず、全体的な復元力が向上します。

• コードベースが小さくなり、懸念事項が分離されるため、メンテナンスとデバッグがより管理しやすくなります。

• その小規模で独立した性質により、個々のマイクロサービスは、アプリケーション全体をスケーリングすることなく、需要に基づいて個別にスケーリングできます。

• 各サービスは異なる方法でテストできます。

デメリット

• 1 つのサービス構成で変更を実行したい場合、各サービス構成で変更を実行する必要はありません。たとえば、すべてのプロジェクトのすべての application.properties ファイルに存在する共通のプロパティがあります。

company.name=tier3Hub

したがって、会社名を変更したい場合は、すべてのサービスで名前を変更する必要があります。

• マイクロサービス ベースのアプリケーションのテストは、サービス間の相互依存性と相互作用により、より複雑になる可能性があります。

• 各サービスは、サービスがダウンしているよりも多くのリクエストを送信した場合、その後特定の量のリクエストを処理するため、そのサービスの複数のインスタンスが必要であり、リクエストをサービスの別のインスタンスにルーティングするには、クライアントからのリクエストと別のインスタンスのルートのバランスをとったロードバランサー。しかし、ロードバランサーを Java で書くのは難しいです。

マイクロサービスに Java を使用する理由

Java は、Rest API を開発するための Spring-Boot と呼ばれるフレームワークを提供します。Spring-Boot は、サービスを開発している場合に自動構成、組み込みサーバーなどの多くの機能を提供するため、サーバー上に sech サービスをデプロイする必要があります。 Spring-Boot は Tomcat サーバーを提供するため、各サービスは Tomcat の異なるポートで実行されます。たとえば、従業員サービスはポート 8080 で実行され、コース サービスはポート 8081 で実行され、各サービスには独自のサーバーがあります。

spring-Boot の助けを借りて、迅速な開発、少ない構成、本番対応アプリケーションおよびステーター プロジェクトのための機能を提供します

Spring Framework の下には、既製のサポート マイクロサービスを提供する Spring Cloud と呼ばれるプロジェクトがあり、Spring Cloud は、マイクロサービスの共通パターンを迅速に開発するためのいくつかの共通ツールと技術を提供します。

Spring Cloud は、典型的なユースケースに対してすぐに使用できる優れたエクスペリエンスと、他のユースケースをカバーする拡張メカニズムを提供することに重点を置いています。

• 分散/バージョン管理された構成
• サービスの登録と検出
• ルーティング
• サービス間通話
• 負荷分散
• サーキットブレーカー
• 分散メッセージング
• 有効期間が短いマイクロサービス (タスク)
• 消費者主導および生産者主導の契約テスト。

マイクロサービスアーキテクチャ

マイクロサービス用の固定アーキテクチャはありません。開発者はプロジェクトの要件に従ってマイクロサービス アーキテクチャをカスタマイズしています。ほとんどのプロジェクトでは、マイクロサービス アーキテクチャの以下のコンポーネントを使用します。

1) サービス レジストリ (Eureka サーバー)

2) サービス (REST API)

3) サービス間通信 (FeginClient)

4) API ゲートウェイ

5) 管理サーバー

6) ジップキン

結論

Java のマイクロサービスは、ソフトウェア開発へのアプローチ方法を変革し、新しいレベルの柔軟性、拡張性、回復力をもたらしました。 Java の豊富なエコシステムと Spring Boot、Micronaut などのフレームワークを組み合わせることで、最新のアプリケーションの要求に耐えられるマイクロサービスを構築するための優れた選択肢となります。

このアーキテクチャを調査してみると、従来のモノリシック アプリケーションよりもマイクロサービスの人気が高まっている理由が明らかです。これらはモジュール性と独立性を提供し、チームがサービスを個別に開発、展開、拡張できるようにします。これは、クラウドネイティブ機能がますます標準になりつつある世界では特に価値があります。ただし、その過程では、データの一貫性の確保、サービス間通信の管理、サービス全体での堅牢なセキュリティの維持などの課題も明らかになりました。

マイクロサービスを扱う Java 開発者にとって、ツールや実践方法の最新の進歩を常に最新の状態に保つことは非常に重要です。状況は常に進化しており、適応する者は、このアーキテクチャの可能性を最大限に活用できる最適な立場に立つことができます。 Java のマイクロサービスの将来は、知識と経験を共有したいと願う開発者のコ​​ミュニティの成長によってサポートされ、フレームワークとツールが継続的に改善されているため、有望に見えます。

Java でマイクロサービスを採用することは、より回復力があり、スケーラブルで、保守しやすいアプリケーションを作成するための扉を開くことを意味します。ベスト プラクティスに従い、継続的な学習に専念することで、開発者はソフトウェア開発の新たな可能性を解き放ち、より革新的で効率的なソリューションを生み出すことができます。