Alexandre Vazquez

Apache Kafka parece ser la solución estándar en la arquitectura actual, pero deberíamos centrarnos en si es la elección correcta para nuestras necesidades.

Hoy en día, estamos en una nueva era de Arquitectura Orientada a Eventos, y esta no es la primera vez que vivimos eso. Antes de los microservicios y la nube, EDA era la nueva normalidad en la integración empresarial. Basado en diferentes tipos de estándares, había protocolos como JMS o AMQP utilizados en productos basados en brokers como TIBCO EMS, Active MQ o IBM Websphere MQ, por lo que este enfoque no es algo nuevo.

Con el auge de las arquitecturas de microservicios y el enfoque liderado por API, parecía que habíamos olvidado la importancia de los sistemas de mensajería, y tuvimos que pasar por los mismos desafíos que vimos en el pasado para llegar a una nueva solución de mensajería para resolver ese problema. Así que estamos volviendo a la Arquitectura EDA, mecanismo pub-sub, para ayudarnos a desacoplar los consumidores y productores, moviéndonos de la orquestación a la coreografía, y todos estos conceptos encajan mejor en los mundos actuales con componentes cada vez más independientes que necesitan cooperación e integración.

Durante este esfuerzo, comenzamos a mirar nuevas tecnologías para ayudarnos a implementar eso nuevamente. Sin embargo, con la nueva realidad, olvidamos los protocolos y estándares pesados como JMS y comenzamos a pensar en otras opciones. Y debemos admitir que sentimos que hay un nuevo rey en esta área, y este es uno de los componentes críticos que parece ser, sin importar qué, en la arquitectura de hoy: Apache Kafka.

Y no me malinterpretes. Apache Kafka es fantástico, y ha sido probado durante mucho tiempo, una solución lista para producción, de alto rendimiento, con capacidades impresionantes para la reproducción y una API poderosa para facilitar la integración. Apache Kafka tiene algunos desafíos en este mundo nativo de la nube porque no se lleva tan bien con algunas de sus reglas.

Si has usado Apache Kafka durante algún tiempo, eres consciente de que hay desafíos particulares con él. Apache Kafka tiene una arquitectura que proviene de sus días en LinkedIn en 2011, donde Kubernetes o incluso Docker y las tecnologías de contenedores no eran una cosa, lo que hace que ejecutar Apache Kafka (servicio puramente con estado) de manera contenedorizada sea bastante complicado. Hay mejoras usando gráficos de helm y operadores para facilitar el viaje, pero aún así, no se siente como si las piezas pudieran integrarse bien de esa manera. Otra cosa es la geo-replicación que incluso con componentes como MirrorMaker, no es algo que se use, funcione sin problemas y se sienta integrado.

Otras tecnologías están tratando de proporcionar una solución para esas capacidades, y una de ellas es también otro proyecto de la Fundación Apache que ha sido donado por Yahoo! y se llama Apache Pulsar.

No me malinterpretes; esto no se trata de encontrar una nueva verdad, esa única solución de mensajería que es perfecta para las arquitecturas de hoy: no existe. En el mundo actual, con tantos requisitos y variables diferentes para los diferentes tipos de aplicaciones, una talla única ya no es cierta. Así que deberías dejar de pensar en cuál solución de mensajería es la mejor, y pensar más en cuál sirve mejor a tu arquitectura y cumple con los requisitos tanto técnicos como comerciales.

Hemos cubierto diferentes formas de comunicación general, con varias soluciones específicas para la comunicación sincrónica (tecnologías de malla de servicios y protocolos como REST, GraphQL o gRPC) y diferentes para la comunicación asincrónica. Necesitamos profundizar en la comunicación asincrónica para encontrar lo que funciona mejor para ti. Pero primero, hablemos un poco más sobre Apache Pulsar.

Apache Pulsar

Apache Pulsar, como se mencionó anteriormente, ha sido desarrollado internamente por Yahoo! y donado a la Fundación Apache. Como se indica en su sitio web oficial, hay varios puntos clave a mencionar al comenzar a explorar esta opción:

