Los patrones de diseño orientados a microservicios han hecho que nuestras aplicaciones sean más escalables que nunca. Los servidores API RESTful, el front-end e incluso las bases de datos ahora son horizontalmente escalables. La escala horizontal es el acto de agregar nuevos nodos a su clúster de aplicación para admitir una carga de trabajo adicional. Por el contrario, también permite reducir el consumo de recursos, cuando la carga de trabajo disminuye, para ahorrar costos. Los sistemas horizontalmente escalables deben ser distribuidos. Estos sistemas que pueden sobrevivir a la falla de múltiples máquinas virtuales, contenedores o enlaces de red y que aún se mantienen en línea y saludables para el usuario final.

Cuando hablamos de sistemas distribuidos como anteriormente, nos encontramos con el problema del análisis y el monitoreo. Cada nodo está generando mucha información sobre su propia salud (uso de CPU, memoria, etc.) y sobre el estado de la aplicación junto con lo que los usuarios están tratando de hacer. Estos detalles deben registrarse en:

1. El mismo orden en el que se crean,
2. Separado en términos de urgencia (análisis o lotes de datos en tiempo real), y lo más importante,
3. El mecanismo con el que se recolectan debe ser un distribuido y escalable, de lo contrario, nos queda un solo punto de falla. Algo que se suponía que el diseño del sistema distribuido debía evitar.

¿Por qué usar kafka??

Apache Kafka se lanza como una plataforma de transmisión distribuida. En Kafka Lingo, Productores Generar datos continuamente (corrientes) y Consumidores son responsables de procesarlo, almacenar y analizarlo. Kafka Corredores son responsables de garantizar que en un escenario distribuido los datos puedan llegar de productores a consumidores sin ninguna inconsistencia. Un conjunto de corredores de kafka y otro software llamado choque constituyen un despliegue típico de Kafka.

El flujo de datos de muchos productores debe agregarse, dividirse y enviarse a múltiples consumidores, hay muchos barajos involucrados. Evitar la inconsistencia no es una tarea fácil. Por eso necesitamos kafka.

Los escenarios en los que se puede usar kafka son bastante diversos. Cualquier cosa, desde dispositivos IoT hasta clúster de máquinas virtuales, hasta sus propios servidores locales de metal desnudo. En cualquier lugar donde muchas 'cosas' simultáneamente quieran su atención .. .Eso no es muy científico, ¿es todo?? Bueno, la arquitectura Kafka es un agujero de conejo propio y merece un tratamiento independiente. Primero veamos una implementación de nivel de superficie del software.

Usando Docker Compose

De cualquier forma imaginativa que decida usar kafka, una cosa es segura: no lo usará como una sola instancia. No está destinado a usarse de esa manera, e incluso si su aplicación distribuida necesita solo una instancia (corredor) por ahora, eventualmente crecerá y debe asegurarse de que Kafka pueda mantenerse al día.

Docker-composición es el socio perfecto para este tipo de escalabilidad. En su lugar, para ejecutar Kafka Brokers en diferentes máquinas virtuales, lo contiene y aprovechamos la composición de Docker para automatizar la implementación y la escala. Los contenedores Docker son altamente escalables tanto en los hosts de Docker individuales como en un clúster si usamos Docker Swarm o Kubernetes. Por lo tanto, tiene sentido aprovecharlo para que Kafka sea escalable.

Comencemos con una sola instancia de corredor. Cree un directorio llamado Apache-Kafka y dentro de él cree su Docker-Compose.YML.

$ mkdir apache-kafka
$ CD Apache-Kafka
$ Vim Docker-Compose.YML

Los siguientes contenidos se pondrán en su Docker-Compose.Archivo YML:

Versión: '3'
servicios:
Zookeeper:
Imagen: WurstMeister/Zookeeper
Kafka:
Imagen: Wurstmeister/Kafka
Puertos:
- "9092: 9092"
ambiente:
Kafka_advertised_host_name: localhost
KAFKA_ZOOKEEPER_CONNECT: ZOOKEEPER: 2181

