마이크로 서비스 및 데이터베이스 조인

모 놀리 식 애플리케이션을 마이크로 서비스로 분할하는 사람들을 위해 데이터베이스를 분리하는 수수께끼를 어떻게 처리하고 있습니까? 내가 작업 한 일반적인 애플리케이션은 성능과 단순성을 위해 많은 데이터베이스 통합을 수행합니다.

논리적으로 구별되는 두 개의 테이블 (원하는 경우 제한된 컨텍스트)이 있지만 해당 데이터의 대량에 대해 집계 처리를 자주 수행하는 경우 모놀리스에서 개체 방향을 피하고 대신 데이터베이스의 표준을 사용합니다. 집계 된 뷰를 앱 계층으로 다시 반환하기 전에 데이터베이스의 데이터를 처리하는 JOIN 기능입니다.

이러한 데이터를 데이터베이스가 아닌 API를 통해 데이터를 '조인'해야하는 마이크로 서비스로 분할하는 것을 어떻게 정당화 할 수 있습니까?

저는 Sam Newman의 Microservices 책을 읽었으며 Monolith 분할에 대한 장에서 "Breaking Foreign Key Relationships"의 예를 제공합니다. 여기서 그는 API에서 조인을 수행하는 것이 더 느릴 것임을 인정합니다. 어쨌든 응용 프로그램이 충분히 빠릅니다. 이전보다 느리다는 것이 중요합니까?

이것은 약간 멍청한 것 같습니까? 사람들의 경험은 무엇입니까? API 조인이 제대로 작동하도록하기 위해 어떤 기술을 사용 했습니까?

• 성능이나 지연 시간이 그다지 중요하지 않은 경우 (예, 항상 필요한 것은 아닙니다) 필요한 추가 데이터를 쿼리하기 위해 간단한 RESTful API를 사용하는 것이 좋습니다. 다른 마이크로 서비스에 대한 여러 호출을 수행하고 하나의 결과를 반환해야하는 경우 API Gateway 패턴을 사용할 수 있습니다 .

• Polyglot 지속성 환경 에서 중복성을 갖는 것은 완벽 합니다. 예를 들어 마이크로 서비스에 메시징 큐를 사용하고 무언가를 변경할 때마다 "업데이트"이벤트를 보낼 수 있습니다. 다른 마이크로 서비스는 필요한 이벤트를 수신하고 데이터를 로컬에 저장합니다. 따라서 쿼리하는 대신 특정 마이크로 서비스에 적합한 스토리지에 필요한 모든 데이터를 보관합니다.

• 또한 캐싱을 잊지 마세요. :) Redis 또는 Memcached 와 같은 도구를 사용 하여 다른 데이터베이스를 너무 자주 쿼리하지 않도록 할 수 있습니다 .

서비스가 다른 서비스의 특정 참조 데이터에 대한 읽기 전용 복제 사본을 갖는 것은 괜찮습니다.

이를 감안할 때 모 놀리 식 데이터베이스를 마이크로 서비스로 리팩터링하려고 할 때 (재 작성과 반대)

• 서비스에 대한 db 스키마 생성
• 해당 스키마에서 버전이 지정된 * 뷰 **를 생성하여 해당 스키마의 데이터를 다른 서비스에 노출
• 이러한 읽기 전용 뷰에 대해 조인

이렇게하면 다른 응용 프로그램을 중단하지 않고 테이블 데이터 / 구조를 독립적으로 수정할 수 있습니다.

뷰를 사용하는 대신 트리거를 사용하여 한 스키마에서 다른 스키마로 데이터를 복제 할 수도 있습니다.

이것은 올바른 방향으로 점진적으로 진행되고 구성 요소의 이음새를 설정하며 나중에 REST로 이동할 수 있습니다.

*보기를 확장 할 수 있습니다. 브레이킹 체인지가 필요한 경우 동일한 뷰의 v2를 만들고 더 이상 필요하지 않은 경우 이전 버전을 제거합니다. ** 또는 테이블 반환 함수 또는 Sprocs.

CQRS --- Command Query Aggregation Pattern은 Chris Richardson에 따라 이에 대한 답입니다. 각 마이크로 서비스가 자체 데이터 모델을 업데이트하고 이전 마이크로 서비스에서 필요한 조인 데이터를 갖는 구체화 된 뷰를 업데이트 할 이벤트를 생성하도록합니다.이 MV는 NoSql DB 또는 Redis 또는 쿼리에 최적화 된 Elasticsearch 일 수 있습니다. 이 기술은 확실히 나쁘지 않은 최종 일관성으로 이어지고 실시간 애플리케이션 측 조인을 피합니다. 이 답변을 바랍니다.

운영 및보고에 대해 사용 영역에 대한 솔루션을 분리합니다.

다른 마이크로 서비스의 데이터를 필요로하는 단일 양식에 데이터를 제공하기 위해 작동하는 마이크로 서비스의 경우 (이는 운영 사례입니다) API 조인을 사용하는 것이 좋은 방법이라고 생각합니다. 많은 양의 데이터를 찾지 않고 서비스에서 데이터 통합을 수행 할 수 있습니다.

다른 경우는 집계 등을 수행하기 위해 대량의 데이터에 대해 큰 쿼리를 수행해야하는 경우입니다 (보고 사례). 이를 위해 원래 계획과 유사하게 공유 데이터베이스를 유지하고 마이크로 서비스 데이터베이스의 이벤트로 업데이트하는 방법을 생각합니다. 이 공유 데이터베이스에서 저장 프로 시저를 계속 사용할 수 있으므로 노력을 절약하고 데이터베이스 최적화를 지원할 수 있습니다.

마이크로 서비스에서는 diff를 만듭니다. 예를 들어 : 두 개의 diff가있는 경우 모델을 읽습니다. 제한된 컨텍스트와 누군가는 두 데이터를 모두 검색하기를 원하고 누군가는 제한된 컨텍스트에서 이벤트를 수신하고 응용 프로그램에 맞는 뷰를 만들어야합니다.

이 경우 더 많은 공간이 필요하지만 조인과 조인이 필요하지 않습니다.