Quarkus を使用したマイクロサービスの効果的なプロジェクトの構築
- DDDオリジナル
- 2024-09-19 06:26:08810ブラウズ
進化し続けるソフトウェア開発の状況において、その拡張性、柔軟性、保守性により、マイクロサービス アーキテクチャの採用が急速に注目を集めています。 Quarkus は、GraalVM および HotSpot 向けに調整された Java ネイティブ Kubernetes スタックとして、特にコンテナー向けに Java を最適化し、Java がサーバーレス、クラウド、および Kubernetes 環境の効果的なプラットフォームになることを可能にします。
Quarkus を効果的に活用するための鍵は、プロジェクトを正しく構成する方法を理解することです。プロジェクトを適切に構造化すると、コードの管理性が向上するだけでなく、マイクロサービス アーキテクチャの導入を成功させる上で重要な役割を果たします。
マイクロサービス アーキテクチャは、Quarkus が強化するいくつかの定義された特性によってそれ自体を区別します。
小規模かつ集中型 - マイクロサービス アーキテクチャの各サービスは、明確に定義された単一のタスクを実行するように設計されており、シンプルさと集中力を促進します。 Quarkus は、特定のタスクに最適な軽量でブート可能な jar とネイティブ コンパイルを容易にすることでこれをサポートします。
独立 - 独立性により、他のサービスに依存せずにサービスを開発、デプロイし、拡張することもできます。 Quarkus のコンテナファーストの哲学により、各マイクロサービスが隔離された環境で実行できることが保証されます。
疎結合 - サービスは明確に定義された API を介して通信し、内部実装への依存を減らします。 Quarkus は、MicroProfile や JAX-RS などの標準による分離を促進し、サービスの対話をシームレスかつ効率的にします。
スケーラブル - 増加するワークロードを効率的に管理することが重要です。 Quarkus のリアクティブ プログラミング機能により、サービスはさまざまな負荷の下でも応答性が高く、スケーラブルになります。
-
柔軟性 - Quarkus の動的なスケーリングと復元機能により、変化する条件に適応する機能が促進され、クラウドネイティブ環境でのオンザフライ調整がサポートされます。
復元力- Quarkus は、組み込みのフォールト トレランス機能とヘルスチェック機能によりマイクロサービスの堅牢性を強化し、サービスの障害に対する耐性と中断からの迅速な回復を保証します。
Maven マルチモジュール プロジェクト構造の採用は、大規模な Java アプリケーションの管理に効果的であることが証明されており、Quarkus はこのモダリティを完全にサポートしています。 Maven のマルチモジュール構造を詳しく見てみましょう:
Maven マルチモジュール プロジェクトは、複数のサブモジュールを調整するアグリゲーター POM で構成されます。この構造は、大規模なアプリケーションを管理可能で独立して展開可能なユニットに分割し、簡単に保守および更新できるようにするのに役立ちます。通常、各モジュールには集中的な責任があり、他のモジュールから独立してデプロイできます。
実際のアプリケーションに基づいた簡略化されたレイアウトは次のとおりです。
parent (aggregator pom.xml) ├── api (API interfaces and DTOs) │ ├── pom.xml │ └── src ├── core (Business logic) │ ├── pom.xml │ └── src ├── data-access (Data layer integration) │ ├── pom.xml │ └── src
私は、多様な開発チームにわたるスケーラビリティ、保守性、一貫性を強化する、Quarkus 専用に最適化されたプロジェクト構造を調整しました。私が 2018 年に初めて開発したデザインは、進化する技術トレンドに合わせていくつかの改良が加えられました。当初、この構造は特に Quarkus を念頭に置いて作成されたものではありませんでした。ただし、そのアプリケーション全体を通じて、Quarkus の哲学およびコーディング手法と非常に優れた互換性があることが証明されています。 IntelliJ IDEA などの IDE に実装されたこの構造を調べてみましょう。ただし、他の最新の IDE にも効果的に適合させることができます。
完全なプロジェクト構造は GitHub リポジトリで見つけることができます
プロジェクトはトップレベルから始めて、特定の役割を持ついくつかのモジュールに分割されます。
api-dtos - このモジュールは、データの内部表現を API を通じて外部に公開されるものから分離するために重要です。データ転送オブジェクト (DTO) をドメイン モデルから分離することにより、このモジュールは、データベース スキーマまたはビジネス ロジックの変更が、これらの API を使用するクライアントに直接影響しないようにします。この分離により、API の安定性とバージョン管理が強化されます。
commons - このユーティリティ モジュールは、プロジェクト内の他の複数のモジュール間で使用される共有ロジック、定数、およびヘルパーのリポジトリとして機能します。この方法で共通の機能を一元化すると、重複が減り、アプリケーション全体の一貫性が高まります。これは、データ形式コンバーター、標準バリデーター、一般的なビジネス ルールなどのユーティリティを保存する場合に特に役立ちます。
configuration - このモジュールでは構成管理が合理化され、アプリケーション全体のすべての構成設定が 1 か所に統合され、アクセスと管理が簡素化されます。この構成の中央リポジトリにより、設定が一貫して適用および管理されるため、環境の移行 (開発から実稼働など) が簡素化され、構成ミスによるエラーの可能性が最小限に抑えられます。このモジュールは、単純な構成ファイルだけでなく、JSON のシリアル化と逆シリアル化のための ObjectMapper、カスタム デシリアライザー、その他の特殊な Bean など、アプリケーション全体で不可欠なカスタム マネージド Bean を定義するための理想的な場所でもあります。
db-entities - データベース対話専用のこのモジュールは、すべての ORM クラスまたはデータベース スキーマをカプセル化し、ビジネス ロジックおよび API レイヤーから確実に分離します。この方法でエンティティを分離すると、データ アクセス メカニズムをビジネス ルール処理から切り離すことにより、クリーンなアーキテクチャ原則を維持することができ、よりクリーンで追跡可能なコードベースが促進されます。
サービス - ここには、ドメイン モデル上で動作し、データの永続化のために db-entities を使用するサービス クラスにカプセル化されたコア ビジネス ロジックがあります。各サービスは特定のビジネス タスクに焦点を当てており、モジュール性と再利用性が強化されています。この分離は、他のモジュールのコントローラー クラスによって処理されるクライアントとの直接のやり取りからビジネス オペレーションを分離することにも役立ち、単一責任の原則を遵守します。
リソース - いくつかの議論の中で、このモジュールは JAX-RS との整合性を反映するために名前が付けられました。JAX-RS のアノテーションが付けられたクラスはリソースと呼ばれます。このモジュールは REST エンドポイントの作成を処理し、外部クライアントとのインターフェースとなる通信層として機能します。 Quarkus を使用した REST API の構築に関する Red Hat リソースで説明されているように、標準化と確立された RESTful 原則への準拠を強調するために、「レスト」や「コントローラー」などの代替名ではなく「リソース」という名前が選択されました。このプロジェクトは、標準の用語に合わせることで、JAX-RS および REST の規約に精通した開発者にとって直観的になることを目指しています。
アプリケーション - すべての部分をまとめる包括的なモジュールとして機能し、それらが正しく接続され、デプロイの準備ができていることを確認します。
これらの各モジュールは、Quarkus を使用したクラウドネイティブ マイクロサービス環境でのメンテナンスの容易さ、拡張性、堅牢性を促進するために調整された戦略的な役割を果たします。
上記の構造は、RedHat リソースで説明されている次のアーキテクチャ層に基づいています
抽象化が多すぎる
プロジェクトの構造について議論するとき、前に説明した階層化されたアプローチの必要性についてよく疑問が生じます。ここで、デイビッド J. ウィーラーの言葉を思い出します。
コンピュータサイエンスにおけるすべての問題は、間接化の層が多すぎる問題を除いて、別のレベルの間接化によって解決できます。 - [C プログラミング言語第 4 版の David J. Wheeler ]
以上がQuarkus を使用したマイクロサービスの効果的なプロジェクトの構築の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。