마이크로서비스의 사가 패턴

마이크로서비스의 문제를 해결하시겠습니까? 사가 모드를 사용해 보세요

이런 상황에 직면한 적이 있습니까? 주문 처리 프로세스에는 결제, 재고, 물류 등 여러 서비스를 호출해야 합니다. 링크 중 하나가 걸려서 전체 프로세스가 혼란에 빠졌습니다. 금액이 차감되었으나 재고가 업데이트되지 않거나, 상품이 발송되었으나 결제가 완료되지 않아 수동 검증 및 롤백을 기다리는 난장판이 됩니다. 두통을 주나요?

마이크로서비스 아키텍처에서는 이런 종류의 문제가 너무 흔합니다. 각 서비스는 자체 토지를 관리하며 데이터는 공유되지 않습니다. 일련의 작업이 성공할지 실패할지 어떻게 보장할 수 있나요? 기존의 패키지 트랜잭션(ACID 트랜잭션)은 단일 애플리케이션에서는 사용하기 쉽지만, 서비스가 여러 조각으로 분산되어 있는 분산 환경에서는 다소 부적합합니다. 이때는 생각을 바꿔야 합니다.

사가 모드란 무엇인가요? 마치 '코디 디렉터' 같다.

간단히 말해서, Saga 모델은 대규모 비즈니스 트랜잭션을 일련의 작고 독립적인 로컬 트랜잭션으로 나누는 것입니다. 각 서비스는 자체 단계만 완료한 후 다음 서비스 작업을 트리거합니다. 중간에 특정 단계가 실패하면 Saga는 영화의 장면이 깨졌듯이 일련의 "보정 작업"을 시작하고 이전에 촬영된 관련 부분을 순서대로 재조정하거나 삭제하여 시스템 상태를 사건 발생 이전으로 되돌릴 수 있습니다.

모든 리소스를 잠그기 위해 큰 잠금에 의존하지 않고 이벤트와 메시지에 의해 구동되어 서비스 간의 "채팅 협업"을 허용합니다. 예를 들어, 주문이 성공적으로 생성되면 "Deduct one item"이라는 메시지가 인벤토리 서비스로 전송됩니다. 재고가 성공적으로 공제되면 물류 담당자에게 "배송 준비가 되었습니다."라는 알림이 전송됩니다. 배송이 실패하면 재고 서비스는 "방금 공제된 품목을 다시 추가하세요"를 알아야 하며 주문 서비스는 상태를 "처리 대기 중"으로 변경해야 할 수도 있습니다.

누군가가 "이거 그냥 플랜B 아닌가요?"라고 물었습니다. 예, 완전히 옳지는 않습니다. 보상은 단순한 롤백이 아니라 비즈니스 로직을 역으로 조정하는 것입니다. 핵심은 디자인할 때 모든 단계가 실패할 경우 "정상적으로 종료"하는 방법을 명확하게 생각해야 한다는 것입니다.

왜 이런 것에 관심을 가져야 합니까? 함정에 덜 빠지고 더 많이 자세요

한밤중 3시에 알람 문자 메시지를 듣고 깨어난다고 상상해 보세요. 주문상태가 멈춰서 업스트림과 다운스트림의 데이터가 모두 일치하지 않는데... 그런 날을 누가 상상이나 했나요? Saga와 같은 모델 채택의 핵심 이점은 최종 일관성과 시스템 복원력을 향상시키는 것입니다. 서비스는 느슨하게 결합되어 있습니다. 한 서비스가 일시적으로 중단되더라도 다른 서비스가 자체 작업을 수행하는 데에는 영향을 미치지 않습니다. 복구되면 보상 메커니즘이 데이터를 따라잡는 데 도움이 될 수 있습니다.

또한 복잡한 프로세스를 가시화하고 관리하기 쉽게 만듭니다. 더 이상 모호한 "분산 거래 블랙박스"에 직면할 필요가 없으며 문제가 어디에 있는지, 어디에서 보상을 시작해야 하는지 알 수 있는 명확한 단계 체인을 볼 수 있습니다. 이렇게 하면 문제를 해결하고 추적을 감사하는 것이 훨씬 쉽습니다.

