마이크로 서비스 간 데이터 일관성

Question

각 마이크로 서비스는 일반적으로 자체 데이터를 갖지만 특정 엔터티는 여러 서비스에서 일관성이 있어야합니다.

마이크로 서비스 아키텍처와 같이 고도로 분산 된 환경에서 이러한 데이터 일관성 요구 사항을 충족하려면 설계를위한 선택 사항은 무엇입니까? 물론 단일 DB가 모든 서비스에서 상태를 관리하는 공유 데이터베이스 아키텍처는 원하지 않습니다. 이는 고립과 비공유 원칙을 위반합니다.

마이크로 서비스는 엔티티를 생성, 업데이트 또는 삭제할 때 이벤트를 게시 할 수 있다는 것을 알고 있습니다. 이 이벤트에 관심이있는 다른 모든 마이크로 서비스는 그에 따라 각각의 데이터베이스에서 링크 된 엔티티를 업데이트 할 수 있습니다.

이 방법을 사용할 수는 있지만 서비스 전반에 걸쳐 많은주의를 기울이고 조정 된 프로그래밍 작업이 필요합니다.

Akka 또는 다른 프레임 워크가이 사용 사례를 해결할 수 있습니까? 방법?

edit1 :
명확성을 위해 아래 다이어그램을 추가하십시오.
기본적으로이 데이터 일관성 문제를 해결할 수있는 프레임 워크가 있다면 이해하려고합니다.

대기열의 경우 RabbitMQ 또는 Qpid와 같은 AMQP 소프트웨어를 사용할 수 있습니다. 데이터 일관성 프레임 워크의 경우 현재 Akka 또는 다른 소프트웨어가 도움이되는지 확신 할 수 없습니다. 아니면이 시나리오가 너무 드문 경우이며, 프레임 워크가 필요하지 않은 그러한 안티 패턴입니까? 기억해야 할

Answer 1

이론적 제한

한 가지 중요한주의해야 할 점은 CAP theorem입니다 : 일관성이나 가용성 : 파티션의 존재에

, 하나는 다음 두 가지 옵션으로 남아 있습니다. 의 가용성을 유지하면서 일관성을 선택할 때 네트워크 파티션으로 인해 특정 정보가 최신 정보로 보장되지 않으면 시스템에서 오류 또는 시간 초과를 반환합니다

따라서 특정 엔터티가 여러 서비스에서 일관성을 유지해야하므로 시간 초과 문제를 처리해야 할 가능성이 높아집니다.

Akka는 데이터 분산

Akka는 클러스터 내에서 정보를 공유 할 수있는 distributed data module 있습니다

클러스터의 항목이 특정 역할 모든 노드 또는 노드에 분산되어 모든 데이터, 직접 복제 및 가십을 통해 보급을 기반으로합니다. 읽기 및 쓰기를 위해 일관성 레벨 의 세밀한 제어가 있습니다.

Answer 2

"따라서 각각의 데이터베이스에서 링크 된 엔터티를 업데이트합니다"-> 데이터 중복 -> FAIL.

다른 데이터베이스를 업데이트하기 위해 이벤트를 사용하는 것은 질문에서 발생하는 캐시 일관성 문제를 일으키는 캐싱과 동일합니다.

로컬 데이터베이스를 가능한 한 분리 된 상태로 유지하고 푸시 대신 푸시 의미론을 사용합니다. 예를 들어 데이터가 필요할 때 RPC 호출을 만들고 시간 초과, 누락 된 데이터 또는 서비스 사용 불가 등 가능한 오류를 정상적으로 처리 할 준비가되어 있어야합니다. Akka 또는 Finagle은 이러한 작업을 수행 할 수있는 충분한 도구를 제공합니다.

이 접근 방법은 일 수도 있고 일 수도 있습니다.하지만 적어도 거래 할 장소와 위치는 선택할 수 있습니다. 대기 시간과 증가 처리량을 줄일 수있는 방법은 다음과 같습니다

• 규모의 데이터 제공 서비스들이 짧은 만료 시간과 낮은 지연
• 사용 로컬 캐시로 더 많은 필수/초를 처리 할 수 ​​있습니다. 결국 일관성이 있지만 성능에 도움이됩니다.
• 사용 분산 캐시와 얼굴 캐시 일관성 문제는 직접

