마이크로 서비스 지향 애플리케이션 디자인

팁

이 콘텐츠는 eBook, 컨테이너화된 .NET 애플리케이션을 위한 .NET 마이크로 서비스 아키텍처에서 발췌한 것이며, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.

PDF 다운로드

이 섹션에서는 가상의 서버 측 엔터프라이즈 애플리케이션 개발에 대해 자세히 다룹니다.

애플리케이션 사양

가상 애플리케이션은 비즈니스 논리를 실행하고 데이터베이스에 액세스한 다음, HTML, JSON 또는 XML 응답을 반환하여 요청을 처리합니다. 애플리케이션이 SPA(단일 페이지 애플리케이션), 기존 웹앱, 모바일 웹앱, 네이티브 모바일 앱을 실행하는 데스크톱 브라우저를 포함한 다양한 클라이언트를 지원해야 하는 경우를 가정하겠습니다. 이 애플리케이션은 타사가 사용할 API도 노출할 수 있습니다. 또한 부분적 장애가 발생할 경우 마이크로 서비스가 쉽게 복원할 수 있도록 마이크로 서비스 또는 외부 애플리케이션을 비동기적으로 통합할 수 있어야 합니다.

이 애플리케이션은 다음과 같은 유형의 구성 요소로 구성됩니다.

• 프레젠테이션 구성 요소. 해당 구성 요소는 UI 처리 및 원격 서비스 사용을 처리합니다.

• 도메인 또는 비즈니스 논리. 해당 구성 요소는 애플리케이션의 도메인 논리입니다.

• 데이터베이스 액세스 논리. 해당 구성 요소는 데이터베이스(SQL 또는 NoSQL) 액세스를 처리하는 데이터 액세스 구성 요소로 구성되어 있습니다.

• 애플리케이션 통합 논리. 해당 구성 요소에는 메시지 브로커를 기반으로 하는 메시징 채널이 포함됩니다.

애플리케이션에는 높은 확장성을 요구되는 반면, 특정 하위 시스템에는 다른 하위 시스템보다 더 큰 확장성이 요구되기 때문에 수직 하위 시스템의 규모를 자율적으로 확장할 수 있습니다.

애플리케이션은 복수의 인프라 환경에 배포해야 하고(복수의 퍼블릭 클라우드 및 온-프레미스) 플랫폼 간 배포가 적절하며 Linux에서 Windows(또는 반대로)로 쉽게 이동할 수 있어야 합니다.

개발 팀 컨텍스트

또한 애플리케이션의 개발 프로세스에 대해 다음을 가정합니다.

• 애플리케이션에서 각각 다른 비즈니스 영역을 주로 담당하는 복수의 개발 팀이 있습니다.

• 새 팀 멤버는 신속하게 생산성을 발휘해야 하며 애플리케이션은 쉽게 이해하고 수정할 수 있어야 합니다.

• 애플리케이션은 장기간에 걸쳐 개발할 예정이며 비즈니스 규칙은 항상 변경됩니다.

• 여러분은 장기적 유지 관리 역량이 뛰어나 나중에 새 변경 사항을 민첩하게 구현할 수 있으며, 복수의 하위 시스템을 업데이트할 때에도 다른 하위 시스템에 미치는 영향을 최소화할 수 있어야 합니다.

• 여러분은 애플리케이션의 지속적인 통합 및 지속적인 배포를 연습하고자 합니다.

• 그리고 애플리케이션을 수정하는 동시에 새로운 기술(프레임워크, 프로그래밍 언어 등)을 활용하고자 합니다. 새로운 기술로 전환할 때 애플리케이션 전체를 마이그레이션할 경우 많은 비용이 발생할 뿐만 아니라 애플리케이션의 예측 가능성과 안정성에 영향을 미치므로 전체 마이그레이션은 원하지 않습니다.

아키텍처 선택

애플리케이션 배포 아키텍처를 어떻게 디자인해야 할까요? 애플리케이션의 규격과 개발 컨텍스트를 기준으로 보면, 협업하는 마이크로 서비스와 컨테이너(마이크로 서비스가 컨테이너)의 형태로 애플리케이션을 자율 하위 시스템으로 분할하여 애플리케이션을 설계하는 것이 좋습니다.

