Azure Service Bus

Los sistemas distribuidos[1] siguen ganando en popularidad debido a la necesidad de compartir información entre sistemas de una manera distribuida y independiente. Cuando se intenta compartir datos entre aplicaciones o sistemas distribuidos, no es una tarea fácil debido a los retos que plantea como el de asegurar la escalabilidad, mínima latencia, consistencia y fiabilidad en las transacciones de datos o al de cómo esa información debe ser compartida.

¿Qué es Azure Service Bus?

Azure Service Bus es un cloud service[2] el cual facilita la integración de un servicio para el intercambio de mensajes entre sistemas independientes de una forma desacoplada. Este servicio es una de las muchas “Platform as a Service” PaaS[3] que Azure ofrece, y permite diseñar desde escenarios simples como una simple cola de mensajes, a escenarios que requieren flujos de intercambio de datos mucho más complejos.

Características

Para crear un service bus se debe definir primero un espacio de nombres en el cual se implementa qué tipo de mecanismo de comunicación usarán las aplicaciones que consuman el service bus.

Hay cuatro tipos de conexión:

  • Queues: proveen comunicación en una única dirección. Estas colas actúan de intermediario guardando los mensajes en cola hasta que son recibidos por el sistema receptor, con lo que es usado en escenarios N a 1.
  • Topics: proveen comunicación en una única dirección. Los Topics son un tipo de colas las cuales los sistemas receptores deben estar suscritos. A su vez, cada Topic permite tener múltiples suscriptores conformando un sistema N a N. Además, cada suscriptor puede definir un filtro para poder recibir sólo los mensajes que cumplen con los criterios especificados.
  • Relays: provee una comunicación bidireccional. A diferencia de los dos casos anteriores, éste no usa colas para guardar los mensajes sino que los envía directamente a la aplicación destino conformando un sistema 1 a 1.
  • Event Hubs: este sistema de comunicación sería similar a las Queues y Topics pero con la característica de soportar grandes flujos de eventos de entrada, manteniendo una baja latencia y una alta fiabilidad.

Azure Service Bus

Queues (Azure Service Bus Queues)

El Service Bus Queues permite al emisor mandar mensajes los cuales puede capturar el receptor de manera asíncrona. Este tipo de colas pueden tener varios emisores mandando información pero cada mensaje sólo puede ser leído por un receptor. En escenarios multicast se debería optar por usar Topics como solución de comunicación.

Azure Service Bus Queues

Los mensajes de comunicación están compuestos por un cuerpo donde se adjunta  un contenido binario, y un conjunto de propiedades clave-valor.

Azure-Service-Bus-Qeues2

Este sistema de colas te permite definir dos posibles formas de tratar los mensajes cuando el receptor los intercepta:

  • ReceiveAndDelete: el receptor recibe el mensaje de la cola y inmediatamente lo borra. Tiene la problemática de no poder recuperar el mensaje en caso que el sistema receptor falle debido a que el mensaje ya haya sido borrado de la cola.
  • PeekLock: el receptor recibe el mensaje pero no lo borra de la cola sino que lo pone en estado Lock haciéndolo no visible para otros receptores. Éste sólo lo borra en caso que el procesamiento del mensaje haya ido bien. En el caso de fallo por parte del receptor, se elimina el estado Lock en el mensaje y pasa a ser visible por los demás para poder ser otra vez procesado.

Este sistema de colas son útiles en escenarios donde el emisor y receptor no están conectados al mismo tiempo y se necesita una comunicación asíncrona, por ejemplo, aplicaciones móviles o procesos batch. Otro posible escenario es usándolo como balanceador de carga, distribuyendo los mensajes entre los diferentes receptores.

Además del Azure Service Bus Queues descrito anteriormente, también existe otro servicio de colas llamado Azure Storage Queues[4] que aunque pueda parecer similar, las características que ofrecen son bastante diferentes.

Azure-Service-Bus2

La decisión de cual usar depende de los requerimientos y arquitectura de tu aplicación. Azure Storage Queues son útiles para los casos donde se requiere de una comunicación entre aplicaciones básica y el tamaño de cola puede exceder los 5GB.

Azure Service Bus Queues estaría destinada a escenarios más complejos donde por ejemplo, necesites controlar la comunicación con sesiones, transacciones, detección de mensajes duplicados, colas FIFO, tiempo de vida de los mensajes, etc.[4]

 Topics (Azure Service Bus Topic)

