REST 마이크로 서비스 전반의 거래?

User, Wallet REST 마이크로 서비스 및 사물을 서로 연결하는 API 게이트웨이가 있다고 가정 해 봅시다. Bob이 웹 사이트에 등록 할 때 API 게이트웨이는 사용자 마이크로 서비스를 통해 사용자를 생성하고 월렛 마이크로 서비스를 통해 지갑을 생성해야합니다.

다음은 상황이 잘못 될 수있는 몇 가지 시나리오입니다.

• 사용자 Bob 작성에 실패했습니다. 괜찮습니다. 오류 메시지를 Bob에게 리턴합니다. 우리는 SQL 트랜잭션을 사용하므로 아무도 시스템에서 Bob을 보지 못했습니다. 모든 것이 좋다 :)

• 사용자 Bob이 생성되었지만 월렛을 생성하기 전에 API 게이트웨이가 충돌합니다. 이제 지갑이없는 사용자가 있습니다 (일관되지 않은 데이터).

• 사용자 Bob이 생성되고 월렛을 생성 할 때 HTTP 연결이 끊어집니다. 지갑 작성에 성공했거나 실패했을 수 있습니다.

이러한 종류의 데이터 불일치가 발생하지 않도록하기 위해 어떤 솔루션을 사용할 수 있습니까? 트랜잭션이 여러 REST 요청으로 확장 될 수있는 패턴이 있습니까? 이 문제를 다루는 2 단계 커밋 의 Wikipedia 페이지를 읽었 지만 실제로 적용하는 방법을 잘 모르겠습니다. 이 Atomic Distributed Transactions : RESTful 디자인 용지도 아직 읽지 않았지만 흥미로워 보입니다.

또는 REST가이 사용 사례에 적합하지 않을 수도 있다는 것을 알고 있습니다. 이 상황을 처리하여 REST를 완전히 삭제하고 메시지 큐 시스템과 같은 다른 통신 프로토콜을 사용하는 올바른 방법일까요? 또는 애플리케이션 코드에서 일관성을 유지해야합니까 (예를 들어, 불일치를 감지하고 수정하는 백그라운드 작업 또는 "만들기", "만든"값 등으로 사용자 모델에 "상태"속성을 가짐)?

말이 안되는 것 :

• REST 서비스와의 분산 트랜잭션 . 정의에 따른 REST 서비스는 상태 비 저장이므로 둘 이상의 서비스에 걸쳐있는 트랜잭션 경계에 참여해서는 안됩니다. 사용자 등록 유스 케이스 시나리오는 의미가 있지만 REST 마이크로 서비스를 사용하여 사용자 및 지갑 데이터를 작성하는 설계는 좋지 않습니다.

두통이 생길 것 :

• 분산 트랜잭션이있는 EJB . 이론적으로는 작동하지만 실제로는 작동하지 않는 것 중 하나입니다. 지금은 JBoss EAP 6.3 인스턴스에서 원격 EJB에 대한 분산 트랜잭션 작업을 시도하고 있습니다. 우리는 몇 주 동안 RedHat 지원에 대해 이야기했지만 아직 작동하지 않았습니다.
• 일반적으로 2 단계 커밋 솔루션 . 2PC 프로토콜 은 훌륭한 알고리즘 이라고 생각합니다 (수년 전에 RPC를 사용하여 C로 구현했습니다). 재시도, 상태 저장소 등의 포괄적 인 장애 복구 메커니즘이 필요합니다. 모든 복잡성은 트랜잭션 프레임 워크 내에 숨겨져 있습니다 (예 : JBoss Arjuna). 그러나 2PC는 실패 증거가 아닙니다. 거래가 단순히 완료 될 수없는 상황이 있습니다. 그런 다음 데이터베이스 불일치를 수동으로 식별하고 수정해야합니다. 운이 좋으면 백만 건의 거래에서 한 번 발생할 수 있지만 플랫폼과 시나리오에 따라 100 건의 거래마다 한 번 발생할 수 있습니다.
• Sagas (보상 거래) . 보상 작업을 작성하는 데 따른 구현 오버 헤드와 마지막에 보상을 활성화하는 조정 메커니즘이 있습니다. 그러나 보상도 실패 증거가 아닙니다. 여전히 불일치 (= 두통)가 발생할 수 있습니다.