이 방식에서는 각 서비스(컨테이너)가 서로 결합되어 있고 관련성이 적은 기능의 집합을 구현합니다. 예를 들어 애플리케이션은 카탈로그 서비스, 주문 서비스, 장바구니 서비스, 사용자 프로필 서비스 등의 서비스로 구성될 수 있습니다.

마이크로 서비스는 HTTP(REST) 등의 프로토콜을 사용하여 통신할 수 있지만 가능할 때마다 AMQP 등을 사용해 비동기적으로 통신합니다(특히 통합 이벤트로 업데이트를 전파할 경우).

마이크로 서비스는 서로 독립적인 컨테이너로 개발 및 배포됩니다. 해당 접근 방식은 개발 팀이 다른 하위 시스템에 영향을 미치지 않고 특정 마이크로 서비스를 개발 및 배포할 수 있음을 의미합니다.

각 마이크로 서비스에는 자체 데이터베이스가 있어 다른 마이크로 서비스에서 완전히 분리할 수 있습니다. 필요할 경우 CQRS(명령과 쿼리의 역할 분리)에서 처리하는 방식대로 논리 이벤트 버스를 통한 애플리케이션 수준 통합 이벤트를 사용하여 다른 마이크로 서비스의 데이터베이스 사이에 일관성을 달성합니다. 이러한 이유로 비즈니스 제약 조건은 복수의 마이크로 서비스와 관련 데이터베이스 사이에 최종 일관성을 적용해야 합니다.

eShopOnContainers: 컨테이너를 사용하여 배포한 마이크로 서비스 및 .NET의 참조 애플리케이션

여러분이 모르는 가상의 비즈니스 도메인에 대해 생각하지 않고 아키텍처와 기술에 집중할 수 있도록 잘 알려진 비즈니스 도메인, 즉, 제품 카탈로그를 보여주고 고객으로부터 주문을 접수하며 재고를 확인하고 기타 비즈니스 기능을 수행하는 간소화된 전자상거래(인터넷 쇼핑몰) 애플리케이션을 선택했습니다. 이 컨테이너 기반 애플리케이션 소스 코드는 eShopOnContainers GitHub 리포지토리에 나와 있습니다.

애플리케이션은 여러 스토어 UI 프런트 엔드(웹 애플리케이션 및 네이티브 모바일 앱)를 포함한 여러 하위 시스템과 내부 마이크로 서비스에 대한 통합 진입점으로 여러 API 게이트웨이가 있는 모든 필수 서버 쪽 작업을 위한 백 엔드 마이크로 서비스 및 컨테이너로 구성됩니다. 그림 6-1은 참조 애플리케이션의 아키텍처입니다.

그림 6-1. 개발 환경을 위한 eShopOnContainers 참조 애플리케이션 아키텍처

위의 다이어그램에서는 모바일 및 SPA 클라이언트가 단일 API 게이트웨이 엔드포인트와 통신한 다음, 엔드포인트가 마이크로 서비스와 통신합니다. 일반적인 웹 클라이언트는 API 게이트웨이를 통해 마이크로 서비스와 통신하는 MVC 마이크로 서비스와 통신합니다.

호스팅 환경. 그림 6-1에 단일 Docker 호스트 내에 배포된 여러 컨테이너가 나와 있습니다. docker-compose up 명령을 사용하여 단일 Docker 호스트에 배포하는 경우에 해당합니다. 하지만 오케스트레이터 또는 컨테이너 클러스터를 사용할 경우 각 컨테이너는 다른 호스트(노드)에서 실행될 수 있으며 아키텍처 섹션에서 설명한 바와 같이 모든 노드는 임의 수의 컨테이너를 실행할 수 있습니다.

통신 아키텍처. eShopOnContainers 애플리케이션은 기능적 작업의 종류에 따라(쿼리 대 업데이트 및 트랜잭션) 두 가지 통신 유형을 사용합니다.

• API 게이트웨이를 통한 Http 클라이언트-마이크로 서비스 간 통신. 해당 접근 방식은 쿼리에 사용되며 클라이언트 앱으로부터 업데이트 또는 트랜잭션 명령을 수락할 때에도 사용됩니다. API 게이트웨이를 사용하는 방법은 이후 섹션에서 자세히 설명합니다.

