마이크로 서비스 및 데이터 복제

새 응용 프로그램을 작성 중이며 마이크로 서비스 아키텍처에 대해 읽었습니다. 아키텍처 자체는 개발, 배포 및 수명주기 관리 관점에서 많은 의미가 있습니다. 그러나 한 가지 문제는 마스터 데이터를 처리하는 방법과 관련이있었습니다.

예를 들어 Sales 앱과 Ticketing 앱이라는 두 가지 앱이 있습니다. 이 두 앱 모두 자체 마이크로 서비스로 구축되었다고 가정합니다. 그러나 두 앱을 모두 배포 할 때 (Sales는 MongoDB를 사용하고 Ticketing은 MariaDB를 사용한다고 별도로 배포한다고 가정 할 경우) Accounts, Products와 같은 동일한 마스터 데이터 인스턴스에 액세스해야합니다. 즉, 지정된 마스터 데이터 엔터티 (예 : 영업 앱일 수있는 계정의 경우) 및 이해 당사자 (예 : 발권 앱은 계정에 대한 정보가 있어야 함)에 대한 소유자 앱이 있음을 의미합니다.

이를 달성 할 수있는 여러 가지 방법이 있습니다.-마스터에서 이해 당사자로의 데이터 복제-이해 당사자에서 마스터로 동기 읽기 (마이크로 서비스 아키텍처 패러다임에서는 동기화 종속성이 권장되지 않음)-자체 중앙 저장소

또한 계정 내에서도 영업 및 발권에 공통적 인 핵심 부분 (예 : 계정 이름, 주소 등)이있을 수 있습니다. 그러나 계정의 일부 측면은 판매와 관련이 있고 다른 일부는 발권과 관련이있을 수 있습니다.

위에서 언급 한 옵션 중 하나에 대한 생각 / 모범 사례 / 의견은 무엇입니까?

서비스 버스를 사용하여 마이크로 서비스 아키텍처를 성공적으로 구축 한 팀의 일원이었습니다.

처음에 우리는 마이크로 서비스와 이벤트 중심 아키텍처를 통해 기본 공유 데이터 ball-of-mud 데이터베이스를 수정할 수 있다고 생각했습니다 .

우리가 배운 것은 마이크로 서비스와 이벤트 중심 아키텍처 가 기본 공유 데이터 볼-오브 머드 데이터베이스를 제거 해야한다는 것입니다.

공유 데이터는 마이크로 서비스와 잘 어울리지 않는다고 생각합니다. 나에게는 엄청나게 어렵습니다. 서비스가 서로의 데이터 를 볼 수 없도록하는 것이 좋습니다 . 쿼리 할 수 ​​없으면 실수로 종속성을 도입 할 수 없습니다.

당신이 경우 어떻게 데이터를 공유, 확실히 하나 개의 서비스는 지금까지 기록을 소유 할 수있다; 레코드에 기록하는 유일한 서비스이며 동일한 데이터를 가진 다른 사용자에게는 읽기 전용 액세스 권한이 있어야합니다.

불행히도,이 적은 양의 공유로도 서비스간에 상당한 연결이 발생합니다. 한 서비스에서 해당 형태의 데이터를 원하지 않으면 어떻게됩니까? 아마도 집계를 원할 것입니다. "소유자 / 쓰기"서비스를 통해 다른 서비스의 이점을 위해 집계 데이터를 작성할 수 있습니까? 나는 조언하지 않을 것이다.

소유자가 데이터를 다른 모양으로 유지하려면 어떻게해야합니까? 그런 다음 모든 리더 서비스를 업데이트해야합니다. 그것은 유지 보수의 악몽입니다.

우리가 가진 최고의 솔루션은 데이터의 상당한 복제 및 비정규 화였습니다. 마이크로 서비스는 자신이 관심을 갖고있는 자체 데이터 사본을 유지했습니다.

메시지는 종종 처리하기에 충분한 수반되는 데이터와 함께 게시되었습니다.

예를 들어, 우편 발송 서비스가 무언가를 게시해야하는 경우 고객 주소 변경을 추적해야 할 수도 있습니다. 그러나 "출하 준비된 품목"메시지에 메시지 데이터의 일부로 대상 주소가 포함되어 있으면 발송 서비스는 더 이상 고객과 관련된 주소 변경을 추적 할 필요가 없습니다. 발송 될 때 품목과 관련된 특정 시점 주소.

동기화 된 데이터로 솔루션을 설계하는 방법을 제안 할 수 없습니다. 우리의 데이터 솔루션은 "최종 일관성"이라는 아이디어를 기반으로 구축되었습니다.

따라서 고객이 주소를 업데이트하면 주소 서비스는 UI의 초기 명령을 처리합니다. 데이터가 올 바르면 다른 모든 관심 서비스에 "고객 주소 업데이트 됨"(전체 주소가 데이터로 첨부 됨)을 알리는 이벤트를 게시합니다. 이러한 서비스는 관심있는 데이터 부분으로 자체 데이터 저장소를 업데이트합니다.

아이디어는 서비스가 중요한 조치를 취해야 할 때마다 독립적으로 추적되거나 응답하는 메시지의 일부로 올바르게 작동하기에 충분한 최신 정보 사본을 가져야한다는 것입니다.

공유 데이터 스토리지는 마이크로 서비스 아키텍처와 반대됩니다. 요점은 계정이있는 경우 계정을 처리하는 서비스가 있어야하며 서비스를 철저히하는 것 외에 이러한 계정과 상호 작용하는 다른 방법이 없어야한다는 것입니다. 공통 스토리지를 공유하고 스토리지 메커니즘, 유효성 검증 또는 기타 제한 조건을 두 서비스 모두에서 구현해야하는 경우 마이크로 서비스는 독립적이지 않습니다. 실제로 이것은 결코 일어나지 않으며 곧 두 응용 프로그램이 심각한 변경으로부터 방지됩니다.

따라서 서비스를 데이터와 같은 유일한 데이터 액세스 방법으로 사용하십시오 (예 : 계정). 다른 서비스에서 기능을 구현하려면 계정 서비스를 변경해야 할 수도 있습니다. 모든 서비스에 특정한 논리가 해당 서비스에 있어야하며 가능한 한 적은 세부 사항이 Accounts 마이크로 서비스에 들어가야한다는 것을 기억하십시오.

동일한 마스터 데이터 인스턴스 (예 : 계정, 제품)에 액세스해야합니다.

동일하지 않습니다. 각 마이크로 서비스는 계정, 제품 등에 대한 자체 매핑을 수행해야합니다. 각 마이크로 서비스는 엔터티에 대해 다른 방식으로 작업 할 것으로 가정합니다.

Domain Driven Design에서는 공통입니다. 각 경계 컨텍스트 (같은 앱에서!)가 동일한 방식으로 동일한 엔티티를 다른 방식으로 매핑 할 수 있습니다.

자세한 정보가 필요하면 Building Microservices : Designing Fine-Grained Systems 책을 추천합니다 .

마스터 세트를 기반으로 골격 레코드의 개념을 고려 했습니까?

예를 들어 한 마이크로 서비스는 계정을 처리하고 다른 마이크로 서비스는 제품을 처리합니다. 세 번째는 도메인 특정 목적을 위해 두 가지 레코드를 유지할 수 있습니다.