API nServiceBus 및 REST API를 사용하여 버전 관리 및 장기 실행 프로세스

Question

우리는 웹 API를 구축하고 모든 비동기 및 장기 실행 프로세스에 대한 메시징을 위해 nServiceBus를 사용하고 있습니다.

새로운 대기열 집합을 사용하는 경우 새로운 버전의 API를 개발할 때 질문이 생깁니 까?

처럼, blobstore.v1.timeout

blobstore.v1.outbound

을 blobstore.v1.inbound

• 은 API 버전 1에 대한
• blobstore.v1.audit

및 API 버전 2의 경우

• 는
• 는
• blobstore.v2.timeout
• blobstore.v2.audit

blobstore.v2.outbound blobstore.v2.inbound 또는 우리와 큐의 동일한 세트를 사용하기 위해 노력한다 여러 메시지 형식 및 처리기 (요구 사항 변경 및 메시지 형식 변경을 가정)

장기적 관점에서 장단점을 이해하려고 노력 중입니다. 별도의 대기열 세트가 있으면 호환성 및 사교성에 대해 걱정하지 않고도 서로 다른 API 버전을 별도로 구축, 배포 및 관리 할 수 ​​있습니다.

개인적으로 나는 후자에 기대고 있지만 호환성과 업그레이드에 대한 도전 과제는 명확하게 이해되지 않았습니다.

이전과 비슷한 시나리오를 다룬 경우 경험, 생각, 제안 및 권장 사항을 공유하십시오.

시간을 많이 주시면 감사하겠습니다.

Answer 1

릴리스 빈도가 높을수록 버전 별 대기열 전략이 적합하지 않게되고 하위 버전과의 호환성이보다 중요해질 것입니다 (구조 및 동작 모두에서).

Answer 2

메시지의 다른 버전을 지원하기 위해 다른 큐 집합이나 단일 큐로 이동하는 결정은 메시지 간의 차이 정도에 따라 달라집니다. versioning sample에서 V2 메시지는 인터페이스 상속으로 나타낼 수있는 V1 메시지의 순수 확장입니다. V1 메시지의 가입자는 V1 메시지의 적절한 수퍼 세트 인 V2 메시지를 수신 할 수 있습니다. 이 경우 동일한 큐를 유지하고 필요에 따라 구독자 만 업데이트하는 것이 좋습니다. 메시지가 크게 다른 경우 두 번째 큐 집합을 배포하는 것이 더 쉬울 수 있습니다. 이것은 당신이 묘사 한 혜택, 즉 격리를 가지고 있습니다. 종속 구성 요소가 엉망이 될 염려는 없습니다. 그러나 대기열에 의존 할 수있는 모든 것을 고려해야하므로 시스템에 더 큰 영향을 미칩니다. V2 롤아웃을 완료하려면 여러 끝점과 서비스를 한 번에 배포해야 할 수 있습니다.