在不斷發展的軟體開發領域，微服務架構的採用因其可擴展性、靈活性和可維護性而迅速受到關注。 Quarkus 是專為 GraalVM 和 HotSpot 量身定制的 Java 原生 Kubernetes 堆疊，專門針對容器優化了 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 - 此實用程式模組可作為在專案中的多個其他模組之間使用的共用邏輯、常數和幫助程式的儲存庫。以這種方式集中通用功能可以減少重複並促進整個應用程式的一致性。它對於儲存資料格式轉換器、標準驗證器或常見業務規則等實用程式特別有用。
配置 - 此模組簡化了組態管理，將整個應用程式的所有組態設定整合到一個地方，簡化了存取和管理。這個中央配置儲存庫可確保一致地應用和管理設置，從而簡化環境轉換（例如從開發到生產）並最大限度地減少因配置錯誤而導致錯誤的可能性。除了簡單的設定檔之外，此模組也是定義跨應用程式必不可少的自訂託管bean 的理想位置，例如用於JSON 序列化和反序列化的ObjectMapper、自訂反序列化器以及其他專用bean 。
db-entities - 此模組專門用於資料庫交互，封裝了所有 ORM 類別或資料庫模式，確保它們與業務邏輯和 API 層分離。以這種方式隔離實體有助於透過將資料存取機制與業務規則處理解耦來維護乾淨的架構原則，從而促進更清潔和更可追蹤的程式碼庫。
服務 - 這裡是核心業務邏輯，封裝在對域模型進行操作並使用資料庫實體進行資料持久化的服務類別中。每個服務都專注於特定的業務任務，增強模組化和可重複使用性。這種分離還有助於將業務操作與直接客戶端互動隔離開來，這些互動由其他模組中的控制器類別處理，從而遵守單一責任原則。
資源 - 在一些爭論中，該模組的命名是為了反映其與 JAX-RS 的一致性，其中用 JAX-RS 註釋的類別稱為資源。此模組處理 REST 端點的創建，充當與外部客戶端互動的通訊層。選擇「資源」這個名稱而不是「休息」或「控制器」等替代名稱，是為了強調標準化和遵守既定的 RESTful 原則，如使用 Quarkus 建立 REST API 的紅帽資源中所述。透過與標準術語保持一致，該專案旨在讓熟悉 JAX-RS 和 REST 約定的開發人員變得直觀。
應用程式 - 作為一個傘模組，將所有部分組合在一起，確保它們正確連接並準備好部署。
每個模組都發揮著策略作用，旨在提高使用 Quarkus 的雲端原生微服務環境中的易維護性、可擴展性和穩健性。
上述結構是基於 RedHat 資源中所提到的以下架構層
在討論專案結構時，出現了一個常見問題，即是否需要我先前描述的分層方法。在這裡，我想起 David J. Wheeler 的話：
電腦科學中的所有問題都可以透過另一層間接來解決，除了太多間接層的問題。 - [《C 程式語言》第四版的 David J. Wheeler。 ]
以上是使用 Quarkus 建構有效的微服務項目結構的詳細內容。更多資訊請關注PHP中文網其他相關文章！
