SISTEMAS DISTRIBUIDOS PROYECTO

TIPOS DE MEPS, CALLBACK.

ARQUITECTURA DE COMPONENTES, TECNOLOGíAS DE IMPLEMENTACION.

Tipos de MEPs

TIPOS DE MEPS

Los patrones de intercambio de mensajes (MEP) describen cómo los sistemas pueden intercomunicarse utilizando mecanismos entendidos por unanimidad. A menos que se especifique lo contrario, los MEPs describen patrones lógicos en lugar de estrictos físicos:

MEPs Lógicos

Establecen cómo se intercambian los datos a nivel conceptual / caso de uso.

MEPs Físicos

Establecen cómo los sistemas informáticos intercambian físicamente los datos. Dentro de la capa física, la distinción también varía según la capa elegida.

TIPOS DE MEPS

Este es un resumen de los patrones más comunes:

Request/Call-back

El patrón de intercambio de mensajes de solicitud / devolución de llamada (MEP) es aquel en el que el consumidor registra una función de devolución de llamada con el proveedor. El proveedor utiliza normalmente dicha función para notificar al consumidor cuando se completa la solicitud; sin embargo, también puede llevar datos adicionales.

Request/Call-back

Este patrón es una forma de MEP bidireccional unidireccional o solicitud / respuesta asincrónica. Lo que lo hace especial es que el punto final y / o la función que utilizará el proveedor se definen de manera ad-hoc en tiempo de ejecución en lugar de definirse de antemano.

Ejemplo de Pseudocòdigo:

define myFunction

print "The food is ready"

end define

provider.cookFood(myFunction)

PROTOCOLO DE COMUNICACIÓN.

Un protocolo de comunicaciones es el conjunto de reglas y estándares que tienen como fin controlar las secuencias de los mensajes que suceden durante la comunicación entre las entidades que forman parte de una misma red.

ZEROMQ

es un broker de mensajería asíncrona de alto rendimiento, Su forma de transmisión implementa colas de mensajes. ZeroMQ ofrece una biblioteca central que funciona muy bien debido a su modelo de subprocesamiento interno, y puede superar las aplicaciones TCP convencionales en términos de rendimiento mediante el uso de una técnica de procesamiento automático de mensajes.

RABBITMQ

es un broker de mensajería que implementa colas de mensajería que se comunican entre ellas para la transmisión de mensajes. Es liviano y fácil de implementar. Es compatible con múltiples protocolos de mensajería y se implementa en configuraciones distribuidas para cumplir con los requisitos de alta disponibilidad y alta escala. RabbitMQ se ejecuta en muchos sistemas operativos y proporciona una amplia gama de herramientas de desarrollo para la mayoría de lenguajes. Dentro de sus características se encuentra la

17 mensajería asincrónica, que se refiere a que admite múltiples protocolos de mensajería, colas de mensajes, acuse de recibo, enrutamiento flexible para colas y tipo de intercambio múltiple.

KAFKA

es un broker de mensajería que proporciona una plataforma unificada, de alto rendimiento y de baja latencia para la manipulación en tiempo real de datos. Puede verse como una cola de mensajes, bajo el patrón publicación-suscripción, masivamente escalable concebida como un registro de transacciones distribuidas. Kafka generalmente se usa para dos clases de aplicaciones: 1. Canales de transmisión de datos en tiempo real entre sistemas o aplicaciones, que ofrecen una entrega de paquetes confiable. 2. Aplicaciones de transmisión en tiempo real que responden a flujos de datos.

OPENMQ

es un proyecto de middleware orientado a mensajes de código abierto de Oracle que implementa Java Message Service 2.0 API.

OpenMQ proporciona funciones empresariales adicionales que incluyen la agrupación en clúster para la escalabilidad y la alta disponibilidad.

ACTIVEMQ