물론, 그것도 만능은 아닙니다. 각각의 순방향 작업과 해당 보상 작업을 신중하게 정의해야 하므로 설계는 더욱 두뇌 집약적입니다. 보상 자체도 실패할 수 있으므로 보다 정교한 오류 처리 및 모니터링 전략이 필요합니다. 그러나 오류가 발생한 후 수동으로 화재를 진압하는 것에 비해 자동화된 교정 프로세스를 미리 설계하면 장기적으로 많은 문제를 줄일 수 있습니다.

그것을 사용하는 방법? 몇 가지 실용적인 아이디어

1. 비즈니스 흐름을 정리하세요: 서두르지 말고 코드를 작성하세요. 먼저 종이 한 장을 가져다가 "사용자 주문 -> 재고 차감 -> 결제 차감 -> 운송장 작성"과 같은 서비스 간 비즈니스 프로세스를 그려보세요. 각 단계의 입력과 출력을 명확히 합니다.
2. "보상 조치"를 정의하십시오.: 각 단계에 대해 스스로에게 질문해 보십시오. "나중에 이 단계가 실패하면 어떻게 실행 취소하거나 그 영향을 상쇄할 수 있습니까?" 재고 공제에 대한 보상은 재고를 다시 추가하는 것입니다. 공제에 대한 보상은 환불을 유발할 수 있습니다. 보상 작업도 비즈니스에 적합한지 확인하세요.
3. 코디방법 선택: 보통 2가지 종류가 있습니다. 하나는안무를 맡은, 밴드 지휘자처럼 누가 무엇을 해야 하는지 지시하는 중앙 집중식 코디네이터를 만듭니다. 두 번째는협력적인, 릴레이 경주처럼 각 서비스가 작업을 완료한 후 다음 서비스에 알리도록 합니다. 전자는 강력한 통제력을 갖고 있는 반면, 후자는 더욱 분산되고 유연합니다. 팀 구조와 복잡성 선호도에 따라 선택하세요.
4. 구현 및 테스트: 친숙한 메시지 대기열이나 이벤트 스트리밍 플랫폼을 사용하여 상태 변경 사항을 전달합니다. 최우선 순위는 테스트, 특히 오류 시나리오입니다. 중간에 서비스 충돌을 시뮬레이션하여 보상 체인이 올바르게 트리거될 수 있는지, 그리고 데이터가 궁극적으로 일관성이 있는지 확인합니다.
5. 모니터링 및 경고: Saga의 각 단계 및 보상 작업에 명확한 로그 및 지표를 추가합니다. 보상이 자주 실행되면 특정 서비스가 불안정하다는 초기 신호일 수 있습니다.

신뢰할 수 있는 기술이 비즈니스의 조용한 지원이 되도록 하십시오.

결국 기술 모델은 비즈니스에 도움이 됩니다. Saga 모델은 시스템 전반에 걸쳐 취약한 비즈니스 프로세스를 더욱 강력하고 예측 가능하게 만드는 데 도움이 됩니다. 시끄럽지는 않지만 사용자 주문이 백그라운드에서 설명할 수 없을 정도로 사라지지 않고 재고 수치가 항상 정확하며 재무 흐름이 명확하고 추적 가능하도록 자동으로 보장합니다. 이러한 기본 안정성은 궁극적으로 제품 경험을 더욱 원활하게 만들고 팀의 운영 및 유지 관리에 대한 부담을 줄여줍니다.

존재하다kpower, 우리는 이러한 안정성 추구를 이해합니다. 세심하게 설계된 기계 시스템과 마찬가지로 각 서보 모터의 회전과 각 스티어링 기어의 반응은 더 큰 순서로 정밀하게 조정되어야 합니다. 좋은 기술 아키텍처의 경우에도 마찬가지입니다. 복잡한 협업을 간단하고 안정적으로 만들어 끝없이 허점을 고치는 대신 비즈니스 혁신 자체에 더 집중할 수 있습니다.

다음에 다단계 작업 및 서비스 간 호출이 포함된 기능을 디자인할 때 다음과 같이 생각해 보는 것이 좋습니다. 이 링크가 중간에 끊어지면 자체적으로 정리할 수 있습니까? 어쩌면 Saga 모드가 여러분에게 필요한 디자인 도면일 수도 있습니다.

2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. 모듈식 드라이브 기술의 혁신을 활용하여,kpower고성능 모터, 정밀 감속기, 멀티 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다. Kpower는 스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론 및 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.