Elección de una plataforma de mensajería
Hay muchas plataformas de comunicaciones disponibles para ayudarle a mejorar la confiabilidad de una aplicación distribuida, incluidas varias en Microsoft Azure. Cada plataforma es una herramienta que tiene un propósito diferente. Es importante elegir la herramienta adecuada para cada requisito de la aplicación. Eche un vistazo a las opciones de Azure Service Bus.
La arquitectura distribuida de la aplicación propuesta para solicitud y seguimiento de pedidos de Contoso Bicycles requiere varios componentes, entre otros, un sitio web, un almacenamiento de datos y un servicio back-end. Puede enlazar componentes de la aplicación de muchas maneras diferentes, y una sola aplicación puede utilizar varias técnicas.
Debe decidir qué técnicas va a usar en la nueva aplicación de Contoso Bicycles. El primer paso es evaluar cada lugar donde hay comunicación entre varias partes. Algunos componentes se deben ejecutar de forma puntual para que la aplicación cumpla su propósito. Algunos pueden ser importantes, pero no críticos en el tiempo. Por último, otros componentes, como las notificaciones de la aplicación móvil, son un poco más opcionales.
Decidir entre mensajes y eventos
Tanto los mensajes como los eventos son datagramas: paquetes de datos que se envían de un componente a otro. Presentan diferencias que al principio parecen sutiles, pero pueden resultar significativas a la hora de diseñar la aplicación.
Mensajes
En la terminología de las aplicaciones distribuidas, la característica definitoria de un mensaje es que la integridad general de la aplicación puede depender de la recepción de mensajes. Puede pensar en el envío de un mensaje como un componente que pasa el testigo de un flujo de trabajo a otro componente. El flujo de trabajo completo puede ser un proceso empresarial vital, y el mensaje es el mortero que sostiene los componentes entre sí.
En general, un mensaje contiene los datos reales, no solo una referencia a ellos (por ejemplo, una dirección URL o un identificador). El envío de datos como parte de un datagrama es menos frágil que el envío de una referencia. La arquitectura de mensajería garantiza la entrega del mensaje y, como no se necesitan búsquedas adicionales, el mensaje se controla de forma confiable. Pero la aplicación remitente debe saber exactamente qué datos se van a incluir para evitar enviar demasiados datos, lo que exige que el componente receptor trabaje innecesariamente. En este sentido, el remitente y el receptor de un mensaje a menudo se asocian por un contrato de datos estricto.
En la nueva arquitectura de Contoso Bicycles, cuando se hace un pedido, es probable que la empresa use mensajes. El front-end web o la aplicación móvil enviarán un mensaje a los componentes de procesamiento de back-end. En el back-end, se realizarán pasos como el enrutamiento a la tienda más cercana al cliente y el cobro en la tarjeta de crédito.
Eventos
Un evento desencadena la notificación de que ha sucedido algo. Los eventos son "más ligeros" que los mensajes y son los que se usan con más frecuencia para difundir comunicaciones.
Los eventos tienen las siguientes características:
- El evento puede enviarse a varios destinatarios o a ninguno.
- Los eventos suelen estar diseñados para la "distribución ramificada de salida" o para disponer de un número elevado de suscriptores para cada publicador.
- El publicador del evento no tiene ninguna expectativa sobre la acción que realiza un componente receptor.
Una cadena de repuestos de bicicletas probablemente use eventos para las notificaciones a los usuarios sobre los cambios de estado. Los eventos de cambio de estado se podrían enviar a Azure Event Grid, luego a Azure Functions y a Azure Notification Hubs para una solución completamente sin servidor.
Esta diferencia entre los eventos y los mensajes es fundamental porque, en general, las plataformas de comunicaciones están diseñadas para controlar unos u otros. Service Bus está diseñado para controlar los mensajes. Si quiere enviar eventos, es probable que elija Event Grid.
Azure también ofrece Azure Event Hubs, pero se suele utilizar para un tipo específico de transmisión de comunicaciones de flujo alto que se usa para el análisis. Por ejemplo, si tuviera sensores conectados en red en los almacenes de las fábricas, podría usar Event Hubs junto con Azure Stream Analytics para detectar patrones en los cambios de temperatura que podrían indicar un fuego no deseado o desgaste de componentes.
Temas y colas de Service Bus
Azure Service Bus puede intercambiar mensajes de dos maneras diferentes: colas y temas.
¿Qué es una cola?
Una cola de Service Bus es una ubicación de almacenamiento temporal simple para los mensajes. Un componente de envío agrega un mensaje a la cola. Un componente de destino selecciona el mensaje al comienzo de la cola. En circunstancias normales, un solo receptor recibe cada mensaje.
Las colas desacoplan los componentes de origen y destino para aislar los componentes de destino de la alta demanda.
Durante las horas pico, se pueden recibir mensajes a una velocidad mayor de la que los componentes de destino pueden controlar. Como los componentes de origen no tienen ninguna conexión directa al destino, el origen no se verá afectado y aumentará la cola. Los componentes de destino quitarán los mensajes de la cola a medida que sean capaces de controlarlos. Cuando la demanda baja, los componentes de destino pueden ponerse al día y acortar la cola.
Una cola responde a una demanda alta sin necesidad de agregar recursos al sistema. Aun así, cuando los mensajes deben administrarse de forma rápida, crear más instancias del componente de destino puede permitirles compartir la carga. Cada mensaje se controla desde una única instancia. Se trata de una forma eficaz de escalar toda la aplicación, al agregar recursos solo a los componentes que en verdad los necesitan.
¿Qué es un tema?
Un tema de Service Bus es similar a una cola, pero puede tener varias suscripciones. Esto significa que varios componentes de destino pueden suscribirse a un tema específico, para que cada mensaje se entregue a varios receptores. Las suscripciones también pueden filtrar los mensajes en el tema para que solo se reciban los mensajes que sean pertinentes. Las suscripciones proporcionan la mismas comunicaciones desacopladas que las colas y responden a la alta demanda de la misma manera. Si desea que cada mensaje que se entregue a más de un componente de destino, utilice un tema.
Nota:
En el plan de tarifas Básico no se admiten los temas.
Colas de Service Bus y colas de almacenamiento
Dos servicios de Azure incluyen colas de mensajes: Service Bus y Azure Storage. Como guía general, las colas de almacenamiento son más fáciles de usar, pero menos sofisticadas y flexibles que las colas de Service Bus.
Entre las ventajas clave de las colas de Service Bus se incluyen:
- Admite tamaños de mensaje superiores de 256 KB (nivel estándar) o 100 MB (nivel premium) por mensaje frente a 64 KB en el caso de los mensajes de cola de Azure Storage.
- Admite las entregas una vez como máximo y una vez como mínimo. Elija entre una probabilidad muy pequeña de que se pierda un mensaje o una probabilidad muy pequeña de que se tramite dos veces.
- Garantiza el orden de primero en entrar, primero en salir (FIFO). Los mensajes se tramitan en el mismo orden en que se agregan. Aunque el orden FIFO es el funcionamiento normal de una cola, el patrón FIFO predeterminado se modifica si la organización configura mensajes secuenciados o programados o durante interrupciones como un bloqueo del sistema. Para más información, vea Comparación de las colas de Azure Storage y de Azure Service Bus.
- Puede agrupar varios mensajes en una transacción. Si no se puede entregar un mensaje de la transacción, todos los demás tampoco se entregarán.
- Se admite la seguridad basada en roles.
- No se requiere que los componentes de destino sondeen la cola continuamente.
Ventajas de las colas de almacenamiento:
- Se admite un tamaño de cola ilimitado (frente al límite de 80 GB de las colas de Service Bus).
- Se mantiene un registro de todos los mensajes.
Cómo elegir una tecnología de comunicaciones
Ha visto los distintos conceptos y las implementaciones que Azure proporciona. A continuación, piense en cómo debería ser su proceso de toma de decisiones para cada una de las comunicaciones.
Consideraciones
A medida que elija un método para enviar y recibir mensajes, tenga en cuenta las siguientes preguntas:
¿Es la comunicación un evento? Si es así, considere la posibilidad de usar Event Grid o Event Hubs.
¿Debería entregarse un único mensaje a más de un destino? Si es así, use un tema de Service Bus. De lo contrario, use una cola de Service Bus.
Colas: Service Bus frente a Storage
Si decide que necesita una cola, restrinja aún más su elección.
Elija una cola de Service Bus si:
- Necesita una garantía de entrega de una vez como máximo.
- Necesita una garantía FIFO (si ninguna otra configuración se anticipa al orden FIFO predeterminado).
- Necesita agrupar los mensajes en transacciones.
- Quiere recibir mensajes sin sondear la cola.
- Tiene que proporcionar un acceso basado en roles a las colas.
- Debe controlar mensajes de más de 64 KB pero de menos de 256 KB en el nivel estándar o 100 MB en el nivel prémium.
- El tamaño de la cola no va a aumentar a más de 80 GB.
- Le gustaría poder publicar y consumir lotes de mensajes.
Elija una cola de Storage si:
- Necesita una cola simple sin requisitos adicionales determinados.
- Necesita un registro de auditoría de todos los mensajes que pasan por la cola.
- Espera que la cola supere el tamaño de 80 GB.
- Quiere realizar el seguimiento del progreso para procesar un mensaje dentro de la cola.
Aunque los componentes de una aplicación distribuida se pueden comunicar directamente, a menudo puede aumentar la confiabilidad de esa comunicación mediante una plataforma de comunicación intermedia, como Azure Event Hubs o Azure Event Grid.
Event Hubs y Event Grid están diseñados para los eventos, que solo notifican a los destinatarios de un evento y no contienen los datos sin procesar asociados al evento. Azure Event Hubs está diseñado para eventos de tipos de análisis de alto flujo.
Las colas de Azure Service Bus y de almacenamiento son para mensajes, que se pueden usar para enlazar las partes centrales de cualquier flujo de trabajo de aplicación.
Si sus requisitos son simples, si quiere enviar cada mensaje a un único destino, o bien si quiere escribir código lo más rápido posible, una cola de almacenamiento puede ser la mejor opción. En caso contrario, las colas de Service Bus proporcionan muchas más opciones y flexibilidad.
Si quiere enviar mensajes a varios suscriptores, use un tema de Service Bus.