Elección de si se usan mensajes o eventos
Imagine que está planeando la arquitectura de una aplicación distribuida para compartir música. Desea asegurarse de que la aplicación es tan confiable y escalable como sea posible y piensa utilizar tecnologías de Azure para crear una infraestructura de comunicación sólida.
Para poder elegir la tecnología de Azure adecuada, debe conocer todas las comunicaciones individuales que los componentes de la aplicación intercambian. Puede elegir una tecnología de Azure diferente para cada comunicación.
Lo primero que hay que saber sobre una comunicación es si envía mensajes o eventos. Se trata de una opción fundamental que le ayuda a elegir el servicio de Azure más adecuado.
Estrategias de comunicación de Azure (API)
¿Qué es un mensaje?
En la terminología de las aplicaciones distribuidas, los mensajes tienen las siguientes características:
- Un mensaje contiene datos sin procesar producidos por un componente y consumidos por otro.
- Un mensaje contiene los datos, no solo una referencia a esos datos.
- El componente de envío espera que el componente de destino procese el contenido del mensaje de una forma determinada. La integridad del sistema global puede depender de que el remitente y receptor realicen un trabajo específico.
Por ejemplo, supongamos que un usuario carga una canción nueva con la aplicación móvil para compartir música. La aplicación móvil debe enviar dicha canción a la API web que se ejecuta en Azure. Se debe enviar el archivo multimedia de la canción, no solo una alerta que indique que se ha agregado una canción nueva. La aplicación móvil espera que la API web almacene la canción nueva en la base de datos y que la ponga a disposición de otros usuarios. Este es un ejemplo de un mensaje.
¿Qué es un evento?
Los eventos pesan algo menos que los mensajes y son los que se usan con más frecuencia para difundir comunicaciones. Los componentes que envían el evento se llaman publicadores y los destinatarios se conocen como suscriptores.
Con los eventos, los componentes destinatarios deciden qué comunicaciones les interesan y se "suscriben" a dichos eventos. La suscripción la administra un intermediario, como Azure Event Grid o Azure Event Hubs. Cuando los publicadores envían un evento, el intermediario lo enruta a los suscriptores interesados. Este patrón se conoce como una "arquitectura de publicación-suscripción". No es la única manera de tratar los eventos, pero sí la más común.
Los eventos tienen las siguientes características:
- Un evento es una notificación ligera que indica que algo ha sucedido.
- 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.
- Algunos eventos son unidades discretas y no están relacionados con otros eventos.
- Algunos eventos forman parte de una serie ordenada y relacionada.
Por ejemplo, supongamos que se ha completado la carga del archivo de música y que se ha agregado la nueva canción a la base de datos. Para informar a los usuarios del nuevo archivo, la API web debe informar de la aplicación móvil y el front-end a los usuarios del nuevo archivo. Los usuarios pueden optar por escuchar la canción nueva, por lo que la notificación inicial no incluye el archivo de música, sino que solo notifica a los usuarios que la canción está disponible. El remitente no tiene ninguna expectativa específica de que los destinatarios del evento hagan algo en particular como respuesta a este evento.
Este escenario es un ejemplo de un evento discreto.
Elección de mensajes o eventos
Es probable que una única aplicación use eventos para algunos propósitos y mensajes para otros. Antes de elegir, debe analizar la arquitectura de la aplicación y todos sus casos de uso para identificar las distintas finalidades que sus componentes tienen para comunicarse entre sí.
Es más probable que los eventos se utilicen para las difusiones y suelen ser efímeros. Esto significa que es posible que ningún destinatario controle una comunicación si no hay ningún suscriptor actualmente. Es más probable que los mensajes se usen si la aplicación distribuida requiere una garantía de que se procese la comunicación.
En cada comunicación, plantéese esta pregunta: ¿el componente de envío espera que el componente de destino procese la comunicación de una forma determinada?
Si la respuesta es sí, opte por usar un mensaje. Si la respuesta es no, es posible que pueda utilizar los eventos.
Entender la manera en que los componentes necesitan comunicarse le ayuda a elegir cómo se comunican sus componentes. Comencemos con los mensajes.