마이크로서비스 롤백 방법

마이크로서비스 롤백 방법

나는 마이크로서비스와 관련된 의심이 있습니다.M1, M2, M3, M3, M4 및 M5와 같이 5개의 마이크로 서비스가 있다고 가정합니다. 4개의 마이크로 서비스로 연결/액세스되는 4개의 데이터베이스가 있습니다.예를 들어 MySQL에 연결된 M2, 카산드라에 연결된 M3, MongoDB에 연결된 M4, Oracle에 연결된 M5 등이 있습니다.

지금이다

1단계: M1이 M2에 전화를 걸어 MySQL의 일부 사용자 데이터를 업데이트하고 성공적으로 업데이트한 후 M2로부터 성공적인 응답을 받았습니다.

2단계: M1이 M3에 전화를 걸어 카산드라의 일부 데이터를 업데이트하고 성공적으로 업데이트한 후 마침내 M3로부터 성공적인 응답을 받았습니다.

3단계: M1이 M4에 전화를 걸어 MongoDB의 일부 데이터를 업데이트했지만 DB 서버 문제 또는 기타 문제로 인해 실패했습니다.

여기서 제 요구 사항은 이전 마이크로 서비스(M2 및 M3)에 발생한 DB 변경사항을 롤백하는 것입니다.

이러한 롤백 시나리오를 달성하려면 어떻게 해야 합니까?

이것은 분산 트랜잭션의 일반적인 경우입니다.데이터베이스에 대해 별도의 기술을 사용하거나 다른 서버에서 동일한 기술을 사용하더라도 트랜잭션 작업을 수행합니다.이러한 유형의 트랜잭션에 대한 롤백을 처리하려면 트랜잭션 및 롤백에 대한 데이터베이스 기술 메커니즘을 릴레이할 수 없습니다.당신은 그것을 당신 스스로 해야 합니다.

사가 패턴

마이크로 서비스 아키텍처에서 분산 트랜잭션 시나리오에 대한 일반적인 솔루션은 Saga 패턴입니다.분산 사가는 시나리오에서 설명한 것과 같은 실패를 관리하기 위한 패턴입니다.

Saga는 "온라인 상점에서 제품 구매"와 같은 비즈니스 프로세스를 기반으로 생성됩니다.이 프로세스에는 여러 마이크로 서비스에 대한 여러 작업이 포함될 수 있습니다.Saga는 이 프로세스 실행을 제어하고 관리하며, 단계 중 하나가 실패하면 실패하기 전에 수행된 작업을 되돌리는 작업을 트리거합니다.

사가를 구현하는 방법은 여러 가지가 있습니다.이는 아키텍처와 마이크로 서비스가 서로 통신하는 방식에 따라 다릅니다.명령 및/또는 이벤트를 사용합니까?

---

예

"온라인 상점에서 제품 구매" 비즈니스 프로세스.이 비즈니스 프로세스에는 세 가지 다른 마이크로 서비스에 의해 수행되는 세 가지 간단한 단계가 있다고 가정해 보겠습니다.

• 조치 1 - 제품-재고-마이크로 서비스에서 제품 예약
• 조치 2 - 지불 마이크로 서비스에서 지불 확인
• 조치 3 - 주문형 제품 주문-마이크로 서비스

이벤트 사용:

이벤트를 게시하여 일부 작업을 수행할 수 있으며, 작업 중 하나가 실패할 경우 해당 이벤트에 대한 되돌림(또는 삭제) 이벤트를 게시할 수 있습니다.위의 비즈니스 프로세스에 대해 1을 예로 들어 보겠습니다.작업이 성공하고 2.작업이 실패했습니다.이 경우 1을 롤백합니다.예약을 제거하고 해당 비즈니스 프로세스에 대한 트랜잭션이 시작되기 전의 상태로 되돌리기 위해 "RemoveReservationFromProduct"와 같은 이벤트를 게시할 수 있습니다.이벤트 핸들러가 이 이벤트를 픽업하여 데이터베이스에서 해당 상태를 되돌립니다.이벤트이므로 실패에 대한 재시도 메커니즘을 구현하거나 코드에 버그가 있으면 나중에 다시 적용할 수 있습니다.

명령 사용:

