기업 비즈니스가 지속적으로 확장되면서 단일 애플리케이션으로 대규모 비즈니스 처리를 처리할 수 없는 경우가 많습니다. 마이크로서비스 아키텍처는 시대의 요구에 따라 등장한 솔루션으로, 대규모 애플리케이션 시스템을 여러 개의 소규모 서비스 단위로 분할하여 각 서비스 단위를 독립적으로 개발, 배포, 운영, 유지 관리 및 업그레이드할 수 있습니다. 이 아키텍처는 애플리케이션의 유연성과 확장성을 크게 향상시키는 동시에 개발자 간의 결합을 줄이고 애플리케이션 개발 및 반복을 가속화할 수 있습니다.
마이크로서비스 아키텍처에서 비즈니스 요청은 완료하기 위해 여러 서비스 단위를 호출해야 하며 이는 트랜잭션 관리라는 매우 중요한 문제를 야기합니다. 비즈니스 요청에 여러 서비스 단위가 포함된 경우 데이터 일관성을 보장하기 위해 이러한 서비스 단위가 동일한 트랜잭션 관리하에 함께 제출되거나 함께 롤백될 수 있는지 확인해야 합니다. 그렇지 않으면 반복 제출, 일관성 없는 데이터 등 다양한 문제가 발생하게 됩니다.
Spring Cloud 마이크로서비스 아키텍처에는 일반적으로 분산 트랜잭션 관리를 수행하는 세 가지 방법이 있습니다.
아래에서는 분산 트랜잭션 관리 문제를 처리하는 데 가장 적합한 솔루션을 선택하기 위해 이 세 가지 솔루션을 각각 소개하고 비교해 보겠습니다.
이 솔루션의 아이디어는 다음과 같습니다. 각 서비스 단위는 내부적으로 로컬 트랜잭션 관리자를 유지 관리합니다. 서비스 단위는 데이터 작업을 수행해야 할 때 먼저 트랜잭션을 열고 데이터 작업을 수행합니다. 그런 다음 트랜잭션을 커밋하거나 롤백합니다.
예: 주문 시스템이 이체 작업을 수행하기 위해 계정 시스템을 호출해야 하는 경우 주문 시스템은 주문 데이터를 자체 데이터베이스에 직접 삽입하거나 주문 데이터를 주문의 로컬 트랜잭션 관리자 컨텍스트에 삽입합니다. . 그런 다음 주문 시스템은 계정 시스템의 전송 서비스를 호출하여 전송 작업을 수행합니다. 또한 작업의 원자성과 일관성을 보장하기 위해 전송 서비스 내부에서 로컬 트랜잭션 관리자를 활성화해야 합니다. 마지막으로 모든 것이 순조롭게 진행되면 주문 시스템은 트랜잭션을 커밋할 수 있고, 그렇지 않으면 트랜잭션을 롤백합니다.
이 솔루션의 장점은 간단하고 이해하기 쉽다는 것입니다. 추가 구성 요소에 의존할 필요가 없으며 Spring에서 제공하는 @Transactional 주석을 사용하여 직접 구현할 수 있습니다. 단점은 트랜잭션 관리 코드를 수동으로 작성해야 하고 유연성이 부족하다는 것입니다. 또한 비즈니스 운영에서 여러 타사 서비스 시스템을 호출해야 하는 경우 이 솔루션의 구현이 매우 복잡해집니다.
이 솔루션의 아이디어는 메시지 대기열의 특성을 사용하여 트랜잭션 관리를 달성하는 것입니다. 비즈니스 요청이 여러 서비스 단위를 호출해야 하는 경우 먼저 요청을 메시지 대기열에 넣은 다음 각 서비스 단위가 메시지 대기열에서 요청을 가져와 처리합니다. 메시지 큐가 트랜잭션 기능을 지원하는 경우 이러한 처리 작업은 함께 제출되거나 함께 롤백되는 동일한 트랜잭션에 있게 됩니다.
예: 주문 시스템이 배송 작업을 위해 물류 시스템을 호출해야 하는 경우 주문 시스템은 메시지 대기열에 "배송 요청" 메시지를 게시합니다. 물류 시스템은 메시지를 수신한 후 배송 작업을 수행해야 하며, 그렇지 않으면 트랜잭션이 롤백됩니다. 주문 시스템이 자체 로컬 데이터베이스를 운영해야 하는 경우 주문 시스템도 메시지 대기열 트랜잭션에 참여해야 합니다.
이 솔루션의 장점은 트랜잭션 관리 코드를 수동으로 작성하지 않아도 되고 트랜잭션의 일관성과 원자성을 보장할 수 있다는 것입니다. 단점은 메시지 대기열에 의존해야 한다는 점입니다. 메시지 대기열의 구성 및 유지 관리가 더 복잡해지고 시스템 규모가 크면 메시지 대기열의 처리량과 지연이 병목 현상이 됩니다.
이 솔루션의 아이디어는 타사 분산 트랜잭션 관리 프레임워크를 사용하여 트랜잭션 관리를 구현하는 것입니다. 예를 들어, Alibaba의 Seata 프레임워크를 사용하여 서비스 간 분산 트랜잭션을 쉽게 구현할 수 있습니다.
예: 주문 시스템이 이체 작업을 위해 계정 시스템을 호출해야 하는 경우 주문 시스템은 Seata 프레임워크에서 제공하는 분산 트랜잭션 서비스를 호출하여 분산 트랜잭션을 생성할 수 있습니다. 그런 다음 주문 시스템과 계정 시스템 모두 이 분산 트랜잭션 관리에 참여하고 데이터 작업을 수행한 다음 트랜잭션을 함께 제출하거나 롤백할 수 있습니다. Seata 프레임워크를 사용하는 경우 각 서비스 단위에서 해당 구성을 설정해야 합니다. 이 구성에는 데이터 소스 및 분산 트랜잭션과 관련된 매개변수가 포함됩니다.
이 솔루션의 장점은 성숙한 분산 트랜잭션 관리 프레임워크를 사용하여 트랜잭션 관리 문제를 최대한 피할 수 있고 강력한 확장성을 갖는다는 것입니다. 단점은 추가적인 구성과 코드 조정이 필요하고, 서비스 단위와 업무 프로세스가 많아지면 관리의 복잡성이 증가한다는 점이다.
위의 세 가지 솔루션은 각각 장단점이 있습니다. 비즈니스 요구 사항과 시스템 설계에 따라 가장 적합한 솔루션을 선택해야 합니다. 물론 실제 프로젝트에서는 좀 더 특수한 상황이 발생할 수 있으므로 유연하게 처리해야 합니다.
Spring Cloud 마이크로서비스 아키텍처의 경우 트랜잭션 관리는 반드시 고려해야 할 문제입니다. 트랜잭션이 제대로 처리되지 않으면 비즈니스에 숨겨진 큰 위험이 초래됩니다. 따라서 아키텍처 설계 및 개발에서는 분산 트랜잭션 관리의 원칙과 모범 사례를 엄격하게 따르고 분산 트랜잭션 관리의 복잡성을 최대한 줄여 애플리케이션의 신뢰성과 안정성을 보장해야 합니다.
위 내용은 Spring Cloud 마이크로서비스 아키텍처에서의 트랜잭션 관리의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!