Projektuj · Łącz · Wdrażaj · Utrzymuj

Przed wyruszeniem w drogę należy z... klonować repo. Ale nie tylko. Zanim wskoczysz w moduły wokół messagingu, wprowadzimy Cię w strukturę kursu, narzędzia jakie otrzymasz do nauki oraz dziedzinę problemową, w której będziesz się poruszać.

• Założenia kursu8:50
• Struktura kursu4:58
• Dziedzina problemowa14:11
• Anomalie w TicketFlow4:09
• Kod i infrastruktura w TicketFlow13:49

Zanim przejdziemy do komunikacji asynchronicznej, omówimy ograniczenia i wyzwania komunikacji synchronicznej. Dzięki temu zrozumiesz, dlaczego ten model nie zawsze sprawdza się w architekturze rozproszonej.

• Dyskusja wprowadzająca4:25
• Komunikacja synchroniczna1:49
• Komunikacja synchroniczna w TicketFlow13:19
• Wyzwania komunikacji synchronicznej2:16
• Problemy z czasem odpowiedzi i wydajnością3:01
• Zależność od dostępności wszystkich usług4:36
• Problemy spowodowane przez błędy, skalowanie i coupling6:50
• Dyskusja podsumowująca4:31
• Challenge

Wiemy już jakie wyzwania stawia przed nami komunikacja synchroniczna. Pora więc spróbować innego podejścia i - póki co - w oparciu o samą teorię omówić alternatywę - komunikację asynchroniczną.

• Dyskusja wprowadzająca2:33
• Idea komunikacji asynchronicznej9:19
• Składowe komunikacji asynchronicznej14:07
• Adres i droga komunikatu10:31
• Message broker6:57
• Dyskusja podsumowująca2:49

Wygląda na to, że znaleźliśmy rozwiązanie naszych problemów - komunikacja asynchroniczna i message broker pozwolą nam zbudować bardziej odporny i rozwijalny system rozproszony. A skoro mowa o brokerze, pora przedstawić nasze główne narzędzie w nadchodzących modułach - RabbitMQ i protokół AMQP.

• Dyskusja wprowadzająca3:03
• RabbitMQ i protokół AMQP7:06
• Building blocks w RabbitMQ7:24
• Topologia i projektowanie w RabbitMQ3:44
• Uruchomienie RabbitMQ20:36
• Dyskusja podsumowująca3:10
• Challenge

RabbitMQ zwarty i gotowy czeka już na nas w swoim Dockerowym kontenerze. Pora byśmy wskoczyli w kod i połączyli się z brokerem wiadomości, stawiając pierwsze kroki z jego SDK.

• Dyskusja wprowadzająca3:20
• RabbitMQ.Client1:43
• Połączenie (Connection)13:16
• Kanał (Channel)8:59
• Virtual Host8:10
• Dyskusja podsumowująca5:51
• Challenge

Połączono! Skoro wiemy już jak rozpocząć pracę z naszym brokerem, pora byśmy omówili wiadomość, czyli ładunek informacyjny, który jest sednem zarówno komunikacji synchronicznej jak i asynchronicznej.

• Dyskusja wprowadzająca2:26
• Komunikat "w akcji"17:09
• Co zawiera wiadomość?9:26
• Koperta wiadomości8:43
• Semantyka wiadomości (command, event, request/response)7:39
• Topologia - jak wpływa na nią semantyka wiadomości?6:55
• Zakres danych (event notification vs. event-carried state transfer)10:29
• Dyskusja podsumowująca5:59
• Challenge

Wiadomość wiadomością ale ktoś ją przecież musi wysyłać... W tym module poznasz szczegóły nadawcy wiadomości czyli "producenta" oraz narzędzia, jakie mamy dla niego dostępne w RabbitMQ.

• Dyskusja wprowadzająca3:23
• Czego potrzebujemy do publikacji wiadomości?7:17
• Wymiana (Exchange)1:08
• Fanout Exchange6:12
• Direct Exchange6:04
• Topic Exchange9:03
• Headers Exchange7:07
• Alternate Exchange11:19
• Exchange-to-exchange5:32
• Topologia od strony producenta wiadomości5:56
• Publikowanie wiadomości w TicketFlow29:14
• Default exchange11:10
• Dyskusja podsumowująca4:24
• Challenge

