Jaka jest typowa strategia dotycząca wersji dla RabbitMQ?

Question

Rozpocząłem pracę nad nowym projektem i zostaliśmy poproszeni o zbudowanie systemu jako serii mikro usług, wykorzystujących RabbitMQ jako warstwę komunikacyjną między nimi.

Podczas tworzenia interfejsów API usług REST preferuję używanie nagłówka HTTP akceptującego do kontrolowania wersji i widzę, że można używać wymiany nagłówków w RabbitMQ do kierowania wiadomości w podobny sposób. Jednak, ponieważ jest to wyłącznie wewnętrzny system przesyłania wiadomości, nie jestem pewien, czy dodatkowa złożoność wymiany nagłówków jest naprawdę warta czasu?

Jaka jest typowa konfiguracja do wersjonowania wiadomości RabbitMQ? Wydaje mi się, że są opcje:

1. New vhost dla każdej wersji
2. Każda wymiana posiada wersję w nazwie (np MyExchange-V1, MyExchange-v2, ... itd.)
3. kolejki są wersjami
4. klucze routingu są wersjami Exchange (MyRoute-2.1. *)
5. Użyj nagłówek

Dzięki za wejście może być.

Answer 1

pójdę z wersji systemu routingu kluczową dla 2 głównych powodów:

Konsumenci będą mogli powiązać (przez kolejek oczywiście) do ich zgodnych wersji za pośrednictwem wielu powiązań. Korzystanie z wersji semantycznej (http://semver.org/) byłoby tu zastosowane za pomocą kryteriów asterix i hash.

Nie jesteś zobowiązany do używania Rabbitmq, ponieważ klucz routingu jest standardową funkcją AMQP