Apache Kafka 3.3 reemplaza a ZooKeeper con el nuevo protocolo KRaft

Tal vez lo más molesto de instalar y levantar kafka para un desarrollador, es instalar y levantar zookeeper. No porque sea difícil, sino que no se entiende mucho la utilidad en entornos de desarrollo. 

Apache Software Foundation ha lanzado Apache Kafka 3.3.1 con muchas funciones y mejoras nuevas. En particular, esta es la primera versión que marca el protocolo KRaft (Kafka Raft) como listo para la producción. 

KRaft es el protocolo de consenso desarrollado para permitir la gestión de metadatos directamente en Apache Kafka. Esto simplifica enormemente la arquitectura de Kafka al consolidar la responsabilidad de los metadatos en Kafka mismo sin el requisito de una herramienta de terceros como Apache ZooKeeper. Este nuevo modo KRaft mejora la escalabilidad y la resiliencia de la partición al tiempo que simplifica las implementaciones de Apache Kafka que ahora se pueden implementar de forma independiente.

Dejo link: https://www.mail-archive.com/announce@apache.org/msg07620.html

La gestión de la configuración en Microservicios parte 2

En el post anterior vimos como podemos mantener las configuraciones de nuestros microservicios y ahora veamos que productos hay en el mercado:

Etcd: Proyecto de código abierto escrito en Go. Se utiliza para el descubrimiento de servicios y la gestión de configuración. Utiliza el protocolo raft (https://raft.github.io/) para su modelo de computación distribuida. Como beneficios podemos nombrar: 

• Muy rápido y escalable
• Distribuible
• Impulsado por línea de comandos
• Fácil de usar y configurar

Eureka: Escrito por Netflix. Extremadamente probado en batalla. Se utiliza tanto para el descubrimiento de servicios como para la gestión de forma clave-valor. Como características podemos nombrar: 

• Almacén distribuido clave-valor.
• Flexible; requiere esfuerzo para configurar
• Ofrece actualización dinámica del cliente lista para usar

Cónsul: Escrito por Hashicorp. Similar a Etcd y Eureka en características, pero usa un algoritmo diferente para su modelo de computación distribuida (protocolo SWIM; https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf).

• Rápido
• Ofrece descubrimiento de servicios nativos con la opción de integrarse directamente con DNS
• No ofrece actualización dinámica para el cliente de inmediato.

ZooKeeper: un proyecto de Apache que ofrece capacidades de bloqueo distribuidas. A menudo se utiliza como una solución de gestión de la configuración para acceder a datos valor-clave.

• Las soluciones más antiguas y probadas en batalla
• El más complejo de usar
• Se puede utilizar para la gestión de la configuración, pero solo debe tenerse en cuenta si ya está utilizando ZooKeeper en otras piezas de su arquitectura.

Servidor de configuración de Spring Cloud: un proyecto de código abierto que ofrece una solución de administración de configuración general con diferentes backends. Puede integrarse con Git, Eureka y Consul como back-end.

• Almacén distribuido clave-valor no distribuido
• Ofrece una estrecha integración para los servicios Spring y no Spring 
• Puede usar múltiples backends para la creación de historias
• datos de configuración que incluyen sistema de archivos, Eureka, Consul y Git

El servidor de configuración Spring Cloud ofrece múltiples backends para almacenar datos de configuración. Si ya está utilizando herramientas como Eureka y Consul, puede conectarlas directamente al servidor de configuración de Spring Cloud.

De todas las soluciones, el servidor de configuración de Spring Cloud puede integrarse directamente con la plataforma de control de fuente Git. La integración de la configuración de Spring Cloud con Git elimina una dependencia adicional en sus soluciones y facilita el control de versiones de los datos de configuración de su aplicación.

Las otras herramientas (Etcd, Consul, Eureka) no ofrecen ningún tipo de control de versiones nativo y, si lo desea, debe crearlo usted mismo. Si su tienda usa Git, el uso del servidor de configuración Spring Cloud es una opción atractiva.

Instalar Kafka con docker

Vamos a instalar un Kafka broker con docker y con un solo nodo, la idea es tener un Kafka andando para hacer pruebas. 

Antes de empezar tenemos que instalar Zookeper, porque Kafka depende de este, pero lo que podemos hacer es un docker compose que instale todo y listo. 

version: '2'

services:

  zookeeper:

    image: confluentinc/cp-zookeeper:latest

    environment:

      ZOOKEEPER_CLIENT_PORT: 2181

      ZOOKEEPER_TICK_TIME: 2000

    ports:

      - 22181:2181

  

  kafka:

    image: confluentinc/cp-kafka:latest

    depends_on:

      - zookeeper

    ports:

      - 29092:29092

    environment:

      KAFKA_BROKER_ID: 1

      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181

      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092

      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT

      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT

      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

Como se puede ver tenemos 2 containers, uno para zookeper y otro para kafka. Lo que hacemos es un archivo docker-compose.yml, lo guardamos en un directorio y luego corremos el siguiente comando (en ese directorio) : 

docker-compose up -d

Ahora vemos si esto funciona con el comando grep en el log de kafka : 

docker-compose logs kafka | grep -i started

Si encontramos algunas lineas, estamos. 

Lo proximo a hacer es conectarnos con Kafka tool pero eso es una historia para otro post. 

Apache ZooKeeper

Ya hablamos de Apache ZooKeeper varias veces, pero de costado. Es decir hablando de otros productos relacionados con el mundo hadoop, y a la vez hablamos de él. Y por que tantas veces tuvimos que hablar de este producto? porque este producto, como lo indica su nombre, se encarga de cuidar las bestias que son todos los productos hadoop.

ZooKeeper tiene integración con todos los productos, dado que es es encargado de monitoriar su trabajo. ZooKeeper es un servicio centralizado para mantener la información de configuración, asignar nombres, proporcionar sincronización distribuida y proporcionar servicios de grupo. Todos estos tipos de servicios son utilizados de una forma u otra por las aplicaciones distribuidas. Cada vez que se implementan, hay un montón de trabajo que consiste en solucionar estos problemas. Debido a la dificultad de implementar este tipo de servicios, al principio las aplicaciones generalmente los escatiman, lo que los hace frágiles este tipo de aplicaciones frente al cambio y difíciles de administrar. Incluso cuando se realizan correctamente, las diferentes implementaciones de estos servicios conducen a la complejidad de la administración cuando se implementan las aplicaciones.

ZooKeeper apunta a destilar la esencia de estos diferentes servicios en una interfaz muy simple a un servicio de coordinación centralizado. El servicio en sí es distribuido y altamente confiable. El servicio implementará los protocolos de consenso, administración de grupos y presencia para que las aplicaciones no tengan que implementarlas por su cuenta. Los usos específicos de la aplicación consistirán en una mezcla de componentes específicos de ZooKeeper y las convenciones específicas de la aplicación. ZooKeeper Recipes muestra cómo este simple servicio se puede usar para construir abstracciones mucho más poderosas.

Espero que este post les abra el apetito del conocimiento dado que vamos a analizar más este producto. Dejo link: https://zookeeper.apache.org/

¿Como esta compuesto Apache HBase?

Bueno, Apache HBase esta compuesto por :

• ZooKeeper
• Hmaster
• RegionServer
• Client
• Catalog Table

Empecemos con ZooKeeper:
ZooKeeper es un sistema de coordinación para aplicaciones distribuidas. El cual provee una sincronización de recursos distribuidos y un grupo de servicios para HBase.

Esto permite centrarnos en la lógica del nuestro negocio y no en la coordinación de los clusters. Este tambien provee un conjunto de APIS que permiten entre otras cosas desarrollar tareas de coordinación.

En HBase, ZooKeeper es usado para elegir el master de un cluster para mantener que servidor esta disponible y meta-informcación del cluster.

ZooKeeper provee Apis para :

• Consistencia, orden y durabilidad
• Sincronización
• Concurrencia para clusters distribuidos. 

Zookeeper fue desarrollado por yahoo research y su nombre esta relacionado con que se encuadra en el marco del proyecto Hadoop, el cual sus subproyectos son todos animales. Es decir ZooKeeper es el encargado de cuidar estos animales.
ZooKeeper no solo simplifica el desarrollo sino que también es una capa de abstracción que facilita la mejor accesibilidad a los componentes del sistema.
ZooKeeper mantiene un árbol con datos llamados internamente znode. Esto puede ser de dos tipos:

• Efímero, que es bueno para las aplicaciones que necesitan entender si un recurso distribuido específico está disponible o no.
• El persistente se almacenará hasta que un cliente no lo elimine explícitamente y también almacene algunos datos de la aplicación.

ZooKeepers se basan en un principio de mayoría (quorum); requiere que tengamos un quórum de servidores para estar activo, donde el quórum es  (n / 2) + 1, para un conjunto de tres nodos significa que dos nodos deben estar funcionando en cualquier momento, y para un conjunto de cinco nodos, un mínimo de tres nodos debe estar arriba. También es importante para la elección del maestro ZooKeeper.