마이크로 서비스 아키텍처 공유 도메인 모델


12

마이크로 서비스 아키텍처를 사용하는 스프링 부트 애플리케이션이 있다고 가정하자. 각 서비스에는 고유 한 도메인 모델이 있지만 각 서비스는 사용자 도메인 개체를 참조해야합니다. 이 문제를 해결하는 가장 좋은 방법은 무엇입니까? 각 서비스마다 userId 만있는 것이 더 좋으며 필요한 경우 사용자 서비스에 사용자 세부 정보를 요청하거나 모든 마이크로 서비스에 대해 공유 도메인 라이브러리를 갖는 것이 더 좋습니까?


1
가능할 때마다 항상 단일 진실 소스 를 갖는 것이 좋습니다 .
Robert Harvey

@RobertHarvey 이것이 폴리 글 로트 지속성에 어떤 영향을 미칩니 까? 모든 도메인 객체에 대해 공유 라이브러리를 사용한다는 것이 여전히 각 마이크로 서비스가 자체 데이터베이스를 가질 수 있음을 의미합니까?
user1176999

그 용어를 이전에 들어 본 적이 없지만 그 정의를 살펴보면 사용자가 데이터 저장소에 어떤 기술을 선택했는지를 제외하고는 폴리 글 로티 지속성에 전혀 영향을 미치지 않는다고 말하고 싶습니다.
Robert Harvey

답변:


12

확장 성, 느슨한 결합 및 각 서비스를 쉽게 독립적으로 수정할 수있는 이점을 위해 마이크로 서비스를 이용했다면 가능한 한 최대로 유지해야합니다.

전반적인 아키텍처

최선의 접근 방식은 다음과 같습니다.

  • 일반 사용자 정보 관리를위한 마이크로 서비스가 있어야합니다.
  • 마이크로 서비스 별 사용자 정보 (예 : 프로필, 인증, 환경 설정)를 각 마이크로 서비스에 보관하십시오 (일반 ID의 참조 사용)

추가 자료 :

  • 이 기사에서는 이러한 종류의 아키텍처와 이론적 근거를 특정 권한 부여 사례와 함께 잘 설명합니다.
  • 이 기사에서는 모든 서비스가 동일한 저장소에 액세스하는 것을 피하기 위해 사용자 ID 관리를위한 과제와 솔루션에 대해 설명합니다.
  • 이 기사에서는 JWT를 사용하여 서비스간에 사용자의 신원을 전달하는 방법에 대해 설명합니다 (ID 토큰에 일부 기본 정보가 제공 될 수 있음) 정보).

코드 공유

위의 솔루션에 동의하면 사용자 마이크로 서비스 (사용자를위한 캡슐화 도메인 모델)가 있으며 다른 모든 서비스는 동일한 마이크로 서비스의 소비자입니다. 질문은 당신이 원하는지 아는 것입니다.

  • 유연하고 뚜렷한 릴리스주기를 허용하는 강력한 분리 규칙에 따라 소비자 코드를 재창조하는 각 마이크로 서비스,
  • 또는이 기본 정보가 "섀시"인프라 패턴 의 확장이라는 점을 고려하여 라이브러리의 일부로 소비자 코드를 공유 할 수 있습니다.

이 코드 공유 주제에 대해 의견이 분분한 의견 전쟁이 있기 때문에 나는 분명한 입장을 취하지 않을 것이며, 나는 객관적인 입장을 취할 입장에 있다고 생각하지 않습니다. 이미 몇 가지 추가 정보가 있습니다.

  • 이 기사에서는 최상의 솔루션이 없다고 생각하며 모두 목표에 달려 있습니다.
  • 이 기사의 입장은 코드 공유가 강력한 결합을 생성하고 코드 공유가 일부 시너지를 가져올 수있는 경우에만 나쁘다는 것입니다
  • 이 기사 (마이크로 서비스를 대규모로 구현 한 사람들)는 별도의 빌드가 필요하며 이전 코드의 잠재적 인 폐기 문제가 있다고 주장합니다. 에 대한 공유 라이브러리 데 소요되는 이러한 좋은 관행을 방지하지 않습니다 고체 버전 관리를합니다.

그것에 대한 내 자신의 견해는 밀접한 결합을 피하기 위해 사용자 공급자와 사용자 소비자 사이에 코드를 공유해서는 안된다는 것입니다. 그러나 강력한 버전 관리 기능이있는 경우 소비자간에 사용자 소비 코드를 공유해야합니다. 이 방법에는 몇 가지 장점이 있습니다.

  • 버전이 독립적 인 사용자 제공 업체와 호환되는 한 다른 버전의 공유 사용자 소비 코드로 다른 사용자 소비 마이크로 서비스를 빌드 할 수 있습니다. 휠을 재창조하는 것과 동일한 유연성이지만 더 높은 생산성.
  • 소비자에게 영향을주지 않고 사용자 공급자 서비스를 독립적으로 변경할 수 있습니다.
  • 소비 측면에서 버그가 발견되면 버그를 한 번 수정하고 모든 소비자를 가장 적합한 것으로 배포 할 수 있습니다 (버전 관리 덕분에). 이는 더 높은 서비스 품질로 이어질 수도 있습니다.
  • 어떤 이유로 사용자 제공자 API를 업데이트해야하는 경우 업데이트 된 사용자 소비를보다 신속하게 배치 할 수 있습니다. 전환하는 동안 이전 및 새 공급자 서비스를 활성 상태로 유지하면 이러한 공유 가능성으로 인해 이전 버전의 소비자 제공 업체를보다 신속하게 폐기 할 수 있습니다.

1

가능하다면 공유 라이브러리를 피할 것입니다. 각 서비스에 필요한 사용자 속성이 무엇인지 자문 해보십시오. 지원 도메인에는 종종 userId 만 있으면되므로 사용자를 둘러싼 대부분의 동작이 수행되는 핵심 도메인이 종종 있습니다.

서비스가 사용자에 대한 다른 세부 사항을 필요로하는 경우, 몇 가지 제안을 살펴 가지고 여기에 이러한 상황을 처리하는 방법에 대한을

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.