일종의 restapi를 사용하여 마이크로 서비스를 명령으로 직접 호출하는 경우 일부 삭제 또는 업데이트 끝점을 실행하여 수행한 변경 사항을 되돌릴 수 있습니다.위의 비즈니스 프로세스에 대해 1을 예로 들어 보겠습니다.작업이 성공하고 2.작업이 실패했습니다.이 경우 1을 롤백합니다.예약을 제거하고 해당 비즈니스 프로세스에 대한 트랜잭션이 시작되기 전의 상태로 되돌리기 위해 특정 제품에 대한 예약을 삭제하기 위해 delete api를 호출하는 작업입니다.

이 예를 통해 사가 패턴을 구현하는 방법을 살펴볼 수 있습니다.

제가 알기로는 당신이 찾고 있는 것은 사가입니다.이 아이디어는 모든 상태 변경 작업에 대해 다운스트림에서 문제가 발생한 경우 호출해야 하는 실행 취소 작업을 제공하는 것입니다.

이 전체 호출 시퀀스에서 @Transactional이 활성화되었는지 확인할 수 있습니다.

1. M1의 모든 마이크로서비스 호출을 단일 트랜잭션으로 간주합니다.
2. 다음과 같은 방법으로 롤백을 표시합니다.
   • M2, M3, M4에서 DB를 업데이트할 때 값을 DB와 함께 Spring cache에 배치합니다.
   • M2, M3 또는 M4에서 /rollback을 호출할 때 Spring Cache에서 값을 가져와 DB에서 실행 취소합니다.
3. fallbackMethod of history 명령에서 M1이 오류 또는 일부 기본 출력으로 응답하면 다른 서비스의 /rollback을 호출합니다.

이 방법은 /rollback 핸들링으로 또 다른 고장 지점을 제공하지만 가장 빠르게 구현할 수 있기 때문에 완벽한 솔루션은 아닐 수 있습니다.

질문에 답변하기 위해 몇 가지 비즈니스 요구 사항을 추가합니다.

사례 1. M1은 Order Placed와 같이 수신된 이벤트를 기반으로 다른 마이크로 서비스와 모든 상호 작용을 수행합니다.

이 경우 M2는...M5 업데이트,

요구 사항 1: 모든 구성 요소가 서로 독립적인 경우.

먼저 하나의 이벤트에서 5개의 이벤트를 생성한 다음

이러한 경우 테이블에 이 이벤트를 처리되지 않은 이벤트로 표시하고 일부 타이머가 처리되지 않은 이벤트를 읽고 Idempotent 방식으로 모든 작업을 수행하려고 할 수 있습니다. 또한 이러한 작업이 실패하고 있는지 보고할 수 있으며 팀에서 해당 작업을 확인하고 수동으로 해결할 수 있습니다.

(페일오버 대기열을 사용하여 유사한 논리를 구현할 수 있습니다. 이 경우 시간이 지나면 동일한 이벤트가 원래 대기열로 다시 전송됩니다.)

요구 사항 2: 모두 독립적이지 않은 경우

단일 이벤트를 사용하고 동일한 솔루션을 사용합니다.

위의 솔루션에서 주요 이점은 트랜잭션 사이에 시스템이 다시 시작되더라도 항상 일관된 시스템을 갖게 된다는 것입니다.

사례 2. M1 api가 호출되고 M1이 여러 마이크로 서비스에서 모든 작업을 수행한 후 사용자에게 응답을 제공해야 하는 경우.

M1 microservice DB(sync_event_table)에서 시작된 이벤트를 생성할 수 있습니다. 모든 microservice에서 업데이트를 시도해 보십시오. 완료된 동기화 이벤트 테이블을 업데이트하십시오.

완료되지 않은 경우 - > Xmin에 대해 완료되지 않은 작업을 확인하는 타이머를 실행한 다음 실행 취소 작업 또는 필요한 작업을 수행합니다.

에센스:

그래서 만약 당신이 모든 해결책을 본다면 당신의 시스템이 모든 다른 마이크로서비스 업데이트를 하도록 제안합니다.

작업을 생성하여

작업 상태 확인

실행 취소/실행 취소 작업 기능 작성

언급URL : https://stackoverflow.com/questions/58178511/how-to-rollback-microservices