El Service Bus Topic es similar al servicio de colas, pero con la diferencia que se basa en un sistema de publicación-suscripción. Cada aplicación puede suscribirse a diferentes Topic[5] y definir un filtro para recibir sólo los mensajes de ese Topic que cumplan con los criterios especificados. Al igual que en las colas, las aplicaciones que reciben mensajes de el Topic al que están suscritos, pueden aplicar el sistema ReceiveAndDelete o PeekLock al procesar el mensaje.

Azure Service Bus Topic tiene un enfoque para escenarios multicast donde muchas aplicaciones están interesadas en recibir el mismo mensaje.

Service-Bus-Topics

Relay (Azure Service Bus Relay)

A diferencia de los sistemas de Queues y Topics que proporcionan una comunicación unidireccional asíncrona, el Azure Service Bus Relay ofrece una comunicación punto a punto bidireccional entre aplicaciones.

Este tipo de solución es ideal en los casos donde se quiere conectar varias aplicaciones o sistemas que están en diferentes datacenters o en casos donde se requiere comunicación entre sistemas hospedados en Azure y on-premise[6] ya que te abstrae de tener que mediar con los firewalls y NAT[7] en la comunicación.

Cada una de estas aplicaciones establece una comunicación TCP con el Service Bus Relay y la mantienen abierta. Las aplicaciones pueden usar el framework Windows Communication Foundation WFC[8] el cual facilita la comunicación y interacción entre aplicaciones por Relay bindings[9].

Service-Bus-Relay

Event Hubs (Azure Service Bus Event Hubs)

Event Hubs está destinado a gestionar el envío de eventos a gran escala. Un ejemplo de uso sería el caso en que aplicaciones o dispositivos necesitan mandar eventos de telemetría, event hubs sería la solución ideal ya que puede llegar a recibir grandes volúmenes de eventos. Cuando recibe los eventos, por debajo crea un flujo de todos estos eventos para que diferentes receptores puedan leerlo. Internamente gestiona un patrón de particiones para poder mediar con ráfagas de datos y poder retener los mensajes mayor tiempo.

También implementa los Consumer Groups por los cuales los receptores pueden leer los eventos. Los Receptores pueden usar un grupo por defecto o puedes crear diferentes grupos donde los receptores de cada grupo van a leer el flujo de datos concurrentemente pudiendo incluso fijar diferentes velocidades de lectura.

A diferencia de las soluciones de Queues o Topics que añadían un gran abanico de controles en la comunicación de mensajes, el Event Hub sacrifica todos estos controles para poder gestionar grandes flujos de eventos. La idea es que los receptores leen de un flujo de datos común y no borran los mensajes leídos sino que usan un puntero para recorrer el flujo de datos y así saber que datos han leído. Esto le permite al servicio ser mucho más eficiente ya que no tiene que gestionar que hacer con los mensajes leídos.

Azure-Events-Hub

Referencias

[1] https://msdn.microsoft.com/en-us/library/ms996406.aspx

[2] https://azure.microsoft.com/en-us/services/cloud-services

[3] https://apprenda.com/library/paas/iaas-paas-saas-explained-compared

[4] https://azure.microsoft.com/en-us/documentation/articles/service-bus-azure-and-service-bus-queues-compared-contrasted

[5] https://azure.microsoft.com/en-in/documentation/articles/service-bus-fundamentals-hybrid-solutions

[6] https://en.wikipedia.org/wiki/On-premises_software

[7] https://es.wikipedia.org/wiki/Traducci%C3%B3n_de_direcciones_de_red

[8] https://msdn.microsoft.com/es-es/library/ms731082(v=vs.110).aspx

[9] https://msdn.microsoft.com/en-us/magazine/dd569756.aspx

 

Descubre cómo SOGETI puede ayudarte en el viaje hacia la Nube.

Ramón-TomásRamón Tomás es Ingeniero superior en Telecomunicaciones por la universidad politécnica de Catalunya. Se ha unido a Sogeti recientemente, en la unidad de soluciones Microsoft en Barcelona como desarrollador analista. Anteriormente ha trabajado como desarrollador especializado en tecnología Microsoft para clientes del sector bancario.

Autor: ITblogsogeti

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s