Какая типичная стратегия управления версиями для RabbitMQ?
Я начал работу над новым проектом, и нас попросили создать систему как ряд микросервисов, используя RabbitMQ в качестве уровня связи между ними.
При разработке API REST я предпочитаю использовать заголовок accepts HTTP для управления версиями, и я вижу, что вы можете использовать обмен заголовком в RabbitMQ для маршрутизации сообщений аналогичным образом. Однако, поскольку это чисто внутренняя система обмена сообщениями, я не уверен, действительно ли добавлена сложность обмена заголовками?
Какова типичная настройка для версий RabbitMQ? Мне кажется, что варианты:
- Новый призрак для каждой версии
- Каждый Exchange имеет версию в имени (например, MyExchange-v1, MyExchange-v2,... и т.д.).
- Очереди версии
- Клавиши маршрутизации версии (myroute-2.1. *)
- Использовать обмен заголовком
Спасибо за любой вклад, который у вас есть.
Ответы
Ответ 1
Я бы включил систему ключевой версии маршрутизации по двум основным причинам:
Потребители смогут связать (через очереди, конечно) с их совместимыми версиями с помощью нескольких привязок. Используя семантическую версию (http://semver.org/), стандарт будет использоваться здесь с помощью критериев астерикса и хэша.
Вы не обязаны использовать Rabbitmq, поскольку ключ маршрутизации является стандартной функцией AMQP