논리적 아키텍처 대 물리적 아키텍처

팁

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

PDF 다운로드

이 시점에서 중지하고, 논리적 아키텍처와 물리적 아키텍처 사이의 차이점을 논하고, 마이크로 서비스 기반 애플리케이션의 디자인에 어떻게 적용되는지를 설명하는 것이 유용합니다.

우선, 마이크로 서비스를 빌드하는데 특정 기술이 필요하지 않습니다. 예를 들어, 마이크로 서비스 기반 아키텍처를 만드는데 Docker 컨테이너가 필수는 아닙니다. 이러한 마이크로 서비스는 일반 프로세스로도 실행할 수 있습니다. 마이크로 서비스는 논리적 아키텍처입니다.

또한, 마이크로 서비스가 물리적으로 단일 서비스, 프로세스 또는 컨테이너로 구현될 수 있는 경우에도(간단히 하기 위해, 이것이 eShopOnContainers의 초기 버전에서 취한 접근법), 수십 또는 수백의 서비스로 구성된 크고 복잡한 애플리케이션을 빌드할 때 비즈니스 마이크로 서비스와 물리적 서비스 또는 컨테이너 간의 패리티는 모든 경우에 필요한 것은 아닙니다.

여기에 애플리케이션의 논리적 아키텍처와 물리적 아키텍처 사이에 차이가 있습니다. 시스템의 논리적 아키텍처와 논리적 경계는 반드시 일대일로 물리적 또는 배포 아키텍처에 매핑되지 않습니다. 그것은 발생할 수도 있지만, 종종 그렇지 않을 때도 있습니다.

특정 비즈니스 마이크로 서비스 또는 경계 컨텍스트를 식별했을 수도 있지만, 비지니스 마이크로 서비스마다 하나의 서비스(예: ASP.NET Web API) 또는 단일 Docker 컨테이너를 만들어서 구현하는 것이 언제나 가장 좋은 방법이라는 것을 의미하지는 않습니다. 각 비즈니스 마이크로 서비스가 단일 서비스 또는 컨테이너를 사용하여 구현되어야 한다는 규칙을 갖는 것은 너무 엄격합니다.

따라서 비즈니스 마이크로 서비스 또는 경계 컨텍스트는 물리적 아키텍처와 일치하거나 또는 그렇지 않을 수도 있는 논리적 아키텍처입니다. 중요한 점은 비즈니스 마이크로 서비스 또는 경계 컨텍스트는 코드와 상태를 독립적으로 버전 관리, 배포 및 크기를 조정할 수 있도록 자율적이어야 합니다.

그림 4-8에서 볼 수 있듯이, 카탈로그 비즈니스 마이크로 서비스는 여러 서비스 또는 프로세스로 구성될 수 있습니다. 이들은 여러 ASP.NET Web API 서비스 또는 HTTP 또는 다른 프로토콜을 사용하는 다른 종류의 서비스일 수 있습니다. 더 중요한 것은, 이들 서비스가 동일한 비즈니스 도메인과 관련하여 응집력을 갖는 한 동일한 데이터를 공유할 수 있습니다.

그림 4-8. 여러 물리적 서비스가 있는 비즈니스 마이크로 서비스

웹 API 서비스가 Search 서비스와 동일한 데이터를 대상으로 하기 때문에 예제의 서비스는 동일한 데이터 모델을 공유합니다. 따라서 비즈니스 마이크로 서비스의 실제 구현에서는 해당 기능을 분리하여 필요에 따라 각 내부 서비스를 확장 또는 축소할 수 있습니다. 아마도 웹 API 서비스는 일반적으로 검색보다 많은 인스턴스가 필요하거나 또는 그 반대일 수 있습니다.

즉, 마이크로 서비스의 논리적 아키텍처가 항상 물리적 배포 아키텍처와 일치하지는 않습니다. 이 가이드에서는 마이크로 서비스에 대해 언급할 때마다 하나 이상의 물리적 서비스에 매핑될 수 있는 비즈니스 또는 논리적 마이크로 서비스를 의미합니다. 대부분의 사례에서 이것은 단일 서비스이지만 더 많을 수도 있습니다.

이전다음