Komunikacja w mikroserwisach -- jak powinna być zrealizowana? Oczywiście komunikacja oparta na HTTP jest łatwiejsza do poprawnej implementacji i prawdopodobnie także do zaprojektowania. Zwłaszcza, iż wielu deweloperów i architektów ma sporo doświadczenia z takim podejściem. Z drugiej strony podejście asynchroniczne, oparte na wiadomościach przesyłanych dzięki kolejek ma wiele zalet. Pozwala tworzyć rozwiązania odporne na awarie, które choćby w przypadku wystąpienia usterek czy przeciążeń przez cały czas mogą dostarczać usługi użytkownikom.
Większość komunikacji jaką w FLYR Inc. zrealizowaliśmy w naszym produkcie była synchroniczna, oparta na HTTP. Na pewnym etapie rozwoju systemu okazało się jednak, iż do zrealizowania wymaganej funkcjonalności potrzebujemy czegoś bardziej elastycznego i... asynchronicznego. Jakie decyzje podjęliśmy? Co zrobiliśmy, żeby te decyzje nie były ostateczne, żebyśmy mogli zmienić te, które w przyszłości okażą się błędne? Jak zapewniliśmy, iż deweloperzy będą poprawnie wykorzystywać message brokera, adekwatnie używać jego sterowników, a każdy serwis będzie miał wiarygodny healthcheck dla Kubernetes? Na te pytania postaram się odpowiedzieć opowiadając swoją historię. A potem opowiem też parę historii o tym z jakimi problemami walczyliśmy przy samym wdrażaniu asynchronicznej komunikacji w naszym systemie i czego się przy tej okazji nauczyliśmy.
Nie mam dla Was jedynie słusznych rozwiązań i rad, które zawsze się sprawdzą. Ale mogę podzielić się z Wami błędami, które udało nam się naprawić i tymi, których udało nam się uniknąć.
Website: https://jdd.org.pl
Facebook: https://www.facebook.com/JDDconf
Twitter: https://twitter.com/JDD_Krakow
