Quarkus를 사용한 마이크로서비스를 위한 효과적인 프로젝트 구조화

끊임없이 진화하는 소프트웨어 개발 환경에서 확장성, 유연성 및 유지 관리 가능성으로 인해 마이크로서비스 아키텍처 채택이 빠르게 주목을 받고 있습니다. GraalVM 및 HotSpot에 맞춰진 Java-Native Kubernetes 스택인 Quarkus는 Java를 컨테이너에 맞게 최적화하고 서버리스, 클라우드 및 Kubernetes 환경에 효과적인 플랫폼이 되도록 지원합니다.

Quarkus를 효과적으로 활용하는 핵심은 프로젝트를 올바르게 구성하는 방법을 이해하는 것입니다. 적절한 프로젝트 구조화는 코드의 관리 효율성을 향상시킬 뿐만 아니라 마이크로서비스 아키텍처 배포의 성공에 중요한 역할을 합니다.

마이크로서비스 아키텍처는 Quarkus가 향상시키는 몇 가지 정의 특성으로 차별화됩니다.

1. 소형 및 집중 - 마이크로서비스 아키텍처의 각 서비스는 잘 정의된 단일 작업을 수행하도록 설계되어 단순성과 집중을 촉진합니다. Quarkus는 특정 작업에 이상적인 가볍고 부팅 가능한 jar 및 기본 컴파일을 지원하여 이를 지원합니다.

2. 독립성- 독립성을 통해 다른 서비스에 의존하지 않고도 서비스를 개발, 배포하고 확장할 수 있습니다. Quarkus의 컨테이너 우선 철학은 각 마이크로서비스가 격리된 환경에서 실행될 수 있도록 보장합니다.

3. 느슨하게 결합- 서비스는 잘 정의된 API를 통해 통신하여 내부 구현에 대한 종속성을 줄입니다. Quarkus는 MicroProfile 및 JAX-RS와 같은 표준을 통해 분리를 장려하여 서비스 상호 작용을 원활하고 효율적으로 만듭니다.

4. 확장성- 증가하는 워크로드를 효율적으로 관리하는 것이 중요합니다. Quarkus의 반응형 프로그래밍 기능을 사용하면 다양한 로드에서도 서비스가 응답하고 확장 가능합니다.

5. 유연성 - 클라우드 기반 환경에서 즉각적인 조정을 지원하는 Quarkus의 동적 확장 및 탄력성 기능을 통해 변화하는 조건에 적응하는 능력이 촉진됩니다.

6. 복원력- 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의 철학 및 코딩 방식과 매우 호환되는 것으로 입증되었습니다. 다른 최신 IDE에도 효과적으로 적용할 수 있지만 IntelliJ IDEA와 같은 IDE에서 구현된 이 구조를 살펴보겠습니다.

GitHub 저장소에서 전체 프로젝트 구조를 찾을 수 있습니다

최상위 수준부터 시작하여 프로젝트는 각각 특정 역할을 가진 여러 모듈로 나뉩니다.

1. api-dtos- 이 모듈은 API를 통해 외부에 노출되는 데이터의 내부 표현을 분리하는 데 중요합니다. 도메인 모델에서 데이터 전송 개체(DTO)를 분리함으로써 모듈은 데이터베이스 스키마나 비즈니스 논리의 변경 사항이 이러한 API를 사용하는 클라이언트에 직접적인 영향을 미치지 않도록 보장합니다. 이러한 분리로 인해 API 안정성과 버전 관리가 향상됩니다.

2. commons - 이 유틸리티 모듈은 프로젝트의 다른 여러 모듈에서 사용되는 공유 논리, 상수 및 도우미에 대한 저장소 역할을 합니다. 이러한 방식으로 공통 기능을 중앙 집중화하면 중복이 줄어들고 애플리케이션 전체에서 일관성이 강화됩니다. 데이터 형식 변환기, 표준 유효성 검사기 또는 일반적인 비즈니스 규칙과 같은 유틸리티를 저장하는 데 특히 유용합니다.