Wiadomość wyprodukowana, zaadresowana i... no właśnie? Ktoś jeszcze musi tą wiadomość odebrać i skonsumować. Dlatego też w tym module omówimy podstawowe koncepty wokół drugiego (po producencie) ogniwa komunikacji asynchronicznej - konsumenta.

• Dyskusja wprowadzająca3:32
• Konsument - podstawy12:31
• Pull vs. push, czyli modele konsumowania10:33
• Przepływ wiadomości w aplikacji27:57
• Przepływ wiadomości - mniej typowe scenariusze16:22
• Skalowanie konsumenta9:22
• Architektura pipes and filters18:10
• Tworzenie topologii z aplikacji18:05
• Kolejki tymczasowe17:31
• Wiadomość o określonym czasie życia12:17
• Dyskusja podsumowująca7:08

Wiadomość - jest. Producent - jest. Konsument - jest. Czyli co, kończymy kurs? Nic bardziej mylnego! Dopiero teraz zaczynają się schody i wkraczamy w zaawansowane koncepty komunikacji asynchronicznej. W tym module poznasz bowiem wyzwania wynikające z różnych modeli dostarczania wiadomości.

• Dyskusja wprowadzająca2:30
• Kontekst problemu dostarczania wiadomości2:54
• Acknowledgment i DeliveryTag2:10
• At least once delivery12:15
• At-most once delivery6:09
• Exactly-once delivery - dlaczego w większości przypadków to ściema?3:41
• Dyskusja podsumowująca3:52
• Challenge

Mądrzejsi o wiedzę z poprzedniego modułu z pokorą wkraczamy w kolejne zaawansowane tematy. Wiedząc, że ta sama wiadomość do konsumenta dotrzeć może więcej niż raz, musimy się jakoś zabezpieczyć.

• Dyskusja wprowadzająca2:21
• Duplikaty wiadomości - jak możemy do nich podejść?2:54
• Deduplikacja biznesowa6:00
• Deduplikacja techniczna w teorii2:42
• Deduplikacja techniczna w praktyce30:47
• Dyskusja podsumowująca6:21
• Challenge

Pierwszy poważny problem rozwiązany - nie straszne nam już zduplikowane wiadomości. Nie da się jednak ukryć, że dużo szybciej napotkamy dużo bardziej przyziemne problemy - np. co, gdy w trakcie odbioru wiadomości przytrafią się nam aplikacyjne "fajerwerki"?

• Dyskusja wprowadzająca3:32
• Podejścia do rozwiązywania błędów w komunikacji9:15
• Ponawianie odbioru przez konsumenta15:06
• Dead letter queue (DLQ) - konsument13:47
• Błędy jako zdarzenia po stronie konsumenta14:18
• Wykrywanie braku konsumenta przez producenta13:24
• Wykrywanie błędu zapisu wiadomości przez producenta12:22
• Dyskusja podsumowująca10:26
• Challenge

Komunikat wysłany, a może już nawet przetworzony przez oczekujących konsumentów. Jeszcze tylko COMMIT na bazie danych i zamykamy transakcje biznesową a na końcu... Exception?

• Dyskusja wprowadzająca2:53
• Wiadomość jako side-effect12:47
• Outbox pattern2:08
• Zapis wiadomości do outboxa20:03
• Publikowanie wiadomości z outbox19:30
• Bolączki wzorca outbox1:19
• Natychmiastowe publikowanie z outbox18:16
• Skalowanie horyzontalne outbox6:41
• Błędy aplikacji, a wzorzec outbox7:48
• Outbox w scenariuszu biznesowym5:03
• Listen to yourself pattern2:06
• Listen to yourself w scenariuszu biznesowym10:07
• Dyskusja podsumowująca5:54
• Challenge

Z każdym kolejnym modułem nasz system staje się coraz bardziej odporny na przeróżne software'owe turbulencje. Jak to jednak bywa w cyklu życia każdego oprogramowania, przychodzi moment, kiedy trzeba wprowadzić zmiany.

• Dyskusja wprowadzająca3:15
• Ewolucja systemu4:56
• Zmiana wersji payloadu6:10
• Zmiana schematu wiadomości23:07
• Zmiana w topologii5:54
• Dyskusja podsumowująca4:05
• Challenge

