RabbitMQ 설정 변경 자동화

Question

Spring Integration + RabbitMQ를 사용하는 프로젝트가 있습니다. 우리는 아직 초기 단계에 있으므로 RabbitMQ 구성을 비롯하여 통합 아키텍처의 토폴로지를 빠르게 변경하고 있습니다.

우리는 핸즈프리 배포로 지속적인 배포를 수행하려고합니다.

스프링 구성에 선언 된 <rabbit:admin /> 요소가 있는데,이 요소는 새로운 교환이나 큐를 추가 할 때 잘 처리됩니다.

그러나 기존 교환/대기열의 구성을 변경하는 업데이트를 배포 할 때 실패합니다. 우리는 우리가 직접 큐에 메시지를 선언 TTL을 변경 팬 아웃 교환

에 직접 대기열을 전환

• : 때문에

  최근 배포 부부는 실패했다.

두 경우 모두 새 인스턴스를 만드는 대신 기존 구성을 변경해야합니다. 이러한 업데이트가 적용되지 않아 시작에 실패합니다.

모두 해결 방법은 간단합니다. 문제가되는 리소스를 삭제하고 응용 프로그램을 다시 시작하면 <rabbit:admin />이 (가) 올바른 킥으로 대체됩니다.

그러나 프로덕션 시스템에서는이를 수행 할 수 없습니다. 또한 현재 배포 과정에서 스크립팅되지 않았으므로 지속적인 배포가 더욱 어려워졌습니다.

RabbitMQ 토폴로지에 대한 업데이트를 처리 할 수있는 지속적인 배포 전략에는 어떤 도구 또는 전략을 사용할 수 있습니까?

Answer 1

곧 1.2 릴리스 (현재 이정표 1에서 - 1.2.0.M1)를 지금 ignore-declaration-exceptions (대신 초기화 실패의) 구성 문제를 기록하기에 RabbitAdminan option있다.

기존 구성은 변경되지 않지만 경고를 로깅하는 동안 응용 프로그램을 초기화 할 수 있습니다.

Answer 2

새로운 교환을 만들고 기존 바인딩에 새로운 바인딩을 추가하는 방법을 들어 보았습니다. 이 경우 게시자를 다음 Exchange로 이전 할 수 있으며 소비자는 같은 대기열에서 소비합니다. 모두가 이동하면 이전 대기열을 삭제할 수 있습니다. 이전 대기열을 다시 만들고 다시 이전 이름으로 이동할 수 있습니다.

대기열을 변경하면 새 설정으로 새 대기열을 작성하고 동일한 교환기에 바인드 할 때 중복 메시지가 발생할 가능성이 있으므로이 작업은 더 어려워집니다. 이 작업이 새로운 교환 (기존의 구성과 동일한 구성으로)과 함께 수행되면 중복 메시지를 방지 할 수 있습니다.

삭제 된 대기열을 유지할 수없는 중요한 시스템의 경우 새 클러스터를 만들고 모든 클라이언트를 올바르게 구성된 새 클러스터로 이동하는 편이 낫습니다. 새 클러스터를 만드는 대신 기존 클러스터를 분할하여 하나의 노드를 수정하고 이전 노드를 지우고 새 노드에 연결할 수 있습니다.

요리사의 교환/대기열 구성을 관리하는 데 익숙해 졌으므로 게시자와 소비자가 새로운 노드에 연결하는 순서에주의하지 않아도됩니다.

내가 본 것 중에 가장 잘 들었습니다. 이전 버전과 호환되지 않는 AMQP 변경 사항은 이와 관련하여 DB 마이그레이션과 유사합니다. 호환되는 변경 사항을 추가하는 작업은 자동화하기는 쉽지만 호환되지 않는 변경 작업에는 약간의주의가 필요합니다.