다음을 통해 공유

마이크로서비스 디자인 패턴

Azure Cloud Services

마이크로 서비스의 목표는 애플리케이션을 독립적으로 배포할 수 있는 소규모 자율 서비스로 분해하여 애플리케이션 릴리스의 속도를 높이는 것입니다. 마이크로 서비스 아키텍처는 몇 가지 과제도 제공합니다. 여기에 표시된 디자인 패턴은 이러한 문제를 완화하는 데 도움이 될 수 있습니다.

마이크로 서비스 디자인 패턴

Ambassador 를 사용하여 모니터링, 로깅, 라우팅 및 보안(예: TLS)과 같은 일반적인 클라이언트 연결 작업을 언어에 구애받지 않는 방식으로 오프로드할 수 있습니다. 앰배서더 서비스는 종종 사이드카로 배포됩니다(아래 참조).

손상 방지 계층 은 새 애플리케이션과 레거시 애플리케이션 간의 외관을 구현하여 새 애플리케이션의 디자인이 레거시 시스템에 대한 종속성에 의해 제한되지 않도록 합니다.

프런트 엔드의 백 엔드는 데스크톱 및 모바일과 같은 다양한 유형의 클라이언트에 대해 별도의 백 엔드 서비스를 만듭니다. 이렇게 하면 단일 백 엔드 서비스가 다양한 클라이언트 유형의 충돌하는 요구 사항을 처리할 필요가 없습니다. 이 패턴은 클라이언트별 문제를 구분하여 각 마이크로 서비스를 단순하게 유지하는 데 도움이 될 수 있습니다.

Bulkhead 는 각 워크로드 또는 서비스에 대한 연결 풀, 메모리 및 CPU와 같은 중요한 리소스를 격리합니다. 격벽을 사용하면 단일 워크로드(또는 서비스)가 모든 리소스를 사용할 수 없어 다른 리소스가 부족합니다. 이 패턴은 하나의 서비스로 인한 연속 오류를 방지하여 시스템의 복원력을 높입니다.

게이트웨이 집계는 여러 개별 마이크로 서비스에 대한 요청을 단일 요청으로 집계하여 소비자와 서비스 간의 수다를 줄입니다.

게이트웨이 오프로드를 사용하면 각 마이크로 서비스가 SSL 인증서 사용과 같은 공유 서비스 기능을 API 게이트웨이로 오프로드할 수 있습니다.

게이트웨이 라우팅은 단일 엔드포인트를 사용하여 요청을 여러 마이크로 서비스로 라우팅하므로 소비자는 별도의 여러 엔드포인트를 관리할 필요가 없습니다.

메시징 브리지 는 서로 다른 메시징 인프라로 빌드된 서로 다른 시스템을 통합합니다.

Sidecar 는 애플리케이션의 도우미 구성 요소를 별도의 컨테이너 또는 프로세스로 배포하여 격리 및 캡슐화를 제공합니다.

Strangler Fig 는 특정 기능을 새 서비스로 점진적으로 대체하여 애플리케이션의 증분 리팩터링을 지원합니다.

Azure 아키텍처 센터에서 클라우드 디자인 패턴의 전체 카탈로그는 클라우드 디자인 패턴을 참조하세요.

다음 단계