Zrozumienie brokerów komunikatów. Poznanie mechaniki przesyłania wiadomości za pomocą ActiveMQ i Kafki. Rozdział 1

Witam wszystkich!

Zacząłem tłumaczyć małą książkę:
«Zrozumienie brokerów wiadomości",
autor: Jakub Korab, wydawca: O'Reilly Media, Inc., data publikacji: czerwiec 2017, ISBN: 9781492049296.

Ze wstępu do książki:
”... Ta książka nauczy Cię, jak myśleć o systemach przesyłania wiadomości przez brokerów, porównując i kontrastując dwie popularne technologie brokerów: Apache ActiveMQ i Apache Kafka. Przedstawi przypadki użycia i zachęty rozwojowe, które skłoniły ich programistów do przyjęcia bardzo różnych podejść do tego samego obszaru – przesyłania wiadomości między systemami za pomocą pośredniczącego brokera. Przyjrzymy się tym technologiom od podstaw i podkreślimy wpływ różnych wyborów projektowych. Zyskasz dogłębną wiedzę na temat obu produktów, zrozumiesz, w jaki sposób należy ich używać, a czego nie należy, a także zrozumiesz, na co zwrócić uwagę, rozważając w przyszłości inne technologie przesyłania wiadomości ... "

Dotychczas przetłumaczone fragmenty:
Rozdział 1 Wstęp
Rozdział 3. Kafka

Ukończone rozdziały będę publikować po ich przetłumaczeniu.

ROZDZIAŁ 1

Wprowadzenie

Przesyłanie wiadomości między systemami to jeden z najmniej rozumianych obszarów IT. Jako programista lub architekt możesz być bardzo zaznajomiony z różnymi frameworkami i bazami danych. Jednak prawdopodobnie masz jedynie przelotną wiedzę na temat działania technologii przesyłania wiadomości opartych na brokerach. Jeśli tak się czujesz, nie martw się, jesteś w dobrym towarzystwie.

Ludzie zazwyczaj mają bardzo ograniczony kontakt z infrastrukturą przesyłania wiadomości. Często łączą się z systemem stworzonym dawno temu lub pobierają dystrybucję z Internetu, instalują ją w PROM i zaczynają pisać dla niej kod. Po uruchomieniu infrastruktury w PROM skutki mogą być mieszane: wiadomości giną z powodu awarii, wysyłanie nie działa zgodnie z oczekiwaniami, albo brokerzy „zawieszają” Twoich producentów lub nie wysyłają wiadomości do Twoich konsumentów.

Brzmi znajomo?

Typowym scenariuszem jest sytuacja, w której kod przesyłania wiadomości działa na razie świetnie. Dopóki nie przestanie działać. Ten okres wprowadza czujność w fałszywe poczucie bezpieczeństwa, co prowadzi do powstania większej liczby kodu opartego na fałszywych przekonaniach na temat podstawowego zachowania technologii. Kiedy coś zaczyna iść nie tak, stajesz przed niewygodną prawdą: tak naprawdę nie zrozumiałeś podstawowego zachowania produktu ani kompromisów wybranych przez autorów, takich jak wydajność kontra niezawodność lub transakcyjność a skalowalność pozioma .

Bez głębokiego zrozumienia sposobu działania brokerów ludzie formułują pozornie rozsądne stwierdzenia na temat swoich systemów przesyłania wiadomości, takie jak:

  • System nigdy nie utraci wiadomości
  • Wiadomości będą przetwarzane sekwencyjnie
  • Dodanie odbiorców przyspieszy działanie systemu
  • Wiadomości zostaną dostarczone tylko raz

Niestety, niektóre z tych stwierdzeń opierają się na założeniach, które mają zastosowanie tylko w określonych okolicznościach, inne natomiast są po prostu błędne.

Ta książka nauczy Cię, jak myśleć o systemach przesyłania wiadomości opartych na brokerach, porównując i kontrastując dwie popularne technologie brokerów: Apache ActiveMQ i Apache Kafka. Przedstawi przypadki użycia i zachęty rozwojowe, które skłoniły ich programistów do przyjęcia bardzo różnych podejść do tego samego obszaru – przesyłania wiadomości między systemami za pomocą pośredniczącego brokera. Przyjrzymy się tym technologiom od podstaw i podkreślimy wpływ różnych wyborów projektowych. Zyskasz dogłębną wiedzę na temat obu produktów, zrozumiesz, w jaki sposób należy ich używać, a czego nie należy, a także zrozumiesz, na co należy zwrócić uwagę, rozważając w przyszłości inne technologie przesyłania wiadomości.