• 비동기 이벤트 기반 통신. 해당 통신은 마이크로 서비스 전체에 업데이트를 전파하거나 외부 애플리케이션과 통합하기 위해 이벤트 버스를 통해 발생합니다. 이벤트 버스는 RabbitMQ와 같은 메시징-브로커 인프라 기술로 구현하거나 Azure Service Bus, NServiceBus, MassTransit 또는 Brighter와 같은 높은 수준(추상화 수준)의 서비스 버스를 사용하여 구현할 수 있습니다.

이 애플리케이션은 컨테이너 형태의 마이크로 서비스 집합으로 배포됩니다. 클라이언트 앱은 API 게이트웨이에서 게시된 공용 URL을 통해 컨테이너로 실행되는 마이크로 서비스와 통신할 수 있습니다.

마이크로 서비스별 데이터 주권

샘플 애플리케이션에서 각 마이크로 서비스는 자체 데이터베이스 또는 데이터 원본을 소유하지만 모든 SQL Server 데이터베이스는 단일 컨테이너로 배포됩니다. 이와 같은 디자인을 결정한 이유는 개발자가 GitHub에서 코드를 가져오고 복제한 다음, Visual Studio 또는 Visual Studio Code에서 손쉽게 열 수 있도록 하기 위해서입니다. 또는 .NET CLI 및 Docker CLI를 사용하여 사용자 지정 Docker 이미지를 손쉽게 컴파일한 다음, Docker 개발 환경에 배포 및 실행할 수 있습니다. 각각의 경우 개발자는 데이터 원본의 컨테이너를 사용함으로써 외부 데이터베이스 또는 인프라(클라우드 또는 온-프레미스)에 대한 종속성이 높은 다른 데이터 원본을 프로비전하지 않고도 몇 분 안에 빌드 및 배포할 수 있습니다.

실제 프로덕션 환경에서 가용성 및 확장성을 높이려면 데이터베이스가 클라우드 또는 온-프레미스에서 데이터베이스 서버를 기반으로 해야 합니다.

따라서 마이크로 서비스(및 이 애플리케이션의 데이터베이스)의 배포 단위는 Docker 컨테이너이며 참조 애플리케이션은 마이크로 서비스 원칙을 적용한 멀티-컨테이너 애플리케이션입니다.

추가 리소스

• eShopOnContainers GitHub 리포지토리. 참조 애플리케이션의 소스 코드
  https://aka.ms/eShopOnContainers/

마이크로 서비스 기반 솔루션의 이점

이러한 유형의 마이크로 서비스 기반 솔루션은 많은 이점이 있습니다.

각 마이크로 서비스는 비교적 소규모이며 관리와 수정이 간단합니다. 특별한 사항

• 개발자가 뛰어난 생산성으로 쉽게 이해하고 빠르게 시작할 수 있습니다.

• 컨테이너가 빠르게 시작되므로 개발자의 생산성이 향상됩니다.

• Visual Studio와 같은 IDE는 작은 프로젝트를 빠르게 로드해 개발자의 생산성을 높여줍니다.

• 각 마이크로 서비스는 다른 마이크로 서비스와 독립적으로 설계하고 개발 및 배포할 수 있어 새 버전의 마이크로 서비스를 빈번하게 배포하기 쉬우므로 민첩한 작업이 가능합니다.

개별 애플리케이션 영역의 규모를 확장할 수 있습니다. 예를 들어 카탈로그 서비스 또는 장바구니 서비스의 규모는 확장하지만 주문 프로세스는 확장하지 않아도 될 수 있습니다. 마이크로 서비스 인프라는 규모 확장 시 리소스와 관련하여 모놀리식 아키텍처에 비해 훨씬 효율성이 뛰어납니다.

개발 작업을 여러 팀으로 나눌 수 있습니다. 각 서비스를 단일 개발 팀이 소유할 수 있습니다. 각 팀은 나머지 팀과 독립적으로 서비스를 관리, 개발, 배포, 확장할 수 있습니다.

문제가 더욱 격리됩니다. 한 서비스에 문제가 있을 경우 처음에 해당 서비스에만 영향을 미치며(마이크로 서비스 간 직접적 종속성이 존재하는 잘못된 디자인을 사용한 경우 제외) 다른 서비스는 계속해서 요청을 처리할 수 있습니다. 반대로, 특히 메모리 누수와 같이 리소스가 관련된 경우 모놀리식 배포 아키텍처에서 구성 요소 하나의 오작동은 전체 시스템이 중단되는 원인이 될 수 있습니다. 또한 마이크로 서비스의 문제가 해결되면 애플리케이션의 나머지 부분에 영향을 미치지 않고 영향을 받은 마이크로 서비스만 배포할 수 있습니다.