Apache ActiveMQ es el servidor de mensajes de fuente abierta y de patrones de integración popular y potente, es rápido, compatible con muchos clientes y protocolos de idiomas cruzados, utiliza patrones de integración empresarial fáciles de emplear y muchas características avanzadas. Es compatible con JMS 1.1 y J2EE 1.4. y trabaja bajo la licencia de Apache 2.0.

Broker

Un bróker de mensajería es un patrón arquitectónico para la validación, la transformación y el ruteo de mensajes. El propósito del bróker es recibir los mensajes entrantes desde las aplicaciones y llevar a cabo determinadas acciones con ellas.

Ejemplo

Qué es RabbitMQ?

RabbitMQ es un broker de mensajería de código abierto, distribuido y escalable, que sirve como intermediario para la comunicación eficiente entre productores y consumidores.

Componentes de un broker

Un Topic es una categoría o un nombre donde publicar los mensajes. Cada Topic los mantiene en un log particionado, cuya representación es la siguiente:

Particion

Cada partición es una secuencia de mensajes inalterable, donde los mensajes son añadidos a una de las particiones según van llegando, y se les va asignando un número secuencial, llamado offset, que identifica de forma única a cada mensaje dentro de su partición.

Productores

Responsables de publicar mensajes a uno o varios Topics. Un mensaje es enviado cada vez a una de las particiones del Topic en round-robin o siguiendo un criterio definido, como puede ser por algún tipo de algoritmo basado en una clave del mensaje.

Consumidores

Kafka proporciona un único nivel de abstración donde recoge el modelo de mensajería de queuing (colas) y publish-subscribe (editor-subscriptor). Este nivel de abstracción es llamado consumer group o grupo consumidor.

Zookeeper

ZooKeeper, es un servicio para coordinar procesos de aplicaciones distribuidas. Históricamente, los procesos distribuidos se coordinan mediante mensajes grupales, registros compartidos o servicios de bloqueo distribuido. ZooKeeper incorpora elementos de todos estos servidores, pero los incorpora en un servicio centralizado. Con ZooKeeper, las aplicaciones manipulan nodos para coordinar las acciones de sus procesos de manera similar a como se manipulan los archivos y directorios en un sistema de archivos. En tales nodos, las aplicaciones de usuario almacenan datos directamente en nodos, o simplemente usan nombres de nodos para indicar algún evento de la aplicación.

CLUSTER

El término clúster se aplica a los conjuntos o conglomerados de computadoras construidos mediante la utilización de hardwares comunes y que se comportan como si fuesen una única computadora.

Simplemente, un clúster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad, de tal forma que el conjunto es visto como un único ordenador, más potente que los comunes de escritorio. Los clústeres son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por encima de la que es provista por un solo computador típicamente siendo más económico que computadores individuales de rapidez y disponibilidad comparables.

CLUSTER

TIPOS DE CLUSTER

CLUSTERS DE ALTO RENDIMIENTO (HPCC - High Performance Computing Clusters):

Son clústeres en los cuales se ejecutan tareas que requieren de gran capacidad computacional, grandes cantidades de memoria, o ambos a la vez. El llevar a cabo estas tareas puede comprometer los recursos del clúster por largos periodos de tiempo.

CLUSTERS DE ALTA DISPONIBILIDAD (HA o HACC - High Availability Computing Clusters):

Son clústeres cuyo objetivo de diseño es el de proveer disponibilidad y confiabilidad. Estos clústeres tratan de brindar la máxima disponibilidad de los servicios que ofrecen. La confiabilidad se provee mediante software que detecta fallos y permite recuperarse frente a los mismos, mientras que en hardware se evita tener un único punto de fallos.

CLUSTERS DE ALTA EFICIENCIA (HT o HTCC - High Throughput Computing Clusters):

Son clústeres cuyo objetivo de diseño es el ejecutar la mayor cantidad de tareas en el menor tiempo posible. Existe independencia de datos entre las tareas individuales. El retardo entre los nodos del clúster no es considerado un gran problema.

