Colas de Storage y de Service Bus: comparación y diferencias
En este artículo se analizan las diferencias y similitudes entre los dos tipos de cola que ofrece Microsoft Azure: las colas de Storage y las colas de Service Bus. Con esta información, puede tomar una decisión más fundamentada sobre la solución que mejor se adapta a sus necesidades.
Introducción
Azure admite dos tipos de mecanismos de cola: colas de Storage y colas de Service Bus.
Las colas de Storage forman parte de la infraestructura de Azure Storage. Permiten almacenar un gran número de mensajes. a los que se puede acceder desde cualquier lugar del mundo a través de llamadas autenticadas mediante HTTP o HTTPS. Un mensaje de la cola puede llegar a tener hasta 64 KB. Una cola puede contener millones de mensajes, hasta el límite de capacidad total de una cuenta de almacenamiento. Las colas se utilizan normalmente para crear un trabajo pendiente del trabajo que se va a procesar de forma asincrónica. Para obtener más información, vea ¿Qué son las colas de Azure Storage?
Las colas de Service Bus forman parte de una infraestructura de mensajería de Azure más amplia que admite la puesta en cola, la publicación o suscripción y patrones de integración más avanzados. Están diseñadas para integrar aplicaciones o componentes de aplicaciones que pueden abarcar varios protocolos de comunicación, contratos de datos, dominios de confianza o entornos de red. Para obtener más información sobre las colas, los temas o las suscripciones de Service Bus, vea Colas, temas y suscripciones de Service Bus.
Consideraciones de selección de tecnología
Las colas de Storage y Service Bus tienen un conjunto de características ligeramente diferente. Puede elegir una o las dos, en función de las necesidades de la solución concreta.
A la hora de determinar qué tecnología de cola se ajusta al propósito de una solución determinada, los desarrolladores y arquitectos de soluciones deben tener en cuenta estas recomendaciones.
Consideración del uso de colas de Storage
Como arquitecto o desarrollador de soluciones, debe considerar el uso de colas de Storage en los siguientes casos:
- La aplicación debe almacenar más de 80 gigabytes de mensajes en una cola.
- La aplicación quiere realizar un seguimiento del progreso del procesamiento de un mensaje de la cola. Esto es útil si se bloquea el trabajo que está procesando un mensaje. Otro trabajo puede usar esa información para continuar desde donde lo ha dejado el trabajo anterior.
- Necesita registros de lado de servidor de todas las transacciones ejecutadas con las colas.
Consideración del uso de colas de Service Bus
Como arquitecto o desarrollador de soluciones, debe considerar el uso de colas de Service Bus cuando:
- La solución necesita recibir mensajes sin tener que sondear la cola. Con Service Bus, esto se logra mediante una operación de recepción de sondeo largo con los protocolos basados en TCP que admite Service Bus.
- Su solución requiere que la cola ofrezca una entrega ordenada por primero en entrar es el primero en salir (FIFO).
- La solución necesita admitir la detección automática de duplicados.
- Quiera que su aplicación procese mensajes como flujos de larga ejecución en paralelo (los mensajes se asocian a un flujo mediante la propiedad Id. de sesión del mensaje). En este modelo, cada nodo de la aplicación de consumo compite por secuencias, en lugar de los mensajes. Cuando se proporciona una secuencia a un nodo de consumo, el nodo puede examinar el estado de la secuencia de aplicación mediante transacciones.
- Su solución requiere un comportamiento transaccional y atomicidad al enviar o recibir varios mensajes desde una cola.
- La aplicación controla los mensajes que pueden superar los 64 KB, pero que probablemente no se acercarán al límite de 256 KB o 1 MB, en función del nivel de servicio elegido (aunque las colas de Service Bus pueden controlar mensajes de hasta 100 MB).
- Aborda un requisito para ofrecer un modelo de acceso basado en roles a las colas y diferentes derechos o permisos para los remitentes y receptores. Para más información, consulte los siguientes artículos.
- El tamaño de la cola no va a aumentar a más de 80 GB.
- Quiere usar el protocolo de mensajería basado en estándares AMQP 1.0. Para obtener más información sobre AMQP, vea Introducción al AMQP de Service Bus.
- Prevé una posible migración de la comunicación de punto a punto basada en colas a un patrón de mensajería de publicación a suscripción. Este patrón permite la integración de receptores adicionales (suscriptores). Cada receptor recibe copias independientes de algunos o todos los mensajes enviados a la cola.
- La solución de mensajería debe admitir las garantías de entrega "Una vez como máximo" y "Una vez como mínimo" sin necesidad de compilar los componentes de infraestructura adicionales.
- La solución necesita publicar y consumir lotes de mensajes.
Comparación de colas de Storage con colas de Service Bus
Las tablas de las secciones siguientes proporcionan una agrupación lógica de características de cola. Permiten comparar, de un vistazo, las capacidades disponibles tanto en las colas de Azure Storage como en las colas de Service Bus.
Capacidades fundamentales
En esta sección se comparan algunas de las funcionalidades de puesta en cola fundamentales ofrecidas por las colas de Storage y las colas de Service Bus.
| Criterios de comparación | Colas de Storage | Colas de Service Bus |
|---|---|---|
| Garantía de ordenación | No Para obtener más información, vea la primera nota de la sección Información adicional. |
Sí: primero en entrar, primero en salir (FIFO) (mediante sesiones de mensajes) |
| Garantía de entrega | Una vez como mínimo | Al menos una vez (con el modo de recepción PeekLock, este es el valor predeterminado) Como máximo una vez (usando el modo de recepción ReceiveAndDelete) Más información sobre los distintos modos de recepción. |
| Compatibilidad con la operación atómica | No | Sí |
| Comportamiento de recepción | Sin bloqueo (se completa inmediatamente si no se encuentra ningún mensaje nuevo) |
Bloqueo con o sin un tiempo de espera (ofrece sondeo largo o "Técnica de cometa") Sin bloqueo (solo con la API administrada de .NET) |
| API de estilo de inserción | No | Sí Nuestros SDK de .NET, Java, JavaScript y Go proporcionan API de estilo de inserción. |
| Modo de recepción | Ojear y alquilar | Ojear y bloquear Recibir y eliminar |
| Modo de acceso exclusivo | Basado en concesión | Basado en bloqueo |
| Duración de concesión/bloqueo | 30 segundos (valor predeterminado) 7 días (máximo) (puede renovar o liberar una concesión de mensaje mediante la API de UpdateMessage). |
30 segundos (valor predeterminado) Puede renovar el bloqueo de mensajes para la misma duración de bloqueo cada vez manualmente o usar la característica de renovación automática de bloqueos donde el cliente administra automáticamente la renovación de bloqueos. |
| Precisión de concesión/bloqueo | Nivel de mensaje Cada mensaje puede tener un valor de tiempo de espera diferente, que luego se puede actualizar según sea necesario al procesar el mensaje, mediante la API UpdateMessage. |
Nivel de cola (cada cola tiene aplicada una precisión de bloqueo a todos sus mensajes, pero el bloqueo se puede renovar como se describe en la fila anterior) |
| Recepción por lotes | Sí (especificando explícitamente el número de mensajes al recuperar mensajes, hasta un máximo de 32 mensajes) |
Sí (habilitando implícitamente una propiedad de captura previa o explícitamente mediante el uso de transacciones) |
| Envío por lotes | No | Sí (mediante transacciones o procesamiento por lotes del lado cliente) |
Información adicional
- Los mensajes de las colas de Storage son normalmente del tipo "primero en entrar, primero en salir" (FIFO), pero en ocasiones pueden estar desordenados. Por ejemplo, si expira la duración del tiempo de espera de visibilidad de un mensaje porque una aplicación cliente se ha bloqueado al procesar un mensaje. Cuando expira el tiempo de espera de visibilidad, el mensaje se vuelve visible en la cola para que otro trabajador lo quite de la cola. En ese momento, el mensaje que acaba de hacerse visible se puede colocar en la cola (para quitarlo después).
- El patrón de FIFO garantizado en las colas de Service Bus requiere el uso de sesiones de mensajería. Si la aplicación se bloquea mientras está procesando un mensaje recibido en el modo Inspección y bloqueo, la siguiente vez que un receptor de la cola acepte una sesión de mensajería, iniciará con el mensaje fallido después de que expire la duración del bloqueo de la sesión.
- Las colas de Storage están diseñadas para admitir escenarios estándar de puesta en cola, por ejemplo:
- Desacoplamiento de componentes de aplicación para aumentar la escalabilidad y la tolerancia a errores
- Redistribución de la carga
- Compilación de flujos de trabajo de proceso.
- Se pueden evitar incoherencias con respecto al control de mensajes en el contexto de las sesiones de Service Bus al usar el estado de sesión para almacenar el estado de la aplicación relativo al progreso del control de la secuencia de mensajes de la sesión y mediante el uso de transacciones sobre la fijación de los mensajes recibidos y la actualización del estado de la sesión. Este tipo de característica de coherencia a veces se etiqueta como procesamiento Una sola vez en los productos de otros proveedores. Los errores de transacción obviamente hacen que se vuelvan a entregar los mensajes, por lo que el término no es del todo adecuado.
- Las colas de Storage ofrecen un modelo de programación coherente y uniforme en las colas, tablas y blobs, tanto para desarrolladores como para los equipos de operaciones.
- Las colas de Service Bus ofrecen compatibilidad con transacciones locales en el contexto de una sola cola.
- El modo Recibir y eliminar compatible con el Service Bus ofrece la capacidad de reducir el número de operaciones de mensajería (y el costo asociado) a cambio de una garantía de entrega menor.
- Las colas de Storage ofrecen concesiones con la posibilidad de ampliar las concesiones para mensajes. Esta característica permite que los procesos de trabajo mantengan breves concesiones sobre los mensajes. Por lo tanto, si se bloquea un trabajo, otro puede volver a procesar rápidamente el mensaje. Además, un trabajo puede ampliar la concesión sobre un mensaje si necesita procesarlo durante más tiempo que el de concesión actual.
- Las colas de Storage ofrecen un tiempo de espera de visibilidad que puede establecer al poner en cola un mensaje o quitarlo de la cola. Además, puede actualizar un mensaje con distintos valores de concesión en tiempo de ejecución y actualizar distintos valores en mensajes de la misma cola. Los tiempos de espera de bloqueo de Service Bus se definen en los metadatos de la cola. Sin embargo, puede renovar el bloqueo de mensajes para la duración de bloqueo predefinida manualmente o usar la característica de renovación automática de bloqueos donde el cliente administra automáticamente la renovación de bloqueos.
- El tiempo de espera máximo para una operación de recepción de bloqueo en las colas de Service Bus es de 24 días. Sin embargo, los tiempos de espera basados en REST tienen un valor máximo de 55 segundos.
- El procesamiento por lotes del cliente ofrecido por el Service Bus permite a un cliente de cola procesar varios mensajes por lotes en una sola operación de envío. El procesamiento por lotes solo está disponible para las operaciones de envío asincrónicas.
- Características como el límite de 200 TB de las colas de Storage (más cuando se virtualizan las cuentas) y las colas ilimitadas la convierten en la plataforma idónea para los proveedores de SaaS.
- Las colas de Storage ofrecen un mecanismo de control de acceso delegado flexible y eficiente.
Capacidades avanzadas
En esta sección se comparan algunas de las funcionalidades avanzadas ofrecidas por las colas de Storage y las colas de Service Bus.
| Criterios de comparación | Colas de Storage | Colas de Service Bus |
|---|---|---|
| Entrega programada | Sí | Sí |
| Mensajes fallidos automáticos | No | Sí |
| Aumentar el valor de período de vida de cola | Sí (a través de la actualización local de tiempo de espera de visibilidad) |
Sí (proporcionado mediante una función de API dedicada) |
| Compatibilidad con mensajes dudosos | Sí | Sí |
| Actualización local | Sí | Sí |
| Registro de transacciones del servidor | Sí | No |
| Métricas de almacenamiento | Sí Métricas por minuto proporciona métricas en tiempo real de disponibilidad, TPS, recuentos de llamadas API, recuentos de errores y mucho más. Todas ellas son en tiempo real, se agregan por minuto y se muestran pocos minutos después de lo que ha ocurrido en producción. Para obtener más información, vea Acerca de las métricas de Storage Analytics. |
Sí Para información sobre las métricas admitidas por Azure Service Bus, consulte Métricas de mensajes. |
| Administración de estados | No | Sí (Active, Disabled, SendDisabled, ReceiveDisabled. Para más información sobre estos estados, consulte Estado de la cola). |
| Reenvío automático de mensajes | No | Sí |
| Purgar la función de cola | Sí | Sí |
| Grupos de mensajes | No | Sí (mediante sesiones de mensajería) |
| Estado de la aplicación por grupo de mensajes | No | Sí |
| Detección de duplicados | No | Sí (configurable en el lado del remitente) |
| Exploración de grupos de mensaje | No | Sí |
| Captura de sesiones de mensajes por id. | No | Sí |
Información adicional
- Ambas tecnologías de cola permiten que se programe un mensaje para su entrega posteriormente.
- El reenvío automático de colas permite el reenvío automático por parte de miles de colas de sus mensajes a una única cola, desde la que la aplicación receptora consume el mensaje. Puede usar este mecanismo para lograr seguridad, flujo de control y aislar el almacenamiento aislado entre cada publicador de mensajes.
- Las colas de Storage ofrecen compatibilidad para actualizar el contenido del mensaje. Puede usar esta funcionalidad para conservar información de estado y actualizaciones incrementales de progreso en el mensaje para que se pueda procesar desde el último punto de comprobación conocido, en lugar de hacerlo desde el principio. Con las colas de Service Bus, puede habilitar el mismo escenario mediante el uso de sesiones de mensajes. Para más información, consulte Estado de la sesión de mensajes.
- Las colas de Service Bus admiten mensajes fallidos. Esto puede ser útil para aislar los mensajes que cumplen los criterios siguientes:
- La aplicación receptora no puede procesar los mensajes correctamente.
- Los mensajes no pueden llegar a su destino debido a una propiedad de período de vida (TTL) expirada. El valor de TTL especifica cuánto tiempo permanece un mensaje en la cola. Con Service Bus, el mensaje se moverá a una cola especial denominada $DeadLetterQueue cuando expira el período de vida.
- Para encontrar mensajes "dudosos" en las colas de Storage, al quitar de la cola un mensaje de la aplicación se examina la propiedad DequeueCount del mensaje. Si DequeueCount se encuentra por encima de un umbral determinado, la aplicación mueve el mensaje a una cola de proceso como correo devuelto definida por la aplicación.
- Las colas de Storage permiten obtener un registro detallado de todas las transacciones ejecutadas en la cola y de las métricas agregadas. Ambas opciones son útiles para depurar y entender cómo usa su aplicación las colas de Storage. También son útiles para ajustar el rendimiento de la aplicación y reducir los costos del empleo de colas.
- Las sesiones de mensajes que admite Service Bus permiten asociar los mensajes que pertenecen a un grupo lógico a un receptor. Eso crea una afinidad de tipo sesión entre los mensajes y sus destinatarios respectivos. Puede habilitar esta funcionalidad avanzada en Service Bus estableciendo la propiedad de id. de sesión en un mensaje. Los receptores pueden escuchar entonces en un id. de sesión específico y recibir mensajes que comparten el identificador de sesión especificado.
- La característica de detección de duplicación de colas de Service Bus elimina automáticamente los mensajes duplicados enviados a una cola o un tema, según el valor de la propiedad de id. de mensaje.
Capacidad y cuotas
En esta sección se comparan las colas de Storage y las colas de Service Bus desde la perspectiva de la capacidad y las cuotas que se pueden aplicar.
| Criterios de comparación | Colas de Storage | Colas de Service Bus |
|---|---|---|
| Tamaño de cola máximo | 500 TB (limitado a una capacidad de cuenta de almacenamiento única) |
De 1 GB a 80 GB (Nivel Premium o Estándar con particiones) |
| Tamaño de mensaje máximo | 64 KB (48 KB al usar codificación Base 64) Azure admite mensajes de gran tamaño mediante la combinación de colas y blobs, momento en el que puede poner en cola hasta 200 GB para un solo elemento. |
256 KB, 1 MB o 100 MB (incluidos tanto el encabezado como el cuerpo, el tamaño máximo de encabezado es: 64 KB). Depende del nivel de servicio. |
| TTL de mensaje máximo | Infinito (api-version 2017-07-27 o posterior) | TimeSpan.MaxValue |
| Número máximo de colas | Ilimitado | 10 000 (nivel Estándar) 1000 / Unidad de mensajería (nivel Premium) (por espacio de nombres de servicio) |
| Número máximo de clientes simultáneos | Sin límite | 5\.000 |
Información adicional
- Service Bus aplica límites de tamaño de cola. El tamaño máximo de cola se especifica al crear una cola. Puede ser de entre 1 GB y 80 GB. Si el tamaño de la cola alcanza este límite, se rechazan los mensajes entrantes adicionales y el autor de la llamada recibe una excepción. Para obtener más información sobre las cuotas en el Service Bus, vea Cuotas de Service Bus.
- En el nivel de mensajería Estándar, puede crear colas y temas de Service Bus de 1 (valor predeterminado), 2, 3, 4 o 5 GB. Al habilitar la partición en el nivel estándar, Service Bus crea 16 copias (16 particiones) de la entidad, cada una del mismo tamaño especificado. Por lo tanto, si crea una cola con un tamaño de 5 GB y 16 particiones, el tamaño de cola máximo se convierte en (5 * 16) = 80 GB. Puede ver el tamaño máximo de la cola o el tema con particiones en Azure Portal.
- Con las colas de Storage, si el contenido del mensaje no es seguro para XML, debe estar codificado en Base64. Si codifica el mensaje con Base64, la carga de usuario puede ser de hasta 48 KB, en lugar de 64 KB.
- Con las colas de Service Bus, cada mensaje almacenado en una cola consta de dos partes: un encabezado y un cuerpo. El tamaño total del mensaje no puede superar el tamaño máximo admitido por el nivel de servicio.
- Cuando los clientes se comunican con colas de Service Bus por el protocolo TCP, el número máximo de conexiones simultáneas a una única cola de Service Bus se limita a 100. Este número se comparte entre remitentes y receptores. Si se alcanza esta cuota, se rechazan las solicitudes de conexiones adicionales y el código de llamada recibe una excepción. Este límite no se impone en clientes que se conectan a las colas mediante la API basada en REST.
- Para escalar más allá de 10 000 colas con SKU estándar de Service Bus o 1000 colas o unidad de mensajería con SKU Premium de Service Bus, también puede crear espacios de nombres adicionales mediante el Azure Portal.
Administración y operaciones
En esta sección se comparan algunas de las características de administración ofrecidas por las colas de Storage y las colas de Service Bus.
| Criterios de comparación | Colas de Storage | Colas de Service Bus |
|---|---|---|
| Protocolo de administración | REST sobre HTTP/HTTPS | REST sobre HTTPS |
| Protocolo de tiempo de ejecución | REST sobre HTTP/HTTPS | REST sobre HTTPS Estándar AMQP 1.0 (TCP con TLS) |
| API de .NET | Sí (API de cliente de Storage para .NET) |
Sí (API de Service Bus para .NET) |
| C++ nativo | Sí | Sí |
| API de Java | Sí | Sí |
| API de PHP | Sí | Sí |
| API de Node.js. | Sí | Sí |
| Compatibilidad con metadatos arbitrarios | Sí | No |
| Reglas de nomenclatura de cola | Hasta 63 caracteres de longitud (las letras de un nombre de cola deben estar en minúscula). |
Hasta 260 caracteres de longitud (los nombres y las rutas de acceso de las colas no distinguen mayúsculas de minúsculas). |
| Función de obtención de la longitud de la cola | Sí (valor aproximado si los mensajes expiran más allá del TTL sin eliminarse). |
Sí (valor exacto en un momento dado). |
| Función de ojear | Sí | Sí |
Información adicional
- Las colas de Storage ofrecen compatibilidad con atributos arbitrarios que se pueden aplicar a la descripción de la cola, en forma de pares de nombre-valor.
- Ambas tecnologías de cola ofrecen la capacidad de ojear un mensaje sin tener que bloquearlo, lo que puede resultar útil al implementar una herramienta de explorador de colas.
- Las API de mensajería asíncrona de .NET de Service Bus usan las conexiones TCP de dúplex completo para mejorar el rendimiento en comparación con REST a través de HTTP, y admiten el protocolo estándar AMQP 1.0.
- Los nombres de colas de Storage pueden tener de 3 a 63 caracteres de longitud que pueden incluir letras minúsculas, números y guiones. Para obtener más información, vea Nomenclatura de colas y metadatos.
- Los nombres de cola de Service Bus pueden tener hasta 260 caracteres y reglas de nomenclatura menos restrictivas. Los nombres de cola de Service Bus pueden contener letras, números, puntos, guiones y caracteres de subrayado.
Autenticación y autorización
En esta sección se describen las características de autenticación y autorización compatibles con las colas de Storage y las colas de Service Bus.
| Criterios de comparación | Colas de Storage | Colas de Service Bus |
|---|---|---|
| Authentication | Clave simétrica y control de acceso basado en roles (RBAC) | Clave simétrica y control de acceso basado en roles (RBAC) |
| Federación de proveedor de identidad: | Sí | Sí |
Información adicional
- Se debe autenticar cada solicitud a cualquiera de las tecnologías de cola. No se admiten colas públicas con acceso anónimo.
- Mediante la autenticación de firma de acceso compartido (SAS), puede crear una regla de autorización de acceso compartido en una cola que pueda proporcionar a los usuarios acceso de solo escritura, de solo lectura o completo. Para más información, consulte Azure Storage: autenticación de SAS y Azure Service Bus: autenticación de SAS.
- Ambas colas admiten la autorización del acceso mediante Microsoft Entra ID. La autorización de usuarios o aplicaciones mediante un token de OAuth 2.0 devuelto por Microsoft Entra ID proporciona una seguridad superior y facilidad de uso sobre las firmas de acceso compartido (SAS). Con Microsoft Entra ID, no es necesario almacenar los tokens en el código y arriesgarse a posibles vulnerabilidades de seguridad. Para más información, consulte Azure Storage: autenticación de Microsoft Entra y Azure Service Bus: autenticación de Microsoft Entra.
Conclusión
Una mejor comprensión de las dos tecnologías permite tomar una decisión más fundamentada sobre la tecnología de cola que se va a usar y cuándo. La decisión sobre cuándo usar las colas de Storage o las colas de Service Bus depende claramente de muchos factores. Estos factores dependen en gran medida de las necesidades individuales de la aplicación y de su arquitectura.
Quizás prefiera elegir las colas de Storage por los siguientes motivos:
- Si la aplicación ya usa las capacidades básicas de Microsoft Azure
- Si necesita comunicación básica y mensajería entre servicios
- Si necesita colas que puedan tener un tamaño superior a 80 GB
Las colas de Service Bus proporcionan muchas características avanzadas, como las siguientes. Por lo tanto, pueden ser la opción preferida si va a compilar una aplicación híbrida o si la aplicación requiere estas características.
- Sesiones
- Transactions
- Detección de duplicados
- Mensajes fallidos automáticos
- Capacidades de publicación y suscripción duraderas
Pasos siguientes
En los artículos siguientes se ofrece más orientación e información sobre el uso de las colas de Storage o las colas de Service Bus.