마이크로 서비스에서 엔터티를 식별하는 데 데이터베이스 기본 키를 사용해야합니까?

Dec 12 2020

서비스 A와 서비스 B라는 두 개의 마이크로 서비스가 있습니다.

서비스 A는 전체 고객 데이터를 소유하고 서비스 B에는이 데이터의 작은 하위 집합이 필요합니다 (일부 대량로드를 통해 서비스 A에서 가져옴).

두 서비스 모두 고객을 자체 데이터베이스에 저장합니다.

서비스 B가 추가 데이터 (예 : GET / customers / {id})를 얻기 위해 서비스 A와 상호 작용해야하는 경우 두 서비스간에 공유되는 고유 식별자가 분명히 필요합니다.

ID가 GUID이기 때문에 서비스 B에서 레코드를 만들 때 서비스 A의 PK를 간단히 사용할 수 있습니다. 따라서 두 PK가 일치합니다.

그러나 이것은 매우 깨지기 쉬운 것 같습니다. 한 가지 옵션은 '외부 ID'(또는 '소스 ID')를 서비스 B에 별도의 필드로 저장하고이를 사용하여 서비스 A와 상호 작용하는 것입니다. 언젠가는 GUID가 아닐 수도 있으므로 이것은 문자열 일 것입니다.

이에 대한 '모범 사례'가 있습니까?

최신 정보

그래서 좀 더 조사를했고 몇 가지 관련 토론을 찾았습니다.

REST API URL에 기본 키를 노출해야합니까?

REST API에서 데이터베이스 ID를 클라이언트에 노출하는 것이 나쁜 습관입니까?

슬러그를 기본 키로 사용

결론

서비스 A와 B에서 고객의 기본 키를 동일하게 유지하려는 내 생각이 잘못되었다고 생각합니다. 이 때문입니다:

분명히 PK는 서비스 구현에 따라 다르므로 UUID 대 자동 증가 INT와 같이 완전히 호환되지 않을 수 있습니다.
호환성을 보장 할 수 있더라도 두 엔터티가 모두 '고객'이라고 불리기는하지만 사실상 두 가지 (잠재적으로 매우 다른) 개념이며 서비스 A와 서비스 B는 모두 자체 '고객'레코드를 '소유'합니다. 당신은 무엇을 할 수 있지만하고 싶은 것은 이러한 서비스를 통해 일부 고객 데이터를 동기화 할 수 있습니다.

따라서 이제 두 서비스 중 하나가 고유 한 ID (필자의 경우 PK GUID)를 통해 고객 데이터를 노출 할 수 있으며 한 서비스가 다른 서비스에서 추가 고객 데이터를 가져와야하는 경우 다른 서비스 식별자 / 키를 저장하고이를 사용해야한다고 생각합니다. 따라서 본질적으로 '외부 ID'또는 '소스 ID'아이디어로 돌아가지만 아마도 '서비스 B ID'로 더 구체적 일 것입니다.

답변

1 AnkitVijay Dec 13 2020 at 04:57

데이터 소스와 디자인에 따라 약간 달라진다고 생각합니다. 그러나 공유를 피하고 싶은 한 가지는 외부 서비스에 대한 GUID 또는 자동 증분 정수인 기본 키입니다. 이는 서비스의 내부 세부 정보이며 다른 서비스가 의존해야하는 사항이 아닙니다.

차라리 다른 서비스와 비즈니스 전체에서 더 잘 이해되는 외부 ID를 갖고 싶습니다. 고유 한 고객 번호, 주문 번호 또는 정책 번호 일 수 id있습니다. "비즈니스 ID"로 간주 할 수도 있습니다. 또한 명심해야 할 한 가지는 외부 ID가 최종 사용자에게도 노출 될 수 있다는 것입니다. 따라서 이벤트 기반 설계를 사용하는지 또는 서비스가 API를 통해 통신하는지에 관계없이 전체 조직 및 서비스에서 "엔티티"를 식별하는 유비쿼터스 방법입니다. DB ID는 인프라 또는 리포지토리에만 노출합니다. 그 외에도 비즈니스 / 외부 ID 일뿐입니다.