클라우드 환경에서 새 인스턴스가 배포되면 통합 테스트가 실행됩니다. 그러나 기존 인스턴스 (이전 버전)가 계속 실행되는 동안 새 코드가 배포중인 서비스의 큐에 메시지를 주입하기 때문에 까다로워집니다. 우리는 청색/녹색 배치가 있습니다.RabbitMQ로 청색/녹색 배치를 처리하는 방법은 무엇입니까?
RabbitMQ가 특정 버전에 대해서만 대기열에서 청취하는 많은 청취자를 가질 수 있습니까?
예를 들어, 실행중인 모든 서버는 2017.10.20 (이전 버전) 또는 이전 버전의 메시지를 읽지 만 최신 버전의 메시지는 읽지 않습니다.
이렇게하면 새로운 서비스를 배포 할 수 있으며 다른 드롭 릿은 테스트 메시지를 읽을 수 없습니다.
배포 할 새 서비스는 기존 서비스와 동일한 기능을합니다. 그것은 현재 실행중인 서비스와 동일한 메시지 유형을 생성하고 소비합니다.
동일한 대기열에 테스트 및 프로덕션 메시지가 혼합 된 것처럼 보입니다. 그것이 맞다면, 나는 그것들을 분리해야한다고 생각합니다. 솔루션은 게시 된/구독하는 새 서비스를 프로덕션과 다른 큐 집합 integration test에 배포 할 수 있습니다. 통합 테스트가 만족 스러우면 인스턴스를 pub/sub로 전환 (예 : 새 경로/대기열 이름을 사용하여 명령 메시지를 보내어) 생산 대기열로 전환하거나 테스트 대기열을 새로운 생산 대기열로 설정하고 이전 세트를 폐기하십시오 서비스와 대기열을
예 : 현재 버전 3.1이 있습니다. my_command_a_3.1, my_command_b_3.1 등의 대기열/경로에 대한 pub/subs가 있습니다. 그런 다음 새 3.2 버전의 환경을 배포하여 3.1 버전과 병렬로 실행합니다. 모든 서비스는 대기열/경로 my_command_a_3.2 및 my_command_b_3.2에서 작동합니다. 그런 다음 3.2 버전에 만족하면 대기열과 함께 3.1 버전을 폐기합니다. 먼저 큐를 배출해야합니다 (먼저 생산자를 전환하고 큐를 비울 때까지 기다리지 말고 소비자를 끕니다)
질문에 대한 가장 직접적인 대답은 다음과 같습니다. 귀하의 소비자를 만들 수 있습니다 nack 소비자가 메시지의 버전을 지원하지 않으면 (메시지 자체에 버전을 입력해야 함) 브로커에게 다시 요청하도록 요청합니다. 그런 다음 새로운 버전 소비자가 어떤 시점에서 처리하게됩니다 (라운드 로빈 알고리즘은 새 소비자에게 새 메시지를 전달합니다). 그것은 브로커 측에서 추가적인 쓸모없는 작업을 생성하고 어떤 메시지에 대해서도 실제로 처리 될 때와 다시 반복 될 때를 알지 못하기 때문에 제 생각에는 더러워집니다.
새 서비스를 배포하면 메시지가 생성됩니까? 메시지를 소비합니까? 양자 모두? –
둘 다. 새로운 서비스는 기존 서비스와 동일하게 작동합니다. 나는 그 질문을 갱신 할 것이다. –