최신 기술 활용할 수 있습니다. 서비스를 독립적으로 개발하고 (컨테이너 및 .NET 덕분에) 동시에 실행할 수 있으므로 전체 애플리케이션의 기존 스택 또는 프레임워크를 고수하지 않고 최신 기술과 프레임워크를 편리하게 사용할 수 있습니다.

마이크로 서비스 기반 솔루션의 단점

이러한 유형의 마이크로 서비스 기반 솔루션은 몇 가지 단점이 있습니다.

분산 애플리케이션. 애플리케이션을 분산하면 개발자가 서비스를 디자인 및 빌드할 때 복잡성이 가중됩니다. 예를 들어 개발자는 HTTP 또는 AMQP와 같은 프로토콜을 사용해 서비스 간 통신을 구현해야 하기 때문에 테스트 및 예외 처리가 더욱 복잡해집니다. 또한 시스템의 대기 시간도 길어집니다.

배포 복잡성. 수십 가지 유형의 마이크로 서비스가 있고 높은 확장성이 요구되는 애플리케이션(서비스당 많은 인스턴스를 만들고 여러 호스트 사이에서 해당 서비스의 균형을 유지해야 함)의 경우 IT 운영 및 관리 시 배포가 매우 복잡해집니다. 마이크로 서비스 기반 인프라(오케스트레이터 및 스케줄러)를 사용하지 않을 경우 이와 같이 복잡성이 증가하면 비즈니스 애플리케이션 자체보다 훨씬 더 많은 개발 작업이 필요할 수 있습니다.

원자성 트랜잭션. 여러 마이크로 서비스 간 원자성 트랜잭션은 일반적으로 가능하지 않습니다. 비즈니스 요구 사항은 여러 마이크로 서비스 간 최종 일관성을 고려해야 합니다. 자세한 내용은 멱등성 메시지 처리 문제를 참조하세요.

전역 리소스 요구 사항 증가(모든 서버 또는 호스트의 총 메모리, 드라이브, 네트워크 리소스). 모놀리식 애플리케이션을 마이크로 서비스 방식으로 교체하면 새 마이크로 서비스 기반 애플리케이션에 필요한 초기 글로벌 리소스의 양이 원본 모놀리식 애플리케이션에 필요한 인프라보다 커지는 경우가 대부분입니다. 해당 접근 방식의 원인은 세분성이 고도화되고 분산 서비스에 더 많은 전역 리소스가 필요하기 때문입니다. 하지만 모놀리식 애플리케이션을 개발할 때의 장기적 비용에 비해 애플리케이션의 특정 영역을 스케일 아웃할 수 있다는 이점과 일반적으로 낮은 리소스 비용을 고려할 경우, 일반적으로 대규모 장기 애플리케이션을 사용하기 위해 더 많은 리소스를 사용하는 것을 감수할 만합니다.

클라이언트-마이크로 서비스 간 직접 통신의 문제. 수십 개의 마이크로 서비스가 있는 대규모 애플리케이션에서는 애플리케이션에 클라이언트-마이크로 서비스 간 직접 통신이 필요할 경우 과제와 제약 사항이 있습니다. 클라이언트와 각 마이크로 서비스에서 노출한 API의 요구 사항이 서로 일치하지 않을 수 있다는 한 가지 문제가 있습니다. 클라이언트 애플리케이션에서 UI 작성을 위해 별도의 많은 요청을 해야 하는 경우도 있으며, 그럴 경우 인터넷에서 비효율적이며 모바일 네트워크에서도 실용적이지 않습니다. 따라서 클라이언트에서 백엔드 시스템에 보내는 요청 수를 최소화해야 합니다.

클라이언트-마이크로 서비스 간 직접 통신의 다른 문제는 일부 마이크로 서비스에서 웹에 적합하지 않은 프로토콜을 사용할 수 있다는 점입니다. 한 서비스는 이진 프로토콜을 사용하고 다른 서비스에서는 AMQP 메시징을 사용하는 경우가 있습니다. 이러한 프로토콜은 방화벽이 있는 경우에도 지원되며 내부에서 최적으로 사용할 수 있습니다. 일반적으로 애플리케이션은 방화벽 외부 통신을 위해 HTTP와 같은 프로토콜과 WebSocket을 사용해야 합니다.