• Funciones de Pulsar: Despliega fácilmente lógica de cómputo ligera usando APIs amigables para desarrolladores sin necesidad de ejecutar tu motor de procesamiento de flujos
• Probado en producción: Apache Pulsar ha funcionado en producción a escala Yahoo durante más de tres años, con millones de mensajes por segundo a través de millones de temas
• Escalabilidad horizontal: Expande la capacidad sin problemas a cientos de nodos
• Baja latencia con durabilidad: Diseñado para baja latencia de publicación (< 5ms) a escala con fuertes garantías de durabilidad
• Geo-replicación: Diseñado para replicación configurable entre centros de datos en múltiples regiones geográficas
• Multi-tenencia: Construido desde cero como un sistema multi-tenant. Soporta Aislamiento, Autenticación, Autorización y Cuotas
• Almacenamiento persistente: Almacenamiento persistente de mensajes basado en Apache BookKeeper. Proporciona aislamiento a nivel de IO entre operaciones de escritura y lectura
• Bibliotecas de clientes: Modelos de mensajería flexibles con APIs de alto nivel para Java, C++, Python y GO
• Operabilidad: API de administración REST para aprovisionamiento, administración, herramientas y monitoreo. Despliega en metal desnudo o Kubernetes.

Como podemos ver, en su diseño, Apache Pulsar está abordando algunas de las principales debilidades de Apache Kafka como la Geo-replicación y su enfoque nativo de la nube.

Apache Pulsar proporciona soporte para el patrón pub/sub, pero también ofrece muchas capacidades que también lo colocan como un sistema de mensajería de cola tradicional con su concepto de temas exclusivos donde solo uno de los suscriptores recibirá el mensaje. También proporciona conceptos y características interesantes utilizados en otros sistemas de mensajería:

• Temas de Carta Muerta: Para mensajes que no pudieron ser procesados por el consumidor.
• Temas Persistentes y No Persistentes: Para decidir si deseas persistir tus mensajes o no durante la transición.
• Espacios de Nombres: Para tener una distribución lógica de tus temas, de modo que una aplicación pueda agruparse en espacios de nombres como lo hacemos, por ejemplo, en Kubernetes para poder aislar algunas aplicaciones de las otras.
• Failover: Similar a exclusivo, pero cuando el consumidor adjunto falla al procesar, otro toma la oportunidad de procesar los mensajes.
• Compartido: Para poder proporcionar un enfoque de round-robin similar al sistema de mensajería de cola tradicional donde todos los suscriptores estarán adjuntos al tema, pero solo uno recibirá el mensaje, y distribuirá la carga entre todos ellos.
• Suscripciones Multi-tema: Para poder suscribirse a varios temas usando una expresión regular (similar al enfoque de Subject de TIBCO Rendezvous, por ejemplo, en los años 90) que ha sido tan poderoso y popular.

Pero también, si requieres características de Apache Kafka, aún tendrás conceptos similares como temas particionados, temas compartidos por clave, y así sucesivamente. Así que tienes todo a tu disposición para elegir qué tipo de configuración funciona mejor para ti y tus casos de uso específicos, también tienes la opción de mezclar y combinar.

Arquitectura de Apache Pulsar

La Arquitectura de Apache Pulsar es similar a otros sistemas de mensajería comparables hoy en día. Como puedes ver en la imagen a continuación del sitio web de Apache Pulsar, estos son los componentes principales de la arquitectura:

• Brokers: Uno o más brokers manejan mensajes entrantes de productores, despachan mensajes a consumidores
• Cluster de BookKeeper para almacenamiento persistente de gestión de mensajes
• Cluster de ZooKeeper para propósitos de gestión.

Así que puedes ver que esta arquitectura también es bastante similar a la de Apache Kafka nuevamente con la adición de un nuevo concepto del Cluster de BookKeeper.

El Broker en Apache Pulsar son componentes sin estado que principalmente ejecutarán dos piezas

• Servidor HTTP que expone una API REST para gestión y es utilizado por consumidores y productores para búsqueda de temas.
• Servidor TCP usando un protocolo binario llamado dispatcher que se utiliza para todas las transferencias de datos. Por lo general, los mensajes se despachan desde un caché de libro mayor gestionado por razones de rendimiento. Pero también si este caché crece demasiado, interactuará con el cluster de BookKeeper por razones de persistencia.

Para soportar la Replicación Global (Geo-Replicación), los Brokers gestionan replicadores que siguen las entradas publicadas en la región local y las republican en las regiones remotas.