Answer 3

Microservices 건축 양식은 조직 개발 및 런타임에 독립적 인 작은 팀이 자신의 서비스를 할 수 있도록하려고합니다. 이 부분은 read입니다. 가장 어려운 부분은 서비스 경계를 ​​유용한 방식으로 정의하는 것입니다. 애플리케이션을 분할하는 방식으로 여러 서비스에 자주 영향을 미치는 요구 사항이 발생하면 서비스 경계를 ​​다시 생각해보아야한다는 것을 알게됩니다. 서비스간에 개체를 공유해야 할 필요성이 높을 때도 마찬가지입니다.

일반적인 조언은 그러한 시나리오를 피하기 위해 매우 열심히 노력하는 것입니다. 그러나 이것을 피할 수없는 경우가있을 수 있습니다. 좋은 아키텍처는 종종 적절한 장단점을 만들어 내기 때문에 여기에 몇 가지 아이디어가 있습니다.

1. 직접 DB 종속성 대신 서비스 인터페이스 (API)를 사용하여 종속성을 표현하는 것을 고려하십시오. 이를 통해 각 서비스 팀은 필요한만큼 내부 데이터 스키마를 변경하고 종속성과 관련하여 인터페이스 디자인에 대해서만 염려 할 수 있습니다. 이는 잠재적으로 모든 잠재적 인 마이크로 서비스와 함께 (잠재적으로 동시에) DB 디자인을 변경하는 대신 추가 API를 추가하고 천천히 이전 API를 더 이상 사용하지 않기 때문에 유용합니다. 즉, 이전 API가 여전히 지원되는 한 새 Microservice 버전을 독립적으로 배포 할 수 있습니다. 이는 마이크로 서비스 접근 방식을 개척 한 Amazon CTO가 권장하는 접근 방식입니다. 여기에 그와 함께 interview in 2006의 권장되는 읽기가 있습니다.

2. 동일한 DB를 사용하는 것을 피할 수없고 여러 팀/서비스가 동일한 엔터티를 필요로하는 방식으로 서비스 경계를 ​​분할 할 때마다 Microservice 팀과 해당 팀 간의 두 가지 종속성을 소개합니다 데이터 체계 : a) 데이터 형식, b) 실제 데이터. 이는 해결이 불가능하지 않지만 조직의 일부 오버 헤드 만 있습니다. 그리고 그러한 종속성을 너무 많이 도입하면 조직이 개발에 어려움을 겪고 느려질 수 있습니다.

A) 데이터 방식에 대한 종속성. 엔티티 데이터 형식은 Microservices에서 변경하지 않고 수정할 수 없습니다. 이것을 분해하려면 엔티티 데이터 스키마 을 정확히으로 버전화하고 데이터베이스는 현재 마이크로 서비스가 사용하는 모든 버전의 데이터를 지원해야합니다.이를 통해 마이크로 서비스 팀은 새로운 버전의 데이터 스키마를 지원하기 위해 서비스를 업데이트 할시기를 스스로 결정할 수 있습니다. 이것은 모든 유스 케이스에서 가능하지는 않지만 많은 경우에 사용할 수 있습니다.

b) 실제 수집 된 데이터에 대한 종속성. Microservice의 알려진 버전이며 수집 된 데이터는 사용할 수 있지만 새로운 버전의 데이터를 생성하는 서비스가 있고 또 다른 서비스가 종속되어있는 경우 문제가 발생합니다. 그러나 아직 업그레이드되지 않았습니다. 최신 버전을 읽을 수 있습니다. 이 문제는 해결하기가 어렵고 많은 경우에 서비스 경계를 ​​올바르게 선택하지 않았 음을 나타냅니다. 일반적으로 데이터베이스의 데이터를 업그레이드하는 것과 동시에 데이터에 의존하는 모든 서비스를 롤아웃 할 수밖에 없습니다. 더 이상한 접근법은 데이터의 다른 버전을 동시에 작성하는 것입니다 (주로 데이터가 변경 가능하지 않을 때 작동합니다).