이러한 클라이언트-서비스 간 직접 방식의 또 다른 단점은 해당 마이크로 서비스의 계약을 리팩터링하기 어렵다는 점입니다. 시간이 지남에 따라 개발자들은 시스템을 서비스에 분할하는 방식을 변경하고 싶어할 수 있습니다. 예를 들어 두 서비스를 병합하거나 하나의 서비스를 두 개 이상의 서비스로 분할할 수 있습니다. 하지만 클라이언트가 서비스와 직접 통신할 경우 이러한 리팩터링을 수행하면 클라이언트 앱과의 호환성이 깨질 수 있습니다.

아키텍처 섹션에서 언급했듯이, 마이크로 서비스를 기반으로 하는 복잡한 애플리케이션을 디자인 및 빌드할 때에는 간단한 마이크로 서비스 간 직접 통신 방법 대신 복수의 정밀 API 게이트웨이를 사용하는 것이 좋습니다.

마이크로 서비스 분할. 마지막으로, 마이크로 서비스 아키텍처에 적용하는 접근 방식과 상관없이 엔드투엔드 애플리케이션을 복수의 마이크로 서비스에 분할하는 방법을 결정해야 하는 또 다른 과제가 있습니다. 가이드의 아키텍처 섹션에서 언급된 바와 같이 몇 가지 기법과 방식을 시도할 수 있습니다. 기본적으로 개발자는 다른 영역에서 분리되고 밀접한 종속성 수가 적은 애플리케이션 영역을 식별해야 합니다. 대부분의 경우 해당 접근 방식은 사용 사례별 서비스 분할에 맞게 조정됩니다. 예를 들어 여기서 다룬 인터넷 쇼핑몰 애플리케이션에서 주문 프로세스와 관련된 모든 비즈니스 논리를 처리하는 주문 서비스가 있습니다. 또한 다른 기능을 구현하는 카탈로그 서비스와 장바구니 서비스가 있습니다. 각 서비스는 작은 역할만 갖는 것이 가장 이상적입니다. 해당 접근 방식은 클래스가 한 가지 이유로만 변경되어야 함을 나타내는 클래스에 적용되는 SRP(단일 책임 원칙)와 유사합니다. 하지만 이 경우에는 마이크로 서비스에 대한 것이므로 단일 클래스보다 범위가 큽니다. 무엇보다도, 마이크로 서비스는 자체 데이터 소스에 대한 책임을 포함하여 엔드투엔드에서 자율적이어야 합니다.

외부/내부 아키텍처 및 디자인 패턴

외부 아키텍처는 이 가이드의 아키텍처 섹션에 설명된 원칙에 따라 복수 서비스로 구성된 마이크로 서비스 아키텍처입니다. 하지만 높은 수준의 마이크로 서비스 아키텍처를 선택하는 경우에도 각 마이크로 서비스의 특징에 따라 각각 다른 패턴을 기준으로 각각의 마이크로 서비스에 대해 다른 내부 아키텍처를 사용하는 것이 일반적이며 때때로 이 방식이 적절한 경우가 있습니다. 마이크로 서비스는 다른 기술과 프로그래밍 언어를 사용할 수도 있습니다. 그림 6-2는 이러한 다양성을 나타냅니다.

그림 6-2. 외부/내부 아키텍처 및 디자인

예를 들어 eShopOnContainers 샘플에서 카탈로그, 장바구니, 사용자 프로필 마이크로 서비스는 간단합니다(기본적으로 CRUD 하위 시스템). 따라서 내부 아키텍처와 디자인이 직관적입니다. 하지만 주문 마이크로 서비스와 같이 높은 수준의 도메인 복잡성으로 비즈니스 규칙이 항상 변경되고 더욱 복잡한 다른 마이크로 서비스를 가질 수 있습니다. 이러한 사례에서는 eShopOnContainers 주문 마이크로 서비스와 같은 방식으로 DDD(Domain-Driven Design) 방식으로 정의된 마이크로 서비스 등의 특정 마이크로 서비스 내에 고급 패턴을 구현하려는 경우가 있습니다. (이러한 DDD 패턴은 나중에 eShopOnContainers 주문 마이크로 서비스 구현에 대해 설명하는 섹션에서 살펴봅니다.)