El Cluster de Apache BookKeeper se utiliza como almacenamiento persistente de mensajes. Apache BookKeeper es un sistema de registro de escritura anticipada (WAL) distribuido que gestiona cuándo los mensajes deben ser persistidos. También soporta escalado horizontal basado en la carga y soporte multi-log. No solo los mensajes son persistentes sino también los cursores que son la posición del consumidor para un tema específico (similar al offset en la terminología de Apache Kafka)

Finalmente, el Cluster de Zookeeper se utiliza en el mismo rol que Apache Kafka como un cluster de almacenamiento de configuración de metadatos para todo el sistema.

Hola Mundo usando Apache Pulsar

Veamos cómo podemos crear un caso rápido de «Hola Mundo» usando Apache Pulsar como protocolo, y para hacer eso, vamos a intentar implementarlo de manera nativa en la nube. Así que haremos un cluster de un solo nodo de Apache Pulsar en una instalación de Kubernetes y desplegaremos una aplicación productora usando la tecnología Flogo y una aplicación consumidora usando Go. Algo similar a lo que puedes ver en el diagrama a continuación:

Y vamos a intentar mantenerlo simple, así que solo usaremos docker puro esta vez. Así que, primero que nada, solo inicia el servidor de Apache Pulsar y para hacer eso usaremos el siguiente comando:

docker run -it -p 6650:6650 -p 8080:8080 --mount source=pulsardata,target=/pulsar/data --mount source=pulsarconf,target=/pulsar/conf apachepulsar/pulsar:2.5.1   bin/pulsar standalone

Y veremos una salida similar a esta:

Ahora, necesitamos crear aplicaciones simples, y para eso, se utilizarán Flogo y Go.

Comencemos con el productor, y en este caso, usaremos la versión de código abierto para crear una aplicación rápida.

Primero que nada, solo usaremos la interfaz web (dockerizada) para hacer eso. Ejecuta el comando:

docker run -it -p 3303:3303 flogo/flogo-docker eula-accept

E instalamos una nueva contribución para habilitar la actividad del publicador de Pulsar. Para hacer eso, haremos clic en el botón «Instalar nueva contribución» y proporcionaremos la siguiente URL:

flogo install github.com/mmussett/flogo-components/activity/pulsar

Y ahora crearemos un flujo simple como puedes ver en la imagen a continuación:

Ahora construiremos la aplicación usando el menú, ¡y eso es todo!

Para poder ejecutar, solo lanza la aplicación como puedes ver aquí:

./sample-app_linux_amd64

Ahora, solo necesitamos crear el consumidor en Go-lang para poder hacer eso necesitamos instalar el paquete golang:

go get github.com/apache/pulsar-client-go/pulsar

Y ahora necesitamos crear el siguiente código:

package main
import (
 “fmt”
 “log”
 “github.com/apache/pulsar-client-go/pulsar”
)
func main() {
 client, err := pulsar.NewClient(pulsar.ClientOptions{URL: “pulsar://localhost:6650”})
 if err != nil {
 log.Fatal(err)
 }
defer client.Close()
channel := make(chan pulsar.ConsumerMessage, 100)
options := pulsar.ConsumerOptions{
 Topic: “counter”,
 SubscriptionName: “my-subscription”,
 Type: pulsar.Shared,
 }
options.MessageChannel = channel
consumer, err := client.Subscribe(options)
 if err != nil {
 log.Fatal(err)
 }
defer consumer.Close()

// Recibe mensajes del canal. El canal devuelve una estructura que contiene el mensaje y el consumidor de donde
 // se recibió el mensaje. No es necesario aquí ya que tenemos un solo consumidor, pero el canal podría ser
 // compartido entre múltiples consumidores también
 for cm := range channel {
 msg := cm.Message
 fmt.Printf(“Mensaje recibido msgId: %v — contenido: ‘%s’n”,
 msg.ID(), string(msg.Payload()))
consumer.Ack(msg)
}
}

Y después de ejecutar ambos programas, puedes ver la siguiente salida como puedes ver, pudimos comunicar ambas aplicaciones en un flujo sin esfuerzo.

Este artículo es solo un punto de partida, y continuaremos hablando sobre cómo usar Apache Pulsar en tus arquitecturas. Si deseas echar un vistazo al código que hemos utilizado en este ejemplo, puedes encontrarlo aquí: