마이크로 서비스에서 다 대다 협회

현재 두 개의 마이크로 서비스가 있습니다. 우리는 그들을 전화 할게 A하고 B.

마이크로 서비스 하의 데이터베이스 A에는 다음 표가 있습니다.

A
|-- users

마이크로 서비스 하의 데이터베이스 B에는 다음 표가 있습니다.

B
|-- trackers

요구 사항 상태 users와 trackers다 대다 관계를 가지고있다.

마이크로 서비스 아키텍처 내에서 올바르게 처리하는 방법을 모르겠습니다.

이 세 가지 방법 중 하나가 작동하는 것을 볼 수 있습니다.

1. user_trackers표 microservice에 추가됩니다 A. A가에 테이블을 포함하는 "외부 키"가입이 비슷한 역할을 users하고 trackers.
2. owners표 microservice에 추가됩니다 B. 이 테이블은 다형성 조인 테이블과 유사하게 작동합니다. 이것은 모든 서비스가 트래커와의 연결을 만들 수있게합니다. 이것은 다음과 같이 보일 수 있습니다. B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. 에 대한 기록 유지 users및 trackers각 microservice에 있습니다. 그것들을 일종의 pubsub 시스템과 동기화하십시오.

원래 트랜잭션 2를 유지하는 것을 좋아했기 때문에 옵션 2를 사용하려고했습니다. 트래커를 만들어 원자 적으로 연결할 수 있습니다. 그러나 마이크로 서비스의 범위를 벗어난 것으로 보입니다 B. 마이크로 B서비스가 A연관을 작성하려는 마이크로 서비스 관리를 왜해야 합니까?

여기에 내가 알지 못하는 좋은 패턴이 있다고 생각합니다. 내가 배치 한 옵션 중 어떤 것이 의미가 있습니까? 더 이해하기 쉬운 다른 옵션이 있습니까?

우선, 도메인 설명부터 시작하겠습니다. 당신은 그것이 무엇인지 언급하지 않았습니다 (나는 추측 할 수 있지만 추측 일뿐입니다). 그런 다음 가치 사슬 분석 또는 비즈니스 기능 매핑을 사용하여 분해하려고합니다 . 그 후에야 구현에 대해 생각할 것입니다.

문제를 고려할 때 가장 먼저 생각해야 할 것은 단순히 서로의 데이터가 필요하기 때문에 서비스 경계가 잘못되었다는 것입니다. 당신은 분산 된 monolith 로 끝나고 싶지 않습니까?

두 번째는 도메인을 충분히 잘 사용하지 못했을 것입니다. 어떤 개념이 users표로 표시됩니까? 그것은 A는 registered user등록에 필요한 정보와 행동은 모두와 함께,? 의사 소통을위한 올바른 개념 trackers이라고 생각하십니까 (무엇이든)? 따라서 내가 올바르게 선택했다면, 옵션 2는 바로 owner도메인에 훨씬 가까운 개념을 도입하는 것 입니다. 실제로 그렇다면 옵션 2도 사용합니다.

그러나 마이크로 서비스 B의 범위를 벗어난 것 같습니다. 마이크로 서비스 B가 마이크로 서비스 A가 연관을 작성하도록 관리해야하는 이유는 무엇입니까?

그것은 경계에 관한 것입니다. 엔터티를 중심으로 마이크로 서비스를 만들고 싶습니다. 여기에서 SOA 가 계층화 된 서비스 아키텍처로 실패했습니다 . 더 나은 방법은 일부 비즈니스 기능을 나타내는 서비스를 작성하여 데이터와 동작을 모두 캡슐화하는 것입니다. 보다 실용적인 관점에서 비즈니스 프로세스 또는 사용 사례를 중심으로 서비스를 작성하는 것입니다. 예를 들어, 하나의 사용자 등록 서비스가있을 수 있습니다. 여기에는 사용자 등록에 필요한 사용자 데이터 및 동작이 포함됩니다. 따라서 개념은 user자연스럽게 형성되며 서비스 A에만 속합니다. 그리고 다음으로 넘어갑니다 . 서비스에 대해 생각하는 다른 방법은 맥락이 있습니다. 서비스와 제한된 컨텍스트를 정렬하는 것이 좋습니다.