3. 구성 - 전체 애플리케이션에 대한 모든 구성 설정을 한 곳에 통합하여 액세스 및 관리를 단순화하는 이 모듈에서는 구성 관리가 간소화됩니다. 이 중앙 구성 저장소는 설정이 일관되게 적용 및 관리되도록 보장하여 환경 전환(예: 개발에서 프로덕션으로)을 단순화하고 잘못된 구성으로 인한 오류 가능성을 최소화합니다. 단순한 구성 파일 외에도 이 모듈은 JSON 직렬화 및 역직렬화용 ObjectMapper, 사용자 정의 역직렬 변환기 및 기타 특수 Bean과 같이 애플리케이션 전반에 필수적인 사용자 정의 관리 Bean을 정의하기 위한 이상적인 위치이기도 합니다.

4. db-entities- 데이터베이스 상호 작용에만 전념하는 이 모듈은 모든 ORM 클래스 또는 데이터베이스 스키마를 캡슐화하여 비즈니스 로직 및 API 계층과 분리되도록 합니다. 이러한 방식으로 엔터티를 분리하면 비즈니스 규칙 처리에서 데이터 액세스 메커니즘을 분리하여 깔끔한 아키텍처 원칙을 유지하는 데 도움이 되며, 따라서 더 명확하고 추적 가능한 코드베이스를 촉진할 수 있습니다.

5. 서비스 - 여기에 도메인 모델에서 작동하고 데이터 지속성을 위해 db 엔터티를 사용하는 서비스 클래스에 캡슐화된 핵심 비즈니스 로직이 있습니다. 각 서비스는 특정 비즈니스 작업에 중점을 두고 모듈성과 재사용성을 향상시킵니다. 이러한 분리는 또한 다른 모듈의 컨트롤러 클래스에서 처리되는 직접적인 클라이언트 상호 작용으로부터 비즈니스 운영을 분리하여 단일 책임 원칙을 준수하는 데에도 도움이 됩니다.

6. 리소스 - 일부 논쟁 중에 이 모듈의 이름은 JAX-RS로 주석이 달린 클래스를 리소스라고 하는 JAX-RS와의 정렬을 반영하여 명명되었습니다. 이 모듈은 외부 클라이언트와 인터페이스하는 통신 계층 역할을 하는 REST 엔드포인트 생성을 처리합니다. '리소스'라는 이름은 Quarkus를 사용하여 REST API를 구축하기 위한 Red Hat 리소스에 설명된 대로 표준화와 확립된 RESTful 원칙 준수를 강조하기 위해 'rest' 또는 'controllers'와 같은 대안 대신 선택되었습니다. 표준 용어에 맞춰 JAX-RS 및 REST 규칙에 익숙한 개발자에게 직관적인 사용을 목표로 합니다.

이러한 각 모듈은 Quarkus를 사용하는 클라우드 네이티브 마이크로서비스 환경에서 유지 관리의 용이성, 확장성 및 견고성을 촉진하기 위해 맞춤화된 전략적 역할을 수행합니다. 위 구조는 RedHat 리소스에 언급된 다음 아키텍처 레이어를 기반으로 합니다

추상화가 너무 많으면 너무 많다

프로젝트 구조를 논의할 때 앞서 설명한 계층적 접근 방식의 필요성에 대한 일반적인 질문이 제기됩니다. 여기서 저는 David J. Wheeler의 다음 말을 떠올립니다.

---

너무 많은 간접 계층 문제를 제외하고 컴퓨터 과학의 모든 문제는 또 다른 수준의 간접 계층으로 해결될 수 있습니다. - [C 프로그래밍 언어 4판의 David J. Wheeler.]

위 내용은 Quarkus를 사용한 마이크로서비스를 위한 효과적인 프로젝트 구조화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!