마이크로 서비스마다 다른 기술을 적용하는 또 다른 이유는 각 마이크로 서비스의 특성 때문입니다. 예를 들어 C# 등의 개체 지향 프로그래밍 언어 대신 F#과 같은 기능적 프로그래밍 언어를 사용하거나 AI 및 기계 학습 도메인을 대상으로 하는 경우 R 등의 언어를 사용하는 것이 더 좋을 수 있습니다.

중요한 점은 각 마이크로 서비스가 다른 디자인 패턴을 기준으로 다른 내부 아키텍처를 가질 수 있다는 점입니다. 모든 마이크로 서비스를 고급 DDD 패턴을 사용하여 구현할 경우 엔지니어링 업무가 과도해집니다. 마찬가지로, 비즈니스 논리가 항상 변경되는 복잡한 마이크로 서비스는 CRUD 구성 요소로 구현하지 않아야 하며, 그럴 경우 코드 품질이 떨어질 수 있습니다.

새로운 환경: 복수 아키텍처 패턴 및 다언어 마이크로 서비스

소프트웨어 설계자와 개발자가 사용하는 아키텍처 패턴은 여러가지가 있습니다. 다음은 몇 가지 예입니다(혼합 아키텍처 스타일 및 아키텍처 패턴).

• 간단한 CRUD, 단일 계층, 단일 레이어.

• 기존 N-레이어.

• 도메인 기반 디자인 N-레이어.

• 클린 아키텍처(eShopOnWeb에 사용된 것)

• CQRS(Command and Query Responsibility Segregation).

• EDA(이벤트 기반 아키텍처).

또한 ASP.NET Core Web API, NancyFx, ASP.NET Core SignalR(.NET Core 2 이상에서 사용 가능), F#, Node.js, Python, Java, C++, GoLang 등의 여러 기술과 언어로 마이크로 서비스를 빌드할 수 있습니다.

중요한 점은 모든 상황에 적합한 특정 아키텍처 패턴, 스타일 또는 특정 기술은 없다는 점입니다. 그림 6-3은 다른 마이크로 서비스에 사용할 수 있는 몇 가지 방식 및 기술(특정 순서로 표시되지 않음)입니다.

그림 6-3. 복수 아키텍처 패턴 및 다언어 마이크로 서비스 환경

다중 아키텍처 패턴 및 다언어 마이크로 서비스는 언어 및 기술을 각 마이크로 서비스의 요구에 맞게 혼합하고 일치시킬 수 있으며, 계속 서로 통신할 수 있음을 의미합니다. 그림 6-3과 같이 여러 마이크로 서비스로 구성된 애플리케이션에서는(도메인 기반 디자인 용어로 바인딩 컨텍스트 또는 간단히 자율 마이크로 서비스로서의 "하위 시스템") 각 마이크로 서비스를 다른 방식으로 구현할 수 있습니다. 각 마이크로 서비스는 애플리케이션의 특성, 비즈니스 요구 사항, 우선 순위에 따라 다른 아키텍처 패턴을 가지고 다른 언어 및 데이터베이스를 사용할 수 있습니다. 마이크로 서비스가 유사한 경우도 있습니다. 하지만 보통 각 하위 시스템의 컨텍스트 경계와 요구 사항이 다르기 때문에 일반적인 경우는 아닙니다.

예를 들어 간단한 CRUD 유지 관리 애플리케이션의 경우 DDD 패턴을 디자인 및 구현하는 것이 의미가 없을 수 있습니다. 하지만 핵심 도메인 또는 핵심 비즈니스의 경우 항상 변경되는 비즈니스 규칙으로 인한 비즈니스 복잡성에 대응하기 위해 고급 패턴을 적용해야 할 수 있습니다.

특히 여러 하위 시스템으로 구성된 대규모 애플리케이션을 처리할 경우 단일 아키텍처 패턴을 기반으로 하는 단일 최상위 아키텍처를 적용하지 않아야 합니다. 예를 들어 CQRS는 전체 애플리케이션의 최상위 아키텍처로 적용하지 않아야 하지만 특정 서비스 집합에 유용할 수 있습니다.

모든 사례에 완벽하거나 적합한 아키텍처 패턴은 없습니다. “모든 사례에 적용할 수 있는 한 가지 아키텍처 패턴”은 없습니다. 각 마이크로 서비스의 우선 순위에 따라 다음 섹션에 설명된 대로 각각에 대해 다른 방법을 선택해야 합니다.

이전다음