¿Por qué es necesario Zookeeper para Apache Kafka?

• Elección de controlador

El controlador es una de las entidades de corretaje más importantes en un ecosistema de Kafka, y también tiene la responsabilidad de mantener la relación líder-seguidor en todas las particiones. Si un nodo por alguna razón se está cerrando, es responsabilidad del controlador decirles a todas las réplicas que actúen como líderes de partición para cumplir con los deberes de los líderes de partición en el nodo que está a punto de fallar.

¿Por qué es necesario Zookeeper para Apache Kafka?

• Configuración de temas

La configuración con respecto a todos los temas, incluida la lista de temas existentes, el número de particiones para cada tema, la ubicación de todas las réplicas, la lista de anulaciones de configuración para todos los temas y qué nodo es el líder preferido, etc.

• Listas de control de acceso

Las listas de control de acceso para todos los temas también se mantienen dentro de Zookeeper.

¿Por qué es necesario Zookeeper para Apache Kafka?

• Membresía del grupo

Zookeeper también mantiene una lista de todos los corredores que están funcionando en un momento dado y son parte del clúster.

Tenga en cuenta que no puede ejecutar los servicios de Kafka sin instalar primero Zookeeper. Sin embargo, Zookeeper ya está instalado y configurado para su clúster CloudKarafka.

Single node, single bróker

Kafka proporciona el valor predeterminado y un simple archivo de configuración de ZooKeeper que se utiliza para lanzar una sola instancia local de ZooKeeper, aunque también se puede realizar una instalación separada de ZooKeeper al configurar el clúster de Kafka.

Single node, single bróker

Nodo único - Broker múltiple

Para configurar múltiples intermediarios en un solo nodo, se requieren diferentes archivos de propiedades del servidor para cada intermediario. Cada archivo de propiedades definirá valores únicos y diferentes para las siguientes propiedades:

Nodo único - Broker múltiple

Nodo único - Broker múltiple

Múltiples nodos: múltiples grupos de intermediarios

El clúster Kafka de intermediario múltiple, donde configuramos varios intermediarios en cada nodo, debemos instalar Kafka en cada nodo del clúster y todos los corredores de los diferentes nodos deben conectarse al mismo ZooKeeper.

Para fines de prueba, todos los comandos seguirán siendo idénticos a los que usamos en el nodo único: clúster de varios corredores.

Múltiples nodos: múltiples grupos de intermediarios

Streaming Processing

Antes del procesamiento de flujo: una infraestructura de datos en reposo

Es el procesamiento de datos en movimiento , o en otras palabras, el cálculo de datos directamente a medida que se producen o reciben.

Una infraestructura de procesamiento de flujo

Procesamiento de flujo con estado

Amazon Web Services (AWS) proporciona varias opciones de trabajo con los datos de streaming. Puede utilizar los servicios de datos de streaming gestionados de Amazon Kinesis

• Apache Kafka

• Apache Flume

• Apache Spark Streaming

• Apache Storm

Arquitectura de Kafka

Streaming Processing en Apache Kafka

Arquitectura de conexión de Apache Kafka

Streaming Processing en Apache Kafka

RABBITMQ

Las colas de mensajes (MQ) solucionan estas necesidades, actuando de intermediario entre emisores y destinatarios, o en un contexto más definido, productores y consumidores de mensajes. Se pueden usar para reducir las cargas y los tiempos de entrega por parte de los servidores de aplicaciones web, ya que las tareas, que normalmente tardarían bastante tiempo en procesarse, se pueden delegar a un tercero cuyo único trabajo es realizarlas.

COLAS DE TRABAJO

Implementacion colas de trabajo

Implementacion del patron publicar/suscribir

Implementacion

publicar/suscribir

- Este patron envia mensaje a muchos consumidores a la vez.

- Archivos javascrip:

--Programa productor emit_log.js

--Programa consumidor receive_logs.js