Jedna zmiana i pół systemu płonie - co gorszego może nam się przytrafić? Wyobraźmy sobie w takim razie, że wiadomości docierają do nas bezbłędnie. Tylko kolejność jakaś taka... zła?

• Dyskusja wprowadzająca4:16
• Ordering w scenariuszu biznesowym8:47
• Topologia, a kolejność przetwarzania wiadomości17:14
• Prefetch count19:11
• Ordering, a skalowanie horyzontalne konsumenta5:12
• Wersjonowanie, a kolejność przetwarzania wiadomości22:44
• Single Active Consumer (SAC)10:38
• Total ordering vs. causality3:33
• Partycjonowanie przy użyciu consistent hash3:32
• Consistent Hash Exchange37:29
• Consistent Hash Exchange + Single Active Consumer9:16
• Ordering, a logika biznesowa6:48
• Dyskusja podsumowująca7:00
• Challenge

Udało się - wiadomości nie tylko zmierzają ale i przetwarzane są w kolejności. Upewnijmy się jednak, by niewinny restart serwera nie stał się dla naszego systemu katastrofą.

• Dyskusja wprowadzająca3:13
• Po co utrwalać wiadomości?7:58
• Kiedy wiadomość jest utrwalana?12:29
• Outbox jako suplement trwałości brokera9:55
• Trwałość w RabbitMQ 4.0 i beyond6:22
• Dyskusja podsumowująca2:07
• Challenge

15 modułów za nami i message brokerzy nie kryją już przed nami zbyt wielu tajemnic. Warto jednak, byśmy poznali również alternywę w postaci platform streamingowych na przykładzie Apache Kafka.

• Dyskusja wprowadzająca2:55
• Message streaming i Apache Kafka13:35
• Uruchomienie i przykład użycia29:04
• Partitions + consumer groups + offset28:14
• Message streaming vs. message broker - przypadki użycia13:10
• Dyskusja podsumowująca7:28
• Challenge

Dawno minęły już czasy, gdy praca w rozwiązaniach chmurowych była tylko dla wybranych. Dlatego też w tym module zderzysz swoją dotychczasową wiedzę z komunikacji asynchronicznej z rozwiązaniem dostępnym w Azure. Dzięki tym paru lekcjom uświadomisz sobie jak dogłębne zrozumienie fundamentów pozwala wejść z pewnością w nowe rozwiązanie messagingowe.

• Dyskusja wprowadzająca4:28
• Azure i Azure Portal UI14:21
• Topic, Subscription i Queue23:07
• Azure SDK w naszej aplikacji36:38
• Subscription filters14:20
• Deduplikacja15:26
• Sesje21:49
• Dyskusja podsumowująca6:14
• Challenge

Czego oczy nie widzą tego sercu nie żal? Nie w systemach rozproszonych! O ile messaging wiele rzeczy ułatwia, to odnajdywanie się w drodze komunikatu i wyłapywanie błędów z nim związanych do nich nie należy. W tym module poznasz absolutne minimum jeśli chodzi o obserwowalność systemu, jakie powinno towarzyszyć wdrażaniu na produkcję messagingu.

• Dyskusja wprowadzająca3:53
• Observability - dlaczego nie jest opcjonalne?2:40
• Czym jest distributed tracing?1:37
• Distributed tracing w komunikacji synchronicznej21:15
• Distributed tracing z message brokerem23:56
• Dyskusja podsumowująca4:43
• Challenge

Testowanie na prodzie? Dziękuje, postoję! W tym module przeanalizujemy co, jak i kiedy możemy przetestować wystarczająco wcześniej, zanim dojdzie do "pożaru na prodzie".

• Dyskusja wprowadzająca4:03
• Jak możemy testować komunikację asynchroniczną?8:55
• Testowanie integracyjne z TestContainers23:35
• Testy integracyjne producenta wiadomości14:01
• Testy integracyjne konsumenta wiadomości13:32
• Dyskusja podsumowująca3:58
• Challenge

Planowaliśmy skonczyć na 20 modułach ale po co się ograniczać? Poniższe lekcje powstały po pierwszej edycji, by uzupełnić dotychczasową wiedzę zawartą w kursie. Udanej nauki!

• RabbitMQ.Client - wersja 7.x43:21
• Dokumentacja z AsyncAPI i EventCatalog58:56