논리 아키텍처와 물리적 아키텍처 비교

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

시작하려면 마이크로 서비스를 빌드할 때 특정 기술을 사용할 필요가 없습니다. 예를 들어 Docker 컨테이너는 마이크로 서비스 기반 아키텍처를 만들어야 하는 것은 아닙니다. 이러한 마이크로 서비스는 일반 프로세스로 실행될 수도 있습니다. 마이크로 서비스는 논리 아키텍처입니다.

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

여기서 애플리케이션의 논리 아키텍처와 물리적 아키텍처 간에 차이가 있습니다. 시스템의 논리적 아키텍처와 논리적 경계가 반드시 물리적 또는 배포 아키텍처에 일대일로 매핑되는 것은 아닙니다. 그것은 일어날 수도 있지만, 자주 일어나지는 않습니다.

비즈니스 마이크로서비스 또는 바운디드 컨텍스트(Bounded Context)를 식별했더라도, 이를 구현하는 최선의 방법이 항상 각 비즈니스 마이크로서비스를 위한 단일 서비스(예: ASP.NET Web API) 또는 단일 Docker 컨테이너를 만드는 것만은 아닙니다. 단일 서비스 또는 컨테이너를 사용하여 각 비즈니스 마이크로 서비스를 구현해야 한다는 규칙이 너무 엄격합니다.

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

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

그림 4-8. 여러 물리적 서비스를 사용하는 비즈니스 마이크로 서비스

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

즉, 마이크로 서비스의 논리적 아키텍처가 항상 물리적 배포 아키텍처와 일치할 필요는 없습니다. 이 가이드에서는 마이크로 서비스를 언급할 때마다 하나 이상의 (물리적) 서비스에 매핑할 수 있는 비즈니스 또는 논리적 마이크로 서비스를 의미합니다. 대부분의 경우 단일 서비스이지만 더 많을 수 있습니다.