아마도 가장 좋은 대안은 무엇입니까?

• 최종 일관성 . ACID와 같은 분산 트랜잭션이나 보상 트랜잭션은 모두 실패 증거가 아니며 두 가지 모두 불일치가 발생할 수 있습니다. 최종 일관성은 종종 "가끔 비 일관성"보다 낫습니다. 다음과 같은 다양한 설계 솔루션이 있습니다.
  • 비동기 통신을 사용하여보다 강력한 솔루션을 만들 수 있습니다. 시나리오에서 Bob이 등록 할 때 API 게이트웨이는 NewUser 큐에 메시지를 보내고 사용자에게 "계정 작성을 확인하는 이메일을받을 것입니다."라고 즉시 응답 할 수 있습니다. 큐 소비자 서비스는 메시지를 처리하고 단일 트랜잭션에서 데이터베이스 변경을 수행하며 Bob에게 전자 메일을 보내 계정 생성을 알릴 수 있습니다.
  • 사용자 마이크로 서비스 는 동일한 데이터베이스에 사용자 레코드 와 월렛 레코드 를 작성 합니다 . 이 경우 사용자 마이크로 서비스의 월렛 저장소는 월렛 마이크로 서비스에서만 볼 수있는 마스터 월렛 저장소의 복제본입니다. 복제본에서 마스터로 또는 그 반대로 데이터 변경 (예 : 새 지갑)을 전송하기 위해 트리거 기반이거나 주기적으로 시작되는 데이터 동기화 메커니즘이 있습니다.

그러나 동기식 응답이 필요한 경우 어떻게해야합니까?

• 마이크로 서비스를 리모델링하십시오 . 서비스 소비자가 즉시 응답이 필요하기 때문에 대기열이있는 솔루션이 작동하지 않으면 동일한 서비스 (또는 적어도 동일한 VM에 배치 된 분산 트랜잭션을 피하기 위해 User 및 Wallet 기능을 재구성) ). 그렇습니다. 마이크로 서비스와는 거리가 멀고 모놀리스와 비슷하지만 두통을 피할 수 있습니다.

이것은 최근에 인터뷰 중에 묻은 고전적인 질문입니다. 여러 웹 서비스를 호출하고 작업 중간에 어떤 종류의 오류 처리를 유지하는 방법. 오늘날 고성능 컴퓨팅에서는 2 단계 커밋을 피합니다. 나는 몇 년 전에 거래에 대한 "스타벅 모델"이라고 불리는 것에 관한 논문을 읽었습니다. 스타벅에서 주문한 커피를 주문, 지불, 준비 및받는 과정에 대해 생각해보십시오. 나는 일을 지나치게 단순화했지만 2 단계 커밋 모델은 전체 프로세스는 커피를받을 때까지 관련된 모든 단계에 대해 단일 포장 거래가 될 것을 제안합니다. 그러나이 모델을 사용하면 모든 직원이 커피를 얻을 때까지 기다렸다가 작업을 중단합니다. 사진이 보여요?

대신 "스타벅 모델"은 "최선의 노력"모델을 따르고 프로세스의 오류를 보상하여 생산성을 향상시킵니다. 첫째, 그들은 당신이 지불하는지 확인합니다! 그런 다음 컵에 주문이 첨부 된 메시지 대기열이 있습니다. 커피를 얻지 못했거나 커피를 주문하지 않은 것처럼 과정에서 문제가 발생하면 보상 프로세스에 들어가서 원하는 것을 얻거나 환불해야합니다. 이것이 가장 효율적인 모델입니다 생산성 향상