사용자가 등록되면 UserCreated이벤트가 발생할 수 있습니다. 내가 생각하는 두 번째 서비스는 그것에 관심이 있습니다. 따라서 그것을 받으면 완전히 다른 엔티티, 즉 Owner엔티티 (어느 쪽이든)를 만들 수 있습니다 . 그것과 tracker엔티티 사이에 많은 흥미로운 협력이 있다는 것을 확신하십시오 -단일 서비스로 유지하십시오.

옵션 3에 매우주의하십시오. 데이터를 복사하면 기능이 따릅니다. 단단히 결합됩니다. CQRS 용어 로 다루지 말고 이벤트를 통한 서비스 간 데이터 동기화에 관한 것이 아닙니다.

Zapadlo의 답변에는 많은 좋은 정보와 추론이 있습니다. 여기에 귀하의 문제와 그 답변에 대한 조언을 쉽게 처리 할 수 ​​있도록 약간의 실용적인 조언을 추가하겠습니다.

디자인 문제를 해결하는 방법은 데이터베이스 구조와 구조에 대한 새로운 요구 사항을 충족시키는 방법입니다. 이는 데이터 모델에서 서비스 디자인을 구축하고 있음을 의미합니다. 예를 들어, 내가 보지 못하는 것은 사용자와 트래커 간의 관계에 액세스하거나 사용하는 방법입니다.

서비스 디자인에서 인터페이스의 구조는 디자인에서 가장 중요한 것입니다. 실제로, 구현은 특히 마이크로 서비스의 경우에 비해 거의 관련이 없습니다. 그 이유는 일단 서비스를 설치하면 서비스에 대한 모든 종속성이 인터페이스에만 존재해야하기 때문입니다. 제대로 이해하면 소비자없이 구현을 완전히 다시 작성할 수 있어야합니다. 이것이 자율성의 주요 이점입니다. 아무도 당신이 그것을 어떻게 만들 었는지 신경 쓰지 않습니다. 의사 소통 방식대로 작동하기 만하면됩니다.

누구나 데이터베이스에서 어떻게 보이는지 또는 원하는 위치를 결정하기 전에이 정보가 어떻게 사용되는지 설명해야합니다. 이것이 서비스를 통해 노출되거나 분석을 위해 섞고 싶은 일종의 데이터입니까?

참고로, 거의 모든 비용으로 양방향 종속성을 피할 수 있습니다. 의존성이 있다면, 한 쪽만 다른쪽에 대해 알고 싶어합니다. 일단 종속성이 양방향에 있으면 서비스는 본질적으로 원자 단위가됩니다.

많은 부분이 도메인 자체에 적용됩니다. 트래커가없는 사용자가 이해가되지 않으면 사용자 서비스는 트래커에 대해 알아야합니다. 트래커에 사용자가 있어야하는 경우 트래커는 사용자에 대해 알아야합니다. 여러 소유자가있는 트래커를 보유하거나 한 사용자에서 다른 사용자로 트래커를 전송할 수있는 것과 같은 것이이 정보가 의미가있는 경우이 정보는 또 다른 서비스에 속할 수 있습니다.

질문 : 왜 데이터가 데이터 테이블과 분리되어 있습니까?

옵션 3을 사용하는 경향이 있습니다. 서비스는 완전히 분리되어 있으며 응답해야 할 각 질문에 답변 할 수 있습니다. 또한, 그들은 훨씬 더 탄력적입니다. 그러나 이벤트가 누락되면 서비스가 비 동기화 될 수 있지만 최종 일관성을 통해 해결할 수 있습니다.

또한 두 서비스를 병합하는 것을 고려할 수 있습니다. 두 서비스가 서로에 대해 알지 못하고 대답 할 수없는 경우 단일 도메인의 일부이므로 병합 할 것입니다.