Modelos de diseño de microservicios
El objetivo de los microservicios es aumentar la velocidad de las versiones de la aplicación, mediante la descomposición de la aplicación en servicios autónomos pequeños que se pueden implementar de forma independiente. Una arquitectura de microservicios también conlleva algunos desafíos. Los patrones de diseño que se muestran aquí pueden ayudar a mitigar estos desafíos.
Ambassador se puede usar para descargar tareas comunes de conectividad de cliente, como la supervisión, el registro, el enrutamiento y la seguridad (como TLS) de forma independiente del lenguaje. A menudo, los servicios ambassador se implementan como sidecar (consulte a continuación).
La capa contra daños implementa una fachada entre las aplicaciones nuevas y heredadas, para asegurarse de que el diseño de una nueva aplicación no está limitado por las dependencias de los sistemas heredados.
Los back-end para front-end crean servicios back-end independientes para distintos tipos de clientes, como escritorio y móvil. De este modo, un único servicio back-end no necesita controlar los requisitos en conflicto de varios tipos de cliente. Este patrón puede ayudar a simplificar cada microservicio, separando preocupaciones específicas del cliente.
Bulkhead aísla los recursos críticos, como el grupo de conexiones, la memoria y la CPU, para cada carga de trabajo o servicio. Mediante el uso de bulkheads, una sola carga de trabajo (o servicio) no puede consumir todos los recursos, lo que hace que otros se desanien. Este patrón aumenta la resistencia del sistema evitando errores en cascada causados por un servicio.
La agregación de puerta de enlace agrega solicitudes a varios microservicios individuales en una sola solicitud, lo que reduce la chattiidad entre los consumidores y los servicios.
La descarga de puerta de enlace permite que cada microservicio descargue la funcionalidad del servicio compartido, como el uso de certificados SSL, en una puerta de enlace de API.
El enrutamiento de puerta de enlace enruta las solicitudes a varios microservicios mediante un único punto de conexión, de modo que los consumidores no necesiten administrar muchos puntos de conexión independientes.
Messaging Bridge integra sistemas dispares creados con diferentes infraestructuras de mensajería.
Sidecar implementa componentes auxiliares de una aplicación como un contenedor o proceso independientes para proporcionar aislamiento y encapsulación.
Strangler Fig admite la refactorización incremental de una aplicación, reemplazando gradualmente partes específicas de funcionalidad por nuevos servicios.
Para obtener el catálogo completo de patrones de diseño en la nube en el Centro de arquitectura de Azure, consulte Patrones de diseño en la nube.
Pasos siguientes
- Entrenamiento: Descompone una aplicación monolítica en una arquitectura de microservicios
- ¿Qué son los microservicios?
- Por qué usar un enfoque de microservicios para compilar aplicaciones
- de arquitectura de microservicios de