때때로 스타벅은 커피를 낭비하지만 전체적인 프로세스는 효율적입니다. 웹 서비스를 여러 번 호출 할 수있는 방식으로 디자인하는 것과 같이 웹 서비스를 구축 할 때 생각해야 할 다른 트릭이 있습니다. 따라서 내 권장 사항은 다음과 같습니다.

• 웹 서비스를 정의 할 때 너무 괜찮지 마십시오 (요즘 마이크로 서비스 과대 광고에 대해 확신하지 못했습니다 : 너무 멀리 갈 위험이 너무 많습니다).

• 비동기는 성능을 향상 시키므로 비동기를 선호하고 가능할 때마다 이메일로 알림을 보냅니다.

• 보다 지능적인 서비스를 구축하여 여러 번 "호출"할 수있게하고, 맨 끝까지 주문을 따르는 uid 또는 taskid로 처리하여 각 단계에서 비즈니스 규칙을 검증합니다.

• 메시지 대기열 (JMS 또는 기타)을 사용하고 반대 작업을 적용하여 "롤백"에 작업을 적용하는 오류 처리 프로세서로 전환합니다. 그런데 비동기 순서로 작업하려면 프로세스의 현재 상태를 확인하기 위해 일종의 대기열이 필요합니다. 그래서 그것을 고려하십시오;

• 최후의 수단으로 (자주 발생하지 않을 수 있으므로) 수동 오류 처리 대기열에 넣습니다.

게시 된 초기 문제로 돌아가 봅시다. 계정을 만들고 지갑을 만들고 모든 것이 완료되었는지 확인하십시오.

전체 작업을 조정하기 위해 웹 서비스가 호출되었다고 가정 해 봅시다.

웹 서비스의 의사 코드는 다음과 같습니다.

1. 계정 생성 마이크로 서비스에 전화를 걸어 정보와 고유 한 작업 ID를 전달하십시오. 1.1 계정 생성 마이크로 서비스는 먼저 해당 계정이 이미 생성되었는지 확인합니다. 작업 ID는 계정의 레코드와 연결됩니다. 마이크로 서비스는 계정이 존재하지 않음을 감지하여 계정을 작성하고 태스크 ID를 저장합니다. 참고 :이 서비스는 2000 번 호출 될 수 있으며 항상 동일한 결과를 수행합니다. 이 서비스는 "필요한 경우 실행 취소 작업을 수행하기위한 최소한의 정보가 포함 된 영수증"으로 응답합니다.

2. 월렛 생성을 호출하여 계정 ID 및 작업 ID를 지정하십시오. 조건이 유효하지 않으며 월렛 작성을 수행 할 수 없다고 가정하십시오. 호출이 오류와 함께 리턴되지만 아무것도 작성되지 않았습니다.

3. 오케 스트레이터는 오류를 알립니다. 계정 생성을 중단해야한다는 것을 알고 있지만 자체적으로 수행하지는 않습니다. 1 단계가 끝날 때받은 "최소 실행 취소 영수증"을 전달하여 월렛 서비스에 요청합니다.

4. 계정 서비스는 실행 취소 영수증을 읽고 작업을 실행 취소하는 방법을 알고 있습니다. 실행 취소 영수증에는 작업의 일부를 수행하기 위해 호출 한 다른 마이크로 서비스에 대한 정보도 포함될 수 있습니다. 이 경우 실행 취소 영수증에 계정 ID 및 반대 작업을 수행하는 데 필요한 추가 정보가 포함될 수 있습니다. 우리의 경우를 단순화하기 위해 단순히 계정 ID를 사용하여 계정을 삭제한다고 가정 해 봅시다.

5. 이제 웹 서비스가 계정 생성 실행 취소가 수행되었다는 성공 또는 실패 (이 경우)를받지 못했다고 가정 해 봅시다. 계정의 실행 취소 서비스를 다시 호출하기 만하면됩니다. 그리고이 서비스는 계정이 더 이상 존재하지 않는 것이 목표이므로 정상적으로 실패하지 않아야합니다. 따라서 존재하는지 확인하고 실행 취소 할 수있는 작업이 없음을 확인합니다. 따라서 작업이 성공했음을 반환합니다.

