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. Algunos ejemplos de uso de este escenario son el seguimiento en tiempo real de productos y mercancías, o algunas soluciones de redes sociales.
En este escenario, examinaremos 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 para compartir la ubicación en tiempo real para sus aplicaciones web o para dispositivos móviles.
Usaremos el servicio SignalR configurado en modo sin servidor para integrarlo en una aplicación de Azure Functions desencadenada por Service Bus, y todo ello usando .NET Core.
Posibles casos de uso
Estos otros casos de usos tienen patrones de diseño similares:
- Compartir ubicación en tiempo real con dispositivos cliente.
- Enviar notificaciones push a usuarios.
- Actualizar escalas de tiempo.
- Crear salas de chat.
Architecture
Componentes
- Service Bus, que es un servicio de mensajería en la nube entre aplicaciones y servicios muy confiable, incluso cuando uno o varios de esos servicios o aplicaciones estén sin conexión.
- SignalR facilita la incorporación de comunicaciones en tiempo real a una aplicación web.
- Azure Functions,que es una plataforma de procesos sin servidor basada en eventos que también puede solucionar problemas de orquestación complejos.
Consideraciones
Estas son algunas de las consideraciones que se han tenido en cuenta para desarrollar este escenario, entre las que se incluye la forma de configurar parámetros en la cadena de conexiones de Azure Service Bus en ServiceBusTrigger, así como:
Centros: los centros se pueden comparar con un servicio de streaming de vídeo. Puede suscribirse al centro para enviar mensajes desde el centro o recibirlos de él.
Destinos: los destinos son como emisoras de radio. 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
Para lograr una alta disponibilidad de esta solución, siga estos pasos:
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.
- Sin embargo, asegúrese de que ambas 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
Azure Front Door es un punto de entrada escalable y seguro para la entrega rápida de aplicaciones globales. Mediante 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 su servicio mediante conjuntos de reglas administradas de Microsoft y cree sus propias reglas para dotar a su 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. Consulte el contrato de nivel de servicio de Front Door y determine si el uso de Front Door por sí solo cumple sus 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. Este paso debe realizarse manualmente, y la aplicación dejará de estar disponible hasta que se propaguen los cambios de DNS.
Precios de este escenario
Supongamos que su empresa recibe 1000 pedidos al día y necesita compartir los datos de ubicación con todos ellos simultáneamente, el uso estimado de Azure para implementar este escenario se aproximará a los 192 USD mensuales, según los precios vigentes en el momento en que se ha escrito este documento.
| 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 en tiempo real sin servidor creada con Azure Functions y Azure SignalR Service normalmente requiere dos funciones de Azure:
- Una función "negotiate" a 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
Se trata de una aplicación de funciones que crea una instancia de Azure Functions con el 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. Debería asignarle el nombre "negotiate". Para más información, lea esta guía
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
- 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 archivo local.settings.json.
- Escriba la dirección URL de la aplicación cliente (cliente de SignalR) en CORS. En esta guía se proporciona la sintaxis más reciente.
- Escriba el nombre de la cola de Service Bus en el desencadenador de Service Bus del archivo Message.cs.
Ahora, vamos a configurar la aplicación cliente para realizar la prueba. En primer lugar, tome los orígenes de ejemplo de aquí
Cliente de SignalR
Esta es una aplicación web sencilla en .NET Core para suscribirse al centro creado por SignalRFunctionApp y mostrar los mensajes recibidos en la cola de Service Bus en tiempo real. Aunque puede usar SignalRFunctionApp para trabajar con un cliente para dispositivos móviles, pero para este repositorio nos ceñiremos al cliente web.
Instrucciones
- Asegúrese de que SignalRFunctionApp se ejecuta primero.
- Copie la dirección URL generada por la función Negotiate. Se parecerá a esta
http://localhost:7071/api/ - Pegue la dirección URL en chat.js dentro de
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build(); - Ejecute la aplicación.
- Verá el estado conectado cuando el cliente web se suscribe correctamente al centro de SignalR.
SendToQueue.js
Se trata de un script de Node.js para enviar un mensaje a Service Bus para que pueda probar la implementación que realizó anteriormente.
Instructions
- Instale el módulo 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
Este escenario se puede adoptar en el entorno de producción; sin embargo, asegúrese de que los servicios de Azure estén configurados 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. Siga esta guía para aprender a publicar el código en Azure Functions desde Visual Studio.
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 que los desarrolladores de aplicaciones creen 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.
Es indudable que tanto Pusher como PubNub son plataformas muy utilizadas para la mensajería en tiempo real, pero para este escenario todas las operaciones se realizarán en Azure. SignalR 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.
Este es un vínculo al repositorio de código abierto de SignalR en GitHub.
Recursos relacionados
En este artículo se explica 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.
En este artículo se explica cómo autenticar y enviar mensajes en tiempo real a los clientes conectados a Azure SignalR Service mediante enlaces de SignalR Service en Azure Functions. Azure Functions admite enlaces de entrada y salida para SignalR Service.