Zanim zaczniemy, omówmy podstawy.

Co to jest system przesyłania wiadomości i dlaczego jest potrzebny?

Aby dwie aplikacje mogły się ze sobą komunikować, muszą najpierw zdefiniować interfejs. Zdefiniowanie tego interfejsu obejmuje wybór transportu lub protokołu, takiego jak HTTP, MQTT lub SMTP, oraz negocjowanie formatów komunikatów, które będą wymieniane między systemami. Może to być rygorystyczny proces, taki jak zdefiniowanie schematu XML z wymaganiami dotyczącymi kosztów ładunku komunikatu, lub może być znacznie mniej formalny, na przykład umowa między dwoma programistami, że część żądania HTTP będzie zawierać identyfikator klienta.

O ile format komunikatów i kolejność ich wysyłania są spójne pomiędzy systemami, mogą one komunikować się między sobą nie martwiąc się o implementację drugiego systemu. Elementy wewnętrzne tych systemów, takie jak używany język programowania lub framework, mogą z czasem ulegać zmianom. Dopóki sama umowa zostanie utrzymana, interakcja może być kontynuowana bez zmian ze strony drugiej strony. Za pomocą tego interfejsu oba systemy są skutecznie oddzielone (oddzielone).

Systemy przesyłania wiadomości zazwyczaj obejmują pośrednika między dwoma systemami, które współdziałają w celu dalszego oddzielenia nadawcy od odbiorcy lub odbiorców. W tym przypadku system przesyłania wiadomości pozwala nadawcy wysłać wiadomość, nie wiedząc, gdzie jest odbiorca, czy jest aktywny i ile jest jego instancji.

Przyjrzyjmy się kilku analogiom rodzajów problemów rozwiązywanych przez system przesyłania wiadomości i wprowadźmy kilka podstawowych terminów.

Punkt-punkt

Aleksandra idzie na pocztę, aby wysłać Adamowi paczkę. Podchodzi do okna i wręcza pracownikowi paczkę. Pracownik odbiera paczkę i wręcza Aleksandrze paragon. Adam nie musi być w domu w momencie wysłania paczki. Alexandra ma pewność, że paczka w pewnym momencie w przyszłości zostanie dostarczona Adamowi i będzie mogła dalej zajmować się swoimi sprawami. Później w pewnym momencie Adam otrzymuje paczkę.

To jest przykład modelu przesyłania wiadomości punkt-punkt. Poczta pełni tutaj rolę mechanizmu dystrybucji paczek, zapewniając, że każda paczka zostanie doręczona jednorazowo. Korzystanie z poczty oddziela czynność nadania przesyłki od jej doręczenia.
W klasycznych systemach przesyłania wiadomości realizowany jest model punkt-punkt poprzez kolejki. Kolejka działa jak bufor FIFO (pierwsze weszło, pierwsze wyszło), który może subskrybować jeden lub więcej konsumentów. Każda wiadomość jest dostarczana tylko jednemu z abonentów. Kolejki zazwyczaj mają na celu sprawiedliwą dystrybucję wiadomości wśród konsumentów. Tylko jeden konsument otrzyma tę wiadomość.

Termin „trwały” odnosi się do kolejek. Niezawodność to właściwość usługi zapewniająca, że ​​system przesyłania wiadomości będzie utrwalał wiadomości w przypadku braku aktywnych subskrybentów, dopóki konsument nie zapisze się do kolejki dostarczania wiadomości.

Niezawodność jest często mylona z trwałość i chociaż te dwa terminy są używane zamiennie, pełnią różne funkcje. Trwałość określa, czy system przesyłania wiadomości zapisuje wiadomość w jakimś magazynie pomiędzy jej otrzymaniem a wysłaniem do konsumenta. Wiadomości wysyłane do kolejki mogą, ale nie muszą, być trwałe.
Wiadomości typu punkt-punkt są stosowane, gdy przypadek użycia wymaga jednorazowej akcji na wiadomości. Przykładami mogą być wpłata środków na konto lub realizacja zamówienia dostawy. Omówimy później, dlaczego sam system przesyłania wiadomości nie jest w stanie zapewnić jednorazowej dostawy i dlaczego kolejki mogą w najlepszym razie zapewnić gwarancję dostawy przynajmniej raz.

Wydawca-Abonent

Gabriella wybiera numer konferencji. Gdy jest połączona z konferencją, słyszy wszystko, co mówi rozmówca, a także resztę uczestników połączenia. Kiedy się wyłącza, tęskni za tym, co zostało powiedziane. Po ponownym nawiązaniu połączenia nadal słyszy, co się do niej mówi.

To jest przykład modelu przesyłania wiadomości publikuj-subskrybuj. Połączenia konferencyjne działają jako mechanizm rozgłaszania. Osoba mówiąca nie przejmuje się tym, ile osób aktualnie uczestniczy w rozmowie – system gwarantuje, że każda osoba aktualnie połączona usłyszy, co zostanie powiedziane.
W klasycznych systemach przesyłania wiadomości realizowany jest model przesyłania wiadomości typu publikacja-subskrypcja tematy. Temat zapewnia tę samą metodę rozgłaszania, co mechanizm konferencji. Gdy wiadomość jest wysyłana do tematu, jest ona rozpowszechniana dla wszystkich subskrybowanych użytkowników.

Tematy są zazwyczaj zawodny (nietrwały). Podobnie jak słuchacz, który nie słyszy, co się mówi podczas połączenia konferencyjnego, gdy słuchacz się rozłączy, tak też subskrybenci tematu tracą wszelkie wiadomości wysyłane w trybie offline. Z tego powodu możemy powiedzieć, że tematy zapewniają gwarancję dostawy nie więcej niż raz dla każdego konsumenta.

Wiadomości typu „publikuj i subskrybuj” są zwykle stosowane, gdy wiadomości mają charakter informacyjny, a utrata jednej wiadomości nie jest szczególnie znacząca. Na przykład temat może przesyłać odczyty temperatury z grupy czujników raz na sekundę. System zainteresowany aktualną temperaturą i subskrybujący temat nie będzie się martwił, jeśli przeoczy jakiś komunikat - w niedalekiej przyszłości pojawi się kolejny.

modele hybrydowe

Strona sklepu umieszcza wiadomości o zamówieniach w „kolejce wiadomości”. Głównym odbiorcą tych komunikatów jest system wykonawczy. Ponadto system audytu powinien posiadać kopie tych komunikatów o zamówieniach w celu późniejszego śledzenia. Obydwa systemy nie mogą przepuszczać wiadomości, nawet jeśli same systemy są niedostępne przez jakiś czas. Strona internetowa nie powinna znać innych systemów.

Przypadki użycia często wymagają połączenia modeli przesyłania wiadomości typu publikowanie-subskrybowanie i typu punkt-punkt, na przykład gdy wiele systemów wymaga kopii wiadomości, a aby zapobiec utracie wiadomości, wymagana jest zarówno niezawodność, jak i trwałość.

W takich przypadkach wymagane jest miejsce docelowe (ogólne określenie kolejek i tematów), które dystrybuuje wiadomości zasadniczo tematycznie, tak aby każda wiadomość była wysyłana do osobnego systemu zainteresowanego tymi wiadomościami, ale także w którym każdy system może zdefiniować kilku odbiorców odbierających przychodzące wiadomości, co przypomina bardziej kolejkę. Typ odczytu w tym przypadku to raz dla każdego zainteresowanego. Te hybrydowe miejsca docelowe często wymagają trwałości, aby w przypadku przejścia konsumenta w tryb offline wiadomości wysłane w tym czasie zostały odebrane po ponownym nawiązaniu połączenia.

Modele hybrydowe nie są nowe i można ich używać w większości systemów przesyłania wiadomości, w tym zarówno w ActiveMQ (za pośrednictwem wirtualnych lub złożonych miejsc docelowych, które łączą tematy i kolejki), jak i w Kafce (w domyśle, jako podstawowa właściwość projektu miejsca docelowego).

Teraz, gdy mamy już podstawową terminologię i rozumiemy, do czego możemy wykorzystać system przesyłania wiadomości, przejdźmy do szczegółów.

Tłumaczenie wykonane: tele.gg/middle_java

Poniższa przetłumaczona część: Rozdział 3. Kafka

To be continued ...

Źródło: www.habr.com

Dodaj komentarz