6. 웹 서비스는 계정을 만들 수 없다는 사용자에게 반환합니다.

이것은 동기적인 예입니다. 시스템이 완전히 오류를 복구하지 못하게하려면 다른 방식으로 관리하고 사례를 헬프 데스크를 대상으로하는 메시지 큐에 넣을 수 있습니다. " 상황을 정정하기 위해 백엔드 시스템에 후크를 제공 할 수 있습니다. 헬프 데스크는 성공적으로 수행 된 작업이 포함 된 메시지를 수신했으며 실행 취소 영수증을 완전히 자동화 된 방식으로 사용할 수있는 것처럼 정보를 수정하기에 충분한 정보가있었습니다.

검색을 수행했으며 Microsoft 웹 사이트에는이 방법에 대한 패턴 설명이 있습니다. 이를 보상 거래 패턴이라고합니다.

거래 패턴 보상

모든 분산 시스템은 트랜잭션 일관성에 문제가 있습니다. 가장 좋은 방법은 당신이 말한 것처럼 2 단계 커밋을하는 것입니다. 지갑과 사용자를 보류 상태로 작성하십시오. 생성 된 후에는 별도의 전화를 걸어 사용자를 활성화하십시오.

마지막 통화는 안전하게 반복 할 수 있어야합니다 (연결이 끊어진 경우).

이를 위해서는 마지막 호출에서 두 테이블에 대해 알아야합니다 (따라서 단일 JDBC 트랜잭션으로 수행 할 수 있음).

또는 지갑이없는 사용자에 대해 왜 그렇게 걱정하는지 생각하고 싶을 수도 있습니다. 이것이 문제를 일으킬 것이라고 생각하십니까? 그렇다면 별도의 휴식 전화로 사용하는 것이 좋지 않습니다. 지갑이없는 사용자가 존재하지 않으면 사용자를 생성하기 위해 원래 POST 호출에서 지갑을 사용자에게 추가해야합니다.

마이크로 서비스 아키텍처의 주요 측면 중 하나는 트랜잭션이 개별 마이크로 서비스 (단일 책임 원칙)에 국한된다는 것입니다.

현재 예제에서 사용자 작성은 자체 트랜잭션입니다. 사용자 작성은 USER_CREATED 이벤트를 이벤트 큐로 푸시합니다. 월렛 서비스는 USER_CREATED 이벤트에 가입하고 월렛 생성을 수행합니다.

내 지갑이 사용자와 동일한 SQL 데이터베이스의 또 다른 레코드 묶음 인 경우 사용자와 지갑 작성 코드를 동일한 서비스에 배치하고 일반 데이터베이스 트랜잭션 기능을 사용하여 처리합니다.

지갑 생성 코드가 다른 시스템이나 시스템을 터치해야 할 때 어떤 일이 발생하는지 묻는 소리가 들립니다. 모든 것이 창조 과정이 얼마나 복잡하고 위험한 지에 달려 있다고 말한다.

신뢰할 수있는 다른 데이터 저장소 (예 : SQL 트랜잭션에 참여할 수없는 데이터 저장소)를 만지는 것이 문제라면 전체 시스템 매개 변수에 따라 두 번째 쓰기가 발생하지 않을 가능성이 거의 없어 질 수 있습니다. 나는 아무것도 할 수는 없지만 예외를 제기하고 보상 거래 또는 일부 임시 방법을 통해 일치하지 않는 데이터를 처리합니다. 항상 개발자들에게 "이런 일이 앱에서 일어나면 눈에 띄지 않을 것"이라고 말합니다.

지갑 생성의 복잡성과 위험이 증가함에 따라 관련된 위험을 개선하기위한 조치를 취해야합니다. 일부 단계에서 여러 파트너 API를 호출해야한다고 가정 해 보겠습니다.

