Cześć wszystkim!
Rozpocząłem tłumaczenie niewielkiej książki:
««,
autor: Jakub Korab, wydawnictwo: O’Reilly Media, Inc., data wydania: czerwiec 2017, ISBN: 9781492049296.
Z wprowadzenia do książki:
«… Ta książka nauczy cię myśleć o systemach wymiany wiadomości na brokerach, porównując i przeciwstawiając dwie popularne technologie brokerów: Apache ActiveMQ i Apache Kafka. Przykłady zastosowań i motywacje w rozwoju, które doprowadziły ich twórców do przyjęcia zupełnie różnych podejść w tej samej dziedzinie — wymianie wiadomości między systemami z pośredniczącym brokerem, będą omówione. Przyjrzymy się tym technologiom od podstaw i podkreślimy wpływ różnych opcji projektowych na tej drodze. Zyskasz głębokie zrozumienie obu produktów, wiedzę o tym, jak należy i nie należy ich używać oraz zrozumienie, na co zwracać uwagę przy rozważaniu innych technologii wymiany wiadomości w przyszłości. …»
Przetłumaczone do tej pory części:
Będę publikować zrealizowane rozdziały w miarę postępu tłumaczenia.
ROZDZIAŁ 1
Wprowadzenie
Wymiana wiadomości między systemami to jedna z najmniej zrozumianych dziedzin IT. Jako programista lub architekt możesz być dobrze zaznajomiony z różnymi frameworkami i bazami danych. Jednak prawdopodobnie masz tylko powierzchowne pojęcie o tym, jak działają technologie wymiany wiadomości bazujące na brokerze. Jeśli tak się czujesz, nie martw się, jesteś w dobrej kompaniji.
Ludzie zazwyczaj mają ograniczony kontakt z infrastrukturą wymiany wiadomości. Często łączą się z systemem stworzonym dawno temu lub pobierają dystrybucję z internetu, instalują ją w produkcji i zaczynają pisać kod. Po uruchomieniu infrastruktury w produkcji wyniki mogą być niejednoznaczne: utrata wiadomości podczas awarii, nieprawidłowe działanie wysyłania lub brokerzy, którzy „zawieszają” twoje producentów lub nie wysyłają wiadomości do twoich konsumentów.
Brzmi znajomo?
Typowym scenariuszem jest sytuacja, w której Twój kod do wymiany wiadomości działa doskonale, aż pewnego dnia przestaje. Ten okres usypia czujność i daje fałszywe poczucie bezpieczeństwa, co prowadzi do dalszego pisania kodu opartego na mylnych przekonaniach na temat fundamentalnego zachowania technologii. Kiedy coś zaczyna iść nie tak, stajesz w obliczu niewygodnej prawdy: naprawdę nie zrozumiałeś podstawowego zachowania produktu ani kompromisów dokonanych przez jego twórców, takich jak wydajność vs. niezawodność, czy transakcjonalność vs. horyzontalna skalowalność.
Bez głębokiego zrozumienia, jak działają brokerzy, ludzie składają bardzo rozsądne twierdzenia o ich systemach wymiany wiadomości, takie jak:
- System nigdy nie straci wiadomości.
- Wiadomości będą przetwarzane w sposób sekwencyjny.
- Dodanie konsumentów przyspieszy system.
- Wiadomości będą dostarczane tylko raz.
Niestety, niektóre z tych twierdzeń opierają się na założeniach, które są prawdziwe tylko w określonych okolicznościami, podczas gdy inne są po prostu nieprawdziwe.
Ta książka nauczy Cię myśleć o systemach wymiany wiadomości opartych na brokerach, porównując i przeciwstawiając dwie popularne technologie brokerów: Apache ActiveMQ i Apache Kafka. Przedstawione zostaną przykłady użycia i bodźce rozwoju, które skłoniły ich twórców do zastosowania całkowicie różnych podejść do tej samej dziedziny — wymiany wiadomości pomiędzy systemami z pośredniczącym brokerem. Zbadamy te technologie od podstaw i wskaźemy wpływ różnych opcji projektowych na tej drodze. Uzyskasz głębokie zrozumienie obu produktów, poznasz, jak powinny i nie powinny być używane, oraz dowiesz się, na co zwrócić uwagę przy rozważaniu innych technologii wymiany wiadomości w przyszłości.
Zanim zaczniemy, przejdźmy przez podstawy.
Co to jest system wymiany wiadomości i po co jest potrzebny?
Aby dwa aplikacje mogły komunikować się ze sobą, muszą najpierw zdefiniować interfejs. Definicja tego interfejsu obejmuje wybór transportu lub protokołu, takiego jak HTTP, MQTT lub SMTP, oraz uzgodnienie formatów wiadomości, którymi będą wymieniać się systemy. Może to być rygorystyczny proces, na przykład określenie schematu XML z wymaganiami dotyczącymi ładunku (payload) wiadomości, lub może być znacznie mniej formalne, na przykład umowa między dwoma programistami, że pewna część żądania HTTP będzie zawierała identyfikator klienta.
Dopóki format wiadomości i kolejność ich wysyłania między systemami są uzgodnione, będą mogły one współdziałać bez martwienia się o implementację innego systemu. Wewnątrz tych systemów, takie jak język programowania czy użyta ramka, mogą się z czasem zmieniać. Dopóki sama umowa jest utrzymywana, współpraca może trwać bez zmian z drugiej strony. Te dwa systemy są efektywnie rozdzielone przez ten interfejs.
Systemy wymiany wiadomości zazwyczaj przewidują udział pośrednika między dwoma systemami, które współdziałają, aby dalej rozdzielić nadawcę od odbiorcy lub odbiorców. System wymiany wiadomości umożliwia nadawcy wysłanie wiadomości, nie wiedząc, gdzie znajduje się odbiorca, czy jest aktywny, ani ile ich egzemplarzy.
Rozważmy kilka analogii problemów, które rozwiązuje system wymiany wiadomości, oraz wprowadźmy kilka podstawowych terminów.
Point-to-Point
Aleksandra idzie na pocztę, aby wysłać paczkę do Adama. Podchodzi do okienka i wręcza pracownikowi paczkę. Pracownik odbiera paczkę i wydaje Aleksandrze pokwitowanie. Adam nie musi być w domu w momencie wysyłania paczki. Aleksandra jest pewna, że paczka zostanie dostarczona do Adama w pewnym momencie w przyszłości i może kontynuować swoje sprawy. Później, w pewnym momencie, Adam otrzymuje paczkę.
To przykład modelu wymiany wiadomości punkt-punkt. Pocztowy urząd działa tutaj jako mechanizm dystrybucji paczek, gwarantując, że każda paczka zostanie dostarczona raz. Użycie urzędu pocztowego oddziela akt wysłania paczki od dostarczenia paczki.
W klasycznych systemach komunikacji model „punkt-punkt” jest realizowany przez kolejki. Kolejka działa jako bufor FIFO (pierwszy wszedł, pierwszy wyszedł), do którego może zapisać się jeden lub kilku odbiorców. Każda wiadomość jest dostarczana tylko jednemu z zapisanych odbiorców. Kolejki zazwyczaj starają się sprawiedliwie rozdzielać wiadomości między odbiorcami. Tylko jeden odbiorca otrzyma daną wiadomość.
Do kolejek stosuje się termin „niezawodne” (ang. "durable"). Niezawodność — to właściwość usługi, która zapewnia, że system wymiany wiadomości będzie przechowywał wiadomości w przypadku braku aktywnych subskrybentów, dopóki odbiorca nie zapisze się na kolejkę w celu otrzymania wiadomości.
Niezawodność często mylona jest z permanencją , i choć te dwa terminy są zamienne, pełnią różne funkcje. Permanencja określa, czy wiadomość jest zapisywana przez system wymiany wiadomości w jakimś rodzaj przechowywania między odebraniem a wysłaniem jej do odbiorcy. Wiadomości wysyłane do kolejki mogą być lub nie być trwałe.
Wymiana wiadomości typu „punkt-punkt” jest wykorzystywana, gdy przypadek użycia wymaga jednorazowej akcji z wiadomością. Przykładem może być wpłata na konto lub realizacja zamówienia na dostawę. Omówimy później, dlaczego system wymiany wiadomości sam w sobie nie jest w stanie zapewnić jednorazowej dostawy i dlaczego kolejki mogą w najlepszym razie zapewnić gwarancję dostawy przynajmniej raz.
Publikacja-Subskrypcja
Gabriela wybiera numer konferencji. Podczas gdy jest podłączona do konferencji, słyszy wszystko, co mówi mówca, razem z innymi uczestnikami połączenia. Gdy się rozłącza, pomija to, co zostało powiedziane. Po ponownym połączeniu kontynuuje słuchanie, co jest mówione.
To przykład modelu wymiany wiadomości publikacja-subskrypcja. Konferencja działa jak mechanizm broadcastowy. Mówiąca osoba nie przejmuje się tym, ile osób aktualnie dołączyło do rozmowy - system gwarantuje, że każdy, kto podłączył się w danym momencie, usłyszy to, co jest mówione.
W klasycznych systemach komunikacji model wymiany wiadomości „publikacja-subskrypcja” jest realizowany przez tematyTemat zapewnia taki sam sposób rozgłaszania, jak mechanizm konferencyjny. Gdy wiadomość jest wysyłana do tematu, jest rozdzielana do wszystkich subskrybentów.
Tematy zwykle są nietrwałe (nondurable). Podobnie jak słuchacz, który nie słyszy, co się mówi w rozmowie konferencyjnej, gdy słuchacz się rozłącza, subskrybenci tematu pomijają wszelkie wiadomości, które są wysyłane w momencie, gdy są w trybie offline. Z tego powodu można powiedzieć, że tematy zapewniają gwarancję dostarczenia nie więcej niż raz dla każdego konsumenta.
Wymiana wiadomości typu „publikacja-subskrypcja” jest zwykle stosowana, gdy wiadomości mają charakter informacyjny i utrata jednej wiadomości nie ma większego znaczenia. Na przykład temat może przesyłać odczyty temperatury z grupy czujników raz na sekundę. System, który interesuje się aktualną temperaturą i który subskrybuje temat, nie martwi się, jeśli przegapi wiadomość — inna nadejdzie wkrótce.
Modele hybrydowe
Strona internetowa sklepu umieszcza wiadomości o zamówieniach w „kolejce wiadomości”. Głównym konsumentem tych wiadomości jest system wykonawczy. Ponadto system audytu musi mieć kopie tych wiadomości o zamówieniach do późniejszego monitorowania. Oba systemy nie mogą przegapić wiadomości, nawet jeśli same systemy pozostają niedostępne przez jakiś czas. Strona internetowa nie powinna znać innych systemów.
Scenariusze użycia często wymagają połączenia modeli wymiany wiadomości „publikacja-subskrypcja” i „punkt-punkt”, na przykład, gdy kilka systemów potrzebuje kopii wiadomości, a do zapobiegania utracie wiadomości wymagana jest zarówno niezawodność, jak i trwałość.
W takich przypadkach wymagany jest odbiorca (destination) (ogólny termin dla kolejek i tematów), który rozdziela wiadomości głównie jak temat, tak żeby każda wiadomość była wysyłana do oddzielnego systemu zainteresowanego tymi wiadomościami, ale również w którym każdy system może określić kilku konsumentów, którzy otrzymują nadchodzące wiadomości, co bardziej przypomina kolejkę. Typ odczytu w tym przypadku — raz dla każdej zainteresowanej stronyTe hybrydowe adresy często wymagają niezawodności, dlatego jeśli konsument zostanie odłączony, wiadomości wysyłane w tym czasie są przyjmowane po ponownym nawiązaniu połączenia przez konsumenta.
Hybrydowe modele nie są nowe i mogą być stosowane w większości systemów wymiany wiadomości, w tym w ActiveMQ (poprzez wirtualne lub złożone adresy, które łączą tematy i kolejki) oraz w Kafka (niejawnie, jako fundamentalna cecha projektowania jej adresatów).
Teraz, gdy mamy podstawową terminologię i zrozumienie tego, do czego może nam się przydać system wymiany wiadomości, przejdźmy do szczegółów.
Tłumaczenie wykonano:
Następna przetłumaczona część:
Ciąg dalszy nastąpi…
Źródło: habr.com