일부 다른 경우에는 hidden data duplication 및 eventual consistency까지 종속성을 줄일 수 있습니다. 각 서비스는 자체 버전의 데이터를 저장하고 해당 서비스에 대한 요구 사항이 변경 될 때마다 수정합니다. 서비스는 공개 데이터 흐름을 청취함으로써 가능합니다. 이러한 시나리오에서는 이벤트를 처리하고 이벤트와 관련된 모든 데이터를 저장하는 여러 서비스의 청취자가 대기 및 소비 할 수있는 공개 이벤트 세트를 정의하는 이벤트 기반 아키텍처를 사용합니다 (잠재적으로 데이터 복제 생성). 이제 일부 다른 이벤트는 내부적으로 저장된 데이터가 업데이트되어야 함을 나타낼 수 있으며 자체 데이터 복사본으로 수행하는 것은 각 서비스 책임입니다. 이러한 공개 이벤트 큐를 유지하는 기술은 Kafka입니다.

서비스 협력 여기

당신이 서비스 오케스트레이션 및 서비스 안무 중에서 선택할 수 있습니다

Answer 4

나는 당신이이 각도, 서비스 협업 및 데이터 모델링에서이 문제에 접근 할 수 있다고 생각합니다. 이미 서비스간에 메시지 또는 이벤트 교환에 대해 언급했습니다. 이것은 말했듯이 작동하지만 메시징 부분을 처리하는 각 서비스에 코드를 작성하는 안무 방식 일 것입니다. 그래도 도서관이 있다고 확신합니다. 또는 서비스 간 데이터 업데이트를 관리 할 수있는 오케 스트레이터 (Orchestrator)라는 새로운 복합 서비스를 소개하는 서비스 오케스트레이션을 선택할 수 있습니다. 데이터 일관성 관리는 이제 별도의 구성 요소로 추출되므로 다운 스트림 서비스를 만지지 않고도 최종 일관성과 강력한 일관성간에 전환 할 수 있습니다.

데이터 모델링

또한 참여 microservices 뒤에 데이터 모델을 재 설계하고 전용 관계 microservice에 의해 관리되는 관계로 여러 서비스에서 일치하는 데 필요한 개체를 추출하도록 선택할 수 있습니다

. 이러한 마이크로 서비스는 오케 스트레이터와 다소 유사하지만 관계가 일반적인 방식으로 모델링 될 수 있기 때문에 결합이 줄어들 것입니다.

Answer 5

은 여기 플레이에서 2 개 주 힘이 있다고 생각 :

• 디커플링이 - 당신이 처음에 microservices을 가지고 데이터 지속성에 비공유 접근 방식을
• 일관성 요구 사항을하려는 그 이유는 - 나는 경우 정확하게 일관된 결과를 얻었음을 알았습니다.

이 다이어그램은 제게는 완벽하지만 이해하기 쉬운 프레임 워크를 알지 못합니다. 트레이드 오프 관련.이 문제는 다음과 같이 접근합니다.

업스트림 서비스는 앞에서 설명한 것처럼 이벤트를 메시지 버스로 내 보냅니다. 직렬화의 목적을 위해 나는 생산자와 소비자를 너무 많이 연결시키지 않는 유선 형식을 신중하게 선택했다. 제가 아는 것들은 protobuf와 avro입니다. 새로 추가 된 필드를 신경 쓰지 않는다면 다운 스트림을 변경하지 않고 업스트림 모델을 업스트림으로 발전시킬 수 있으며 롤업 업 그레 이드를 수행 할 수 있습니다.

다운 스트림 서비스가 이벤트에 가입합니다. 메시지 버스는 내결함성을 제공해야합니다. 우리는 kafka를이 용도로 사용하고 있습니다. 그러나 AMQP를 선택 했으므로 필요로하는 것을 제공한다고 가정하고 있습니다.

네트워크 장애가있는 경우 (예 : 다운 스트림 소비자가 브로커에 연결할 수 없음) 가용성보다 일관성이있는 경우 일부 데이터보다 오래 걸릴 수있는 데이터에 의존하는 요청을 처리하지 않기로 선택할 수 있습니다. 사전 구성된 임계 값.