Tag RabbitMQ

Logika nazywania kolejek i exchange była dla mnie na początku mocno niezrozumiała. Nie mogłem też znaleźć w dokumentacji nic, co by to jasno wyjaśniało.

W tym tekście postaram się opisać kilka przykładów, które pokazują jak to działa.

Pierwszy przykład to najprostsza konfiguracja – aplikacja publikująca wiadomości, aplikacja konsumująca wiadomości i współdzielony projekt z definicją rekordów wiadomości.

Drugi przykład jest podobny, jednak brak jest wspólnego projektu, a każdy z programów ma własną definicje rekordów wiadomości.

Trzeci przykład pokazuje jak skonfigurować exchange i kolejki pozwalające na użycie większej ilości konsumentów.

W systemach komunikujących się za pomocą wiadomości i systemów kolejkowych, wyróżnia się dwa typy wiadomości – komendy (commands) i zdarzenia (events). Ich obsługa przez system powinna się nieco różnić.

Przedstawiony tym razem przykład obejmuje jeden program publikujący wiadomości będące komendami i zdarzeniami oraz dwa programy konsumujące te wiadomości.

Wiadomości-zdarzenia powinny trafić do wszystkich zainteresowanych konsumentów. Wiadomości-komendy powinny zaś zostać odebrane i przetworzone przez jednego konsumenta (tak, żeby nie zostały przetworzone wielokrotnie).

Do tej pory używałem bibliotek dostarczanych wraz z RabbitMQ, jednak jakiś czas temu, przy okazji jednego z projektów, zaproponowano mi użycie MassTransit do obsługi wymiany wiadomości miedzy mikroserwisami. Okazało się, że jest to całkiem ciekawe rozwiązanie.

MassTransit to otwarty framework wprowadzający warstwę abstrakcji nad systemem wymiany komunikatów. Oficjalnie wspierane są RabbitMQ, Azure Service Bus i Amazon SQS.

Poniżej przykład użycia w aplikacji producenta i konsumenta wiadomości.