이 시점에서 부분적으로 구성된 사용자 및 / 또는 지갑 개념과 함께 메시지 큐를 도입 할 수 있습니다.

엔터티가 결국 제대로 구성되도록하는 간단하고 효과적인 전략은 성공할 때까지 작업을 다시 시도하는 것이지만 응용 프로그램의 사용 사례에 따라 다릅니다.

또한 프로비저닝 프로세스에서 실패하기 쉬운 단계에 대해 오랫동안 열심히 생각했습니다.

간단한 해결책 중 하나는 사용자 서비스를 사용하여 사용자를 작성하고 사용자 서비스가 이벤트를 발생시키는 메시징 버스를 사용하고 월렛 서비스가 메시징 버스에 등록하고 사용자 작성 이벤트를 청취하며 사용자의 월렛을 작성하는 것입니다. 그 동안 사용자가 월렛 UI를 사용하여 월렛을 확인한 경우 사용자가 방금 생성되었는지 확인하고 월렛 생성이 진행 중인지 확인합니다. 잠시 후 확인하세요.

이러한 종류의 데이터 불일치가 발생하지 않도록하기 위해 어떤 솔루션을 사용할 수 있습니까?

전통적으로 분산 트랜잭션 관리자가 사용됩니다. 몇 년 전 Java EE 환경에서 이러한 서비스를 EJB 로 작성 하여 다른 노드에 배치했으며 API 게이트웨이가 해당 EJB를 원격으로 호출했을 수 있습니다. 응용 프로그램 서버 (올바르게 구성된 경우)는 2 단계 확약을 사용하여 트랜잭션이 확약되거나 각 노드에서 롤백되도록 일관성을 보장합니다. 그러나이를 위해서는 모든 서비스가 동일한 유형의 응용 프로그램 서버에 배포되어 호환 될 수 있어야하며 실제로는 단일 회사에서 배포 한 서비스로만 작동해야합니다.

트랜잭션이 여러 REST 요청으로 확장 될 수있는 패턴이 있습니까?

SOAP (RESO가 아닌 ok)의 경우 WS-AT 사양이 있지만 통합해야 할 서비스는 지원하지 않습니다. REST의 경우 JBoss에는 파이프 라인에 무언가가 있습니다. 있습니다. 그렇지 않으면 "패턴"은 아키텍처에 연결할 수있는 제품을 찾거나 자체 솔루션을 구축하는 것입니다 (권장되지 않음).

Java EE 용 제품을 게시했습니다 : https://github.com/maxant/genericconnector

참조하는 논문에 따르면 Atomikos의 Try-Cancel / Confirm 패턴 및 관련 제품도 있습니다.

BPEL 엔진은 보상을 사용하여 원격으로 배치 된 서비스 간의 일관성을 처리합니다.

또는 REST가이 사용 사례에 적합하지 않을 수도 있다는 것을 알고 있습니다. 이 상황을 처리하여 REST를 완전히 삭제하고 메시지 큐 시스템과 같은 다른 통신 프로토콜을 사용하는 올바른 방법일까요?

비 트랜잭션 리소스를 트랜잭션에 "바인딩"하는 방법에는 여러 가지가 있습니다.

• 제안한대로 트랜잭션 메시지 큐를 사용할 수는 있지만 비동기식이므로 응답에 의존하면 혼란스러워집니다.
• 백엔드 서비스를 데이터베이스에 호출 한 다음 배치를 사용하여 백엔드 서비스를 호출해야한다는 사실을 작성할 수 있습니다. 다시 한 번 비동기이므로 지저분해질 수 있습니다.
• 백엔드 마이크로 서비스를 조정하기 위해 비즈니스 프로세스 엔진을 API 게이트웨이로 사용할 수 있습니다.
• 원격 EJB는 처음부터 언급 한대로 분산 트랜잭션을 즉시 지원하므로 사용할 수 있습니다.

