Wzory projektowania zorientowane na mikrousługę sprawiły, że nasze aplikacje są bardziej skalowalne niż kiedykolwiek. RESTful API, front-end, a nawet bazy danych są teraz skalowalne poziomo. Skalowanie poziome to akt dodania nowych węzłów do klastra aplikacji w celu obsługi dodatkowego obciążenia pracą. I odwrotnie, umożliwia również zmniejszenie zużycia zasobów, gdy obciążenie zmniejsza się, aby zaoszczędzić koszty. Systemy skalowalne poziome muszą być systemem rozproszonym. Te systemy, które mogą przetrwać awarię wielu maszyn wirtualnych, kontenerów lub linków sieciowych i nadal pozostać online i zdrowe dla użytkownika końcowego.

Mówiąc o systemach rozproszonych, takich jak powyżej, napotykamy problem analizy i monitorowania. Każdy węzeł generuje wiele informacji na temat własnego zdrowia (użycie procesora, pamięć itp.) I status aplikacji, a także to, co użytkownicy próbują zrobić. Te szczegóły muszą być zapisane w:

1. Ta sama kolejność, w której są tworzone,
2. Oddzielony pod względem pilności (analizy lub partii danych), a co najważniejsze,
3. Mechanizm, z którym są gromadzone, musi być rozproszony i skalowalny, w przeciwnym razie pozostało nam jeden punkt awarii. Czegoś, czego powinien uniknąć projektowania systemu rozproszonego.

Dlaczego warto korzystać z Kafki?

Apache Kafka jest rozsiany jako rozproszona platforma przesyłania strumieniowego. W Kafka Lingo, Producenci Ciągle generuj dane (strumienie) I Konsumenci są odpowiedzialne za przetwarzanie, przechowywanie i analizę. Kafka Brokerzy są odpowiedzialne za zapewnienie, że w scenariuszu rozproszonym dane mogą dotrzeć do producentów do konsumentów bez żadnej niespójności. Zestaw brokerów Kafka i kolejny oprogramowanie o nazwie Zookeeper stanowią typowe wdrożenie kafki.

Strumień danych wielu producentów musi zostać agregowany, podzielony i wysyłany do wielu konsumentów, w grę wchodzi wiele tasowania. Unikanie niespójności nie jest łatwym zadaniem. Dlatego potrzebujemy kafki.

Scenariusze, w których można używać Kafki, jest dość zróżnicowany. Wszystko, od urządzeń IoT po klaster maszyn wirtualnych po własne lokalne serwery metalowe. Gdziekolwiek wiele „rzeczy” jednocześnie chce twojej uwagi… .To nie jest zbyt naukowe, prawda?? Cóż, architektura Kafka jest własną dziurą i zasługuje na niezależne leczenie. Najpierw zobaczmy wdrożenie oprogramowania bardzo powierzchniowego.

Korzystanie z Docker Compose

W jakikolwiek pomysłowy sposób, w jaki zdecydujesz się użyć Kafki, jedno jest pewne - nie będziesz go używać jako pojedynczego instancji. Nie ma być używany w ten sposób, a nawet jeśli Twoja rozproszona aplikacja potrzebuje na razie tylko jednej instancji (broker), w końcu będzie rosła i musisz upewnić się, że Kafka może nadążyć.

Docker-Compose jest idealnym partnerem dla tego rodzaju skalowalności. Zamiast tego do uruchamiania brokerów Kafka na różnych maszynach wirtualnych, konteneryzujemy go i wykorzystujemy Docker komponuj do automatyzacji wdrażania i skalowania. Kontenery Docker są wysoce skalowalne zarówno na hostach pojedynczych Docker, jak i w klastrze, jeśli używamy Docker Swarm lub Kubernetes. Więc sensowne jest wykorzystanie go, aby kafka jest skalowalna.

Zacznijmy od pojedynczego instancji brokera. Utwórz katalog o nazwie Apache-kafka, a w środku Utwórz kompozycję dokera.yml.

$ mkdir apache-kafka
$ CD Apache-Kafka
$ vim Docker-Compose.yml

Poniższe treści zostaną umieszczone w Twoim kompozycie dokera.plik YML:

Wersja: „3”
Usługi:
Zookeeper:
Zdjęcie: Wurstmeister/Zookeeper
Kafka:
Zdjęcie: Wurstmeister/Kafka
Porty:
- „9092: 9092”
środowisko:
Kafka_adverted_host_name: localhost
Kafka_zookeeper_connect: Zookeeper: 2181

Po zapisaniu powyższej zawartości w pliku kompozycji, z tego samego uruchomienia katalogu:

$ Docker -Compose Up -d

Okej, więc co tu zrobiliśmy?

Zrozumienie kompozycji dokera.yml

Komponowanie rozpocznie dwie usługi wymienione w pliku YML. Spójrzmy trochę na plik uważnie. Pierwszym obrazem jest Zookeeper, którego Kafka potrzebuje do śledzenia różnych brokerów, topologii sieci, a także synchronizacji innych informacji. Ponieważ zarówno usługi Zookeeper, jak i Kafka będą częścią tej samej sieci mostów (jest to tworzone podczas uruchamiania kompozycji Docker), nie musimy wystawiać żadnych portów. Broker Kafka może porozmawiać z Zookeeper i taka jest cała komunikacja potrzebuje Zookeeper.

Druga usługa to sama Kafka, a my po prostu uruchamiamy jej instancję, to znaczy jednego brokera. Idealnie byłoby użyć wielu brokerów, aby wykorzystać rozproszoną architekturę Kafki. Usługa słucha w porcie 9092, który jest odwzorowany na ten sam numer portu na hostie Docker i tak komunikuje się usługi ze światem zewnętrznym.

Druga usługa ma również kilka zmiennych środowiskowych. Po pierwsze, jest kafka_adverted_host_name ustawiony na localhost. Jest to adres, pod którym działa Kafka i gdzie mogą go znaleźć producenci i konsumenci. Po raz kolejny powinien to być zestaw do lokalizacji, ale raczej na adres IP lub nazwa hosta z tym serwerami można osiągnąć w sieci. Drugi to nazwa hosta i numer portu Twojej usługi Zookeeper. Ponieważ nazwaliśmy usługę Zookeeper… cóż, Zookeeper, taka będzie nazwa hosta, w Docker Bridge Network, o której wspominaliśmy.

Uruchamianie prostego przepływu wiadomości

Aby Kafka zaczęła działać, musimy utworzyć w nim temat. Klienci producenci mogą następnie publikować strumienie danych (wiadomości) na wspomniany temat, a konsumenci mogą odczytać wspomniany DataStream, jeśli są oni subskrybowane z tym konkretnym tematem.

Aby to zrobić, musimy założyć interaktywny terminal z pojemnikiem Kafka. Wymień pojemniki, aby odzyskać nazwę kontenera Kafka. Na przykład w tym przypadku nasz kontener nazywa się Apache-kafka_kafka_1

$ Docker Ps

Z nazwą Kafka Container możemy teraz wpuścić do tego pojemnika.

$ Docker Exec -it Apache -kafka_kafka_1 bash
Bash-4.4#

Otwórz dwa takie różne terminale, aby używać jednego jako konsumenta i innego producenta.

Strona producenta

W jednej z podpowiedzi (ten, który wybierzesz producent), wprowadź następujące polecenia:

## Aby utworzyć nowy temat o nazwie Test
Bash-4.4# Kafka-Topics.SH-Create --zookeeper Zookeeper: 2181-Factor Replication 1
--partycje 1 -Test topowy
## Aby założyć producenta, który publikuje DataSastream od standardowego wejścia do Kafki
Bash-4.4# Kafka-Console-Producer.SH-Broker-List LocalHost: 9092-Test topowy
>

Producent jest teraz gotowy do przejęcia danych z klawiatury i opublikowania go.

Strona konsumenta

Przejdź na drugi terminal podłączony do pojemnika Kafka. Poniższe polecenie rozpoczyna konsument, który zasila temat testowy:

$ Kafka-Console-Consumer.sh-bootstrap-server localhost: 9092-Test topowy

Powrót do producenta

Możesz teraz wpisać wiadomości w nowej monitu i za każdym razem, gdy naciśnię, Nowa linia jest wydrukowana w wierszu konsumenta. Na przykład:

> To jest wiadomość.

Ta wiadomość zostaje przekazywana konsumentowi za pośrednictwem Kafki, i możesz zobaczyć ją wydrukowaną na podpowiedzi konsumenckiej.

Realne konfiguracje

Masz teraz szorstkie zdjęcie, jak działa konfiguracja Kafki. W przypadku własnego przypadku użycia musisz ustawić nazwę hosta, która nie jest hostem lokalnym, potrzebujesz wielu takich brokerów, aby byli częścią klastra Kafka, a na koniec musisz skonfigurować klientów konsumentów i producentów.

Oto kilka przydatnych linków:

1. Klient Python Confluent
2. Oficjalna dokumentacja
3. Przydatna lista dema

Mam nadzieję, że dobrze się bawisz, odkrywając Apache Kafka.