Según el sitio web de Microsoft Azure, Azure Service Bus es un sistema genérico de mensajería basado en la nube para conectar casi cualquier cosa, aplicaciones, servicios y dispositivos, donde sea que se encuentren. Dado que es un tipo de sistema de mensajería, se utiliza mejor con sistemas / arquitectura de varios niveles; La arquitectura de múltiples niveles aquí no se limita al sentido clásico donde la separación es principalmente lógica, sino también muy útil donde la separación también es física. Por lo tanto, también es muy útil para que su sistema sea fácilmente escalable. (Nota: para obtener descripciones extensas de funcionalidades, consulte el sitio web de Microsoft Azure).
Por ejemplo, supongamos que tiene una aplicación de varios niveles con UI móvil y basada en web, y una base de datos. La arquitectura habitual de acceso sería: capa de interfaz de usuario (aplicación móvil y aplicación web) – Capa de servicio / API – [Capa de acceso a datos] – Base de datos.
Si implementa su sistema localmente en 1 región, por ejemplo, Australia del Este, entonces es bastante sencillo. Ahora, supongamos que tiene una base de usuarios cada vez mayor y, después de un análisis más detallado, puede dividir los orígenes de sus usuarios en Oceanía y Europa. Para brindar un mejor rendimiento, es mejor implementar su sistema en los centros de datos de Europa y Australia Oriental. Sin embargo, ahora tiene un problema de coherencia entre las bases de datos. Sí, puede confiar en la función de replicación de SQL Server (o de la base de datos de su base de datos), sin embargo, puede ser costoso; por lo general, debe usar la versión de extremo superior de SQL Server y los costos de transporte, por nombrar algunos.
El bus de servicio puede ser de gran ayuda aquí. Si coloca Service Bus + Worker Role entre la capa Service / API y las capas Data-access / Database; entonces, en lugar de actualizar directamente la base de datos, la información se pasa en el bus de servicio. Y el rol de trabajador buscará el mensaje de la cola y actualizará los datos de la base de datos de esa región (por ejemplo, Europa), así como empujará ese mismo mensaje al bus de servicio en la otra región (por ejemplo, Australia del Este), de los cuales el trabajador El rol en esa región buscará ese mensaje y actualizará la base de datos de la región de Australia Oriental.
Luego puede extender la escalabilidad a múltiples instancias de Servicio / API, así como a la capa de acceso a datos / base de datos sin preocuparse mucho por la configuración de equilibrio de carga. Si es necesario, incluso puede implementar varias instancias del bus de servicio de las cuales el rol de trabajador buscará en cada canal los mensajes recibidos. Arquitectura similar es utilizada por la tienda / tienda en línea de Amazon.
Otro ejemplo de implementación es donde desea transmitir información entre la implementación local y la implementación de su sistema basada en la nube; o como centro de notificaciones para sus dispositivos móviles (teléfono, mesas, etc.).
- ¿Qué es la computación de no repudio?
- ¿Es una buena idea alojar una aplicación en AWS si se dirige a usuarios chinos?
- ¿Qué servicios de AWS debe aprender un desarrollador senior de Java?
- ¿Hay alguien que esté interesado en ayudar y ser parte de mis ideas para dos nuevas empresas?
- ¿La automatización afectará los trabajos de Amazon Web Services (AWS)?
Puede encontrar más ejemplos y tutoriales en los sitios web de Microsoft Azure y en Microsoft Virtual Academy.
Espero que esto ayude.