Una vez que haya guardado los contenidos anteriores en su archivo de composición, desde el mismo directorio ejecutado:

$ Docker -Compose Up -d

Bien, ¿qué hicimos aquí??

Comprender el Docker-Compose.YML

Componer iniciará dos servicios como se enumeran en el archivo YML. Veamos el archivo un poco de cerca. La primera imagen es Zookeeper que Kafka requiere para realizar un seguimiento de varios corredores, la topología de la red y la sincronización de otra información. Dado que los servicios Zookeeper y Kafka serán parte de la misma red de puentes (esto se crea cuando ejecutamos Docker-Compose Up) No necesitamos exponer ningún puerto. Kafka Broker puede hablar con Zookeeper y eso es todo lo que necesita la Comunicación.

El segundo servicio es Kafka y solo estamos ejecutando una sola instancia, es decir, un corredor. Idealmente, desea usar múltiples corredores para aprovechar la arquitectura distribuida de Kafka. El servicio escucha en el puerto 9092 que se asigna al mismo número de puerto en el host de Docker y así es como el servicio se comunica con el mundo exterior.

El segundo servicio también tiene un par de variables de entorno. Primero, es kafka_advertised_host_name establecido en localhost. Esta es la dirección en la que se está ejecutando Kafka y donde los productores y los consumidores pueden encontrarla. Una vez más, este debería ser el conjunto en localhost, sino en la dirección IP o el nombre de host con esto, los servidores se pueden llegar en su red. El segundo es el nombre de host y el número de puerto de su servicio Zookeeper. Desde que llamamos el servicio Zookeeper ... bueno, Zookeeper, eso es lo que será el nombre de host, dentro de Docker Bridge Network que mencionamos.

Ejecutando un flujo de mensaje simple

Para que Kafka comience a trabajar, necesitamos crear un tema dentro de él. Los clientes productores pueden publicar flujos de datos (mensajes) a dicho tema y los consumidores pueden leer dicho DataStream, si se suscriben a ese tema en particular.

Para hacer esto, necesitamos comenzar una terminal interactiva con el contenedor Kafka. Enumere los contenedores para recuperar el nombre del contenedor de Kafka. Por ejemplo, en este caso nuestro contenedor se llama apache-kafka_kafka_1

$ Docker PS

Con el nombre de Kafka Container, ahora podemos caer dentro de este contenedor.

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

Abra dos terminales tan diferentes para usar uno como consumidor y otro productor.

Lado del productor

En una de las indicaciones (la que elige ser productor), ingrese los siguientes comandos:

## para crear un nuevo tema llamado Test
bash-4.4# kafka-topics.SH-CREATE-ZOOKEEPER ZOOKEEPER: 2181-Factor de replicación 1
--Partitions 1 -topic tope
## para iniciar un productor que publique DataStream desde la entrada estándar a Kafka
bash-4.4# kafka-commoducer.SH-Broker-List Localhost: 9092-Prueba de tope
>

El productor ahora está listo para tomar la entrada del teclado y publicarla.

Lado del consumidor

Muévase en el segundo terminal conectado a su contenedor Kafka. El siguiente comando inicia un consumidor que se alimenta del tema de la prueba:

$ kafka-consolse-consoly.sh --bootstrap-server localhost: 9092-prueba-tope

Volver al productor

Ahora puede escribir mensajes en el nuevo aviso y cada vez que presiona la devolución de devolución, la nueva línea se imprime en la solicitud del consumidor. Por ejemplo:

> Este es un mensaje.

Este mensaje se transmite al consumidor, a través de Kafka, y puede verlo impreso en el mensaje del consumidor.

Configuraciones del mundo real

Ahora tienes una imagen aproximada de cómo funciona la configuración de Kafka. Para su propio caso de uso, debe establecer un nombre de host que no sea localhost, necesita múltiples corredores de este tipo para ser parte de su clúster Kafka y finalmente debe configurar clientes de consumidores y productores.

Aquí hay algunos enlaces útiles:

1. Cliente de Python de Confluent
2. Documentación oficial
3. Una lista útil de demostraciones

Espero que te diviertas explorando Apache Kafka.