En este escenario se describe cómo diseñar una solución que procese los cambios que se realizan en los datos subyacentes de una vista web, sin necesidad de actualizar la página, mediante servicios en tiempo real. Entre los ejemplos de uso de este escenario se encuentran el seguimiento en tiempo real de productos y mercancías, y algunas soluciones para redes sociales.
Architecture
Descargue un archivo Visio de esta arquitectura.
Componentes
- Azure Service Bus es un servicio muy fiable de mensajería en la nube entre aplicaciones y servicios, incluso si uno o varios de esos servicios o aplicaciones están sin conexión.
- Azure SignalR Service facilita la incorporación de comunicaciones en tiempo real a una aplicación web.
- Azure Functions es una plataforma de proceso sin servidor basada en eventos que también puede solucionar problemas de orquestación complejos.
Alternativas
Hay varias alternativas para abordar este escenario, entre las que se incluye Pusher. Es el líder de su categoría en las API sólidas para los desarrolladores de aplicaciones que crean características de comunicación escalables en tiempo real.
También existe PubNub. PubNub permite agregar fácilmente funcionalidades en tiempo real a las aplicaciones, sin tener que preocuparse por la infraestructura. Cree aplicaciones que permitan a los usuarios participar en tiempo real desde dispositivos móviles, exploradores, equipos de escritorio y servidores.
Ably es otra alternativa. Proporciona mensajería de publicación/suscripción (pub/sub) sin servidor, que se escala de forma confiable con sus necesidades. La mensajería se entrega en el perímetro mediante WebSockets. La plataforma Ably proporciona una infraestructura en tiempo real distribuida globalmente, de alta disponibilidad y escalable de forma elástica, con la llamada de una API.
Aunque Pusher, PubNub y Ably son las plataformas de mensajería en tiempo real más utilizadas, para este escenario todas las operaciones se realizarán en Azure. Se recomienda el uso de la plataforma SignalR, ya que permite la comunicación bidireccional entre el servidor y el cliente. También es una herramienta de código abierto con 79 000 estrellas de GitHub y 22 000 bifurcaciones de GitHub.
Para más información, vea el repositorio de código abierto de SignalR en GitHub.
Detalles del escenario
En este escenario, verá cómo configurar un servicio de mensajería en tiempo real para compartir la ubicación en directo de la transacción de un servicio de comida a domicilio. Este ejemplo también puede ser útil para los usuarios que intentan crear una plataforma a fin de compartir la ubicación en tiempo real para sus aplicaciones web o para dispositivos móviles.
Usará el servicio SignalR configurado en modo sin servidor para integrarlo en una aplicación de Azure Functions desencadenada por Service Bus, y todo ello mediante .NET Core.
Posibles casos de uso
Estos otros casos de usos tienen patrones de diseño similares:
- Uso compartido de la ubicación en tiempo real con dispositivos cliente
- Envío de notificaciones de inserción a usuarios
- Actualización de escalas de tiempo
- Creación de salones de chat
Consideraciones
Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Estos son un par de aspectos que debe tener en cuenta a la hora de desarrollar este escenario, como la forma de configurar parámetros en la cadena de conexiones de Azure Service Bus en ServiceBusTrigger:
- Centros: los centros se pueden comparar con un servicio de streaming de vídeo. Puede suscribirse a un centro para enviar y recibir mensajes desde y hacia él.
- Destinos: los destinos son como emisoras de radio. Incluyen a todos los usuarios que escuchan el canal de destino y reciben una notificación cuando hay algún mensaje nuevo.
Si puede recordar las dos características anteriores de la plataforma SignalR, le costará muy poco empezar a trabajar rápidamente.
Disponibilidad, escalabilidad y seguridad
Puede lograr la alta disponibilidad con esta solución si sigue lo que se describe en las dos secciones siguientes.
Emparejamiento regional
Cada región de Azure se empareja con otra región de la misma zona geográfica. En general, elija regiones del mismo par de regional (por ejemplo, Este de EE. UU. 2 y Centro de EE. UU.). Las ventajas de hacerlo son:
- Si se produce una interrupción prolongada, se establece como prioridad la recuperación de al menos una región de cada par.
- Las actualizaciones planeadas del sistema de Azure se implementan en las regiones emparejadas de manera secuencial para reducir el posible tiempo de inactividad.
- En la mayoría de los casos, los pares regionales residen en la misma zona geográfica para cumplir los requisitos de residencia de datos.
- Pero asegúrese de que las dos regiones admitan todos los servicios de Azure necesarios para la aplicación. Consulte Regiones de Azure. Para más información sobre los pares regionales, consulte Continuidad empresarial y recuperación ante desastres (BCDR): Regiones emparejadas de Azure.
Azure Front Door
Descargue un archivo Visio de esta arquitectura.
Azure Front Door es un punto de entrada escalable y seguro para la entrega rápida de aplicaciones globales. Al usar el enrutamiento prioritario, realiza automáticamente una conmutación por error si la región primaria deja de estar disponible. Una arquitectura de varias regiones puede proporcionar una mayor disponibilidad que la implementación en una sola región. Si una interrupción regional afecta a la región primaria, puede usar Front Door realizar una conmutación por error a la región secundaria.
Esta arquitectura también puede ayudar si un se produce un error en algún subsistema individual de la solución. Detenga los ataques tanto a la red como a las aplicaciones en el perímetro con un firewall de aplicaciones web y DDoS Protection. Proteja el servicio mediante conjuntos de reglas administradas de Microsoft y cree reglas propias para dotar a la aplicación de protección personalizada.
Front Door es un posible punto de error en el sistema. Si el servicio no funciona, los clientes no pueden acceder a la aplicación durante el tiempo de inactividad. Revise el Acuerdo de Nivel de Servicio (SLA) de Front Door y determine si el uso de Front Door por sí solo cumple los requisitos empresariales de alta disponibilidad. Si no es así, considere la posibilidad de agregar otra solución de administración de tráfico como reserva. Si el servicio Front Door no funciona, cambie los registros de nombre canónico (CNAME) de DNS para que apunten al otro servicio de administración del tráfico. Debe realizar este paso manualmente, y la aplicación dejará de estar disponible hasta que se propaguen los cambios de DNS.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
Imagine que la empresa tiene 1000 pedidos en un día y necesita compartir los datos de ubicación con todos ellos simultáneamente. El uso estimado de Azure para implementar este escenario será cercano de 192 USD al mes, según los precios en la fecha de publicación.
| Tipo de servicio | Costo mensual estimado |
|---|---|
| Azure Functions | 119,40 USD |
| Servicio Azure SignalR | 48,97 USD |
| Azure Service Bus | 23,71 USD |
| Total | 192,08 USD |
Implementación de este escenario
Desarrollo de Azure Functions
Una aplicación sin servidor en tiempo real compilada con Azure Functions y Azure SignalR Service normalmente necesita dos funciones de Azure:
- Una función
negotiatea la que el cliente llama para obtener un token de acceso válido de SignalR Service y la dirección URL del punto de conexión de servicio. - Una o varias funciones que envían mensajes o que administran la pertenencia al grupo.
SignalRFunctionApp
SignalRFunctionApp es una aplicación de funciones que crea una instancia de Azure Functions, con un desencadenador de Service Bus con SignalR.
Negotiate.cs
Esta función la desencadena una solicitud HTTP. La usan las aplicaciones cliente para obtener un token del servicio SignalR, que los clientes pueden usar para suscribirse a un centro de conectividad. Esta función se debe denominar negotiate. Para más información, vea Desarrollo y configuración de Azure Functions con Azure SignalR Service.
Message.cs
Esta función la desencadena un desencadenador de Service Bus. Tiene un enlace con el servicio SignalR. Extrae el mensaje de la cola y lo pasa a un centro de SignalR.
Instructions
Antes de empezar:
- Asegúrese de que tiene una cola de Service Bus aprovisionada en Azure.
- Asegúrese de que tiene un servicio SignalR aprovisionado en modo sin servidor en Azure.
- Escriba las cadenas de conexión (Service Bus y SignalR) en el local.settings.json.
- Escriba la URL de la aplicación cliente (cliente de SignalR) en CORS (Uso compartido de recursos entre orígenes). Para obtener la sintaxis más reciente, vea Desarrollo y configuración de Azure Functions con Azure SignalR Service.
- Escriba el nombre de la cola de Service Bus en el desencadenador de Service Bus en el archivo Message.cs.
Ahora se configurará la aplicación cliente para probarla. En primer lugar, obtenga los orígenes de ejemplo de la página de GitHub solution-architectures.
Cliente de SignalR
Es una sencilla aplicación web de .NET Core para suscribirse al centro de conectividad creado por SignalRFunctionApp. Muestra los mensajes que se reciben en la cola de Service Bus en tiempo real. Aunque puede usar SignalRFunctionApp para trabajar con un cliente para dispositivos móviles, para el repositorio de este escenario se ceñirá al cliente web.
Instrucciones
Asegúrese de que SignalRFunctionApp esté en ejecución.
Copie la dirección URL generada por la función negotiate. Es similar a
http://localhost:7071/api/.Pegue la dirección URL en el archivo chat.js, dentro de
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Ejecute la aplicación.
El estado es conectado cuando el cliente web se suscribe correctamente al centro de SignalR.
SendToQueue.js
Este script de Node.js envía un mensaje a Service Bus, para que pueda probar la implementación que acaba de realizar.
Instructions
Instale el módulo de Azure Service Bus del nodo (@azure/service-bus).
Escriba las cadenas de conexión y el nombre de la cola en el script.
Ejecute el script.
Pasos siguientes
Puede llevar este escenario al entorno de producción. Pero asegúrese de que los servicios de Azure están establecidos para escalarse. Por ejemplo, Azure Service Bus debe haberse configurado con un plan Estándar o Prémium.
Puede implementar el código en Azure Functions directamente desde Visual Studio. Para obtener información sobre cómo publicar el código en Azure Functions desde Visual Studio, siga la guía La forma de crear software.
Consulte cómo trabajar con enlaces de Azure Service Bus en Azure Functions. Azure Functions admite enlaces de desencadenador y salida para colas y temas de Service Bus.
Consulte cómo autenticar y enviar mensajes en tiempo real a clientes que estén conectados a Azure SignalR Service mediante enlaces de SignalR Service en Azure Functions. Azure Functions admite enlaces de entrada y salida para SignalR Service.