또는 애플리케이션 코드에서 일관성을 유지해야합니까 (예를 들어, 불일치를 감지하고 수정하는 백그라운드 작업 또는 "만들기", "만든"값 등으로 사용자 모델에 "상태"속성을 가짐)?

악마를 옹호하는 옹호 : 왜 당신을 위해 그것을하는 제품이있을 때 (위 참조), 왜 그런 식으로 무언가를 만들고, 아마도 그들이 시험되고 시험 되었기 때문에 당신이 할 수있는 것보다 더 나을까요?

개인적으로 나는 사용 사례에 의해 정의 된 모듈 인 Micro Services의 아이디어를 좋아하지만 질문에서 언급했듯이 은행, 보험, 통신 등과 같은 고전적인 비즈니스에는 적응 문제가 있습니다.

많은 사람들이 언급했듯이 분산 트랜잭션은 좋은 선택이 아닙니다. 사람들은 이제 궁극적으로 일관된 시스템을 위해 더 많이 가고 있지만 이것이 은행, 보험 등에 효과가 있는지 확신하지 못합니다 ...

제안 된 솔루션에 대한 블로그를 작성했는데 도움이 될 수 있습니다.

https://mehmetsalgar.wordpress.com/2016/11/05/micro-services-fan-out-transaction-problems-and-solutions-with-spring-bootjboss-and-netflix-eureka/

궁극적 일관성은 여기서 핵심입니다.

• 서비스 중 하나가 이벤트의 기본 핸들러가되도록 선택되었습니다.
• 이 서비스는 단일 커밋으로 원래 이벤트를 처리합니다.
• 1 차 핸들러는 2 차 효과를 다른 서비스와 비동기 적으로 통신하는 책임을집니다.
• 기본 핸들러는 다른 서비스 호출의 오케스트레이션을 수행합니다.

사령관은 분산 트랜잭션을 담당하고 통제합니다. 실행할 명령을 알고 실행을 조정합니다. 대부분의 시나리오에는 두 개의 명령 만 있지만 여러 명령을 처리 할 수 ​​있습니다.

사령관은 모든 명령의 실행을 보장 할 책임이 있으며 이는 은퇴를 의미합니다. 사령관이 원격 업데이트를 시도하고 응답을받지 못하면 다시 시도하지 않습니다. 이런 방식으로 시스템은 고장이 덜 발생하도록 구성 할 수 있으며 스스로 치유됩니다.

재 시도 할 때 i 등성이 있습니다. Idempotence는 최종 결과가 한 번만 수행 된 것과 동일한 방식으로 두 번 수행 할 수있는 속성입니다. 명령이 두 번 이상 수신되는 경우 명령을 한 번만 처리 할 수 ​​있도록 원격 서비스 또는 데이터 소스에서 dem 등성이 필요합니다.

최종 일관성 이는 대부분의 분산 트랜잭션 문제를 해결하지만 여기서 몇 가지 사항을 고려해야합니다. 실패한 모든 트랜잭션 다음에 재 시도가 수행되며, 재시도 횟수는 컨텍스트에 따라 다릅니다.

일관성은 결국입니다. 예를 들어 고객이 책을 주문한 후 지불 한 후 재고 수량을 업데이트하는 등의 재시도 동안 시스템이 일관된 상태가 아닙니다. 재고 갱신 조작이 실패하고 마지막 재고가 있다고 가정하면 재고 갱신에 대한 재시도 조작이 성공할 때까지 책을 계속 사용할 수 있습니다. 재 시도에 성공하면 시스템이 일관됩니다.

스크립팅 / 프로그래밍을 지원하는 APIM (API Management) 플랫폼을 사용하지 않는 이유는 무엇입니까? 따라서 마이크로 서비스를 방해하지 않고 APIM에서 복합 서비스를 구축 할 수 있습니다. 이 목적으로 APIGEE를 사용하여 설계했습니다.