Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Patrón de puerta de enlace de la API
Se recomienda utilizar el patrón de puerta de enlace de la API si desea diseñar y crear aplicaciones complejas o grandes basadas en microservicios con varias aplicaciones cliente. El patrón es similar al patrón de fachada
El patrón proporciona un proxy inverso para redirigir o enrutar las solicitudes a los puntos de conexión de microservicios internos. Una puerta de enlace de API proporciona un único punto de conexión o URL para las aplicaciones cliente y asigna internamente las solicitudes a los microservicios internos. Se proporciona una capa de abstracción ocultando determinados detalles de la implementación (por ejemplo, el nombre y la versión de la función de Lambda), y también se puede añadir funcionalidad adicional sobre el servicio de backend, como las transformaciones de respuesta y solicitud, la autorización de acceso al punto de conexión o el rastreo.
Debería considerar la posibilidad de utilizar la puerta de enlace de API si:
-
El número de dependencias de un microservicio se puede administrar y no aumenta con el tiempo.
-
El sistema de llamadas requiere una respuesta sincrónica del microservicio.
-
Tiene requisitos de baja latencia.
-
Debe exponer una API para recopilar datos de varios microservicios.
Caso de uso
En este caso de uso, un cliente realiza pagos mensuales periódicos en un sistema de seguro que consta de cuatro microservicios implementados como funciones de Lambda (“Cliente”, “Comunicación”, “Pagos” y “Ventas”). El microservicio “Cliente” actualiza la base de datos de clientes con los detalles de los pagos mensuales. El microservicio “Ventas” actualiza la base de datos de ventas con información relevante que ayuda al equipo de ventas a hacer un seguimiento con el cliente de las oportunidades de venta cruzada. El microservicio “Comunicación” envía un correo electrónico de confirmación al cliente una vez que el pago se ha procesado correctamente. Por último, el microservicio “Pagos” es el sistema general que utiliza el cliente para realizar su pago mensual. El patrón utiliza servicios web para integrar los subsistemas “Cliente”, “Ventas” y “Comunicación” con el microservicio “Pagos”.
El uso de este patrón para este caso de uso presenta tres desafíos:
Las llamadas sincrónicas se realizan a los sistemas descendentes, lo que significa que cualquier latencia provocada por estos subsistemas afecta al tiempo de respuesta general.
Los costos de ejecución son más altos porque el sistema “Payments” espera las respuestas de los demás microservicios antes de responder al sistema de llamada. Por lo tanto, el tiempo total de ejecución es relativamente mayor en comparación con un sistema asincrónico.
La gestión de errores y los reintentos se gestionan por separado para cada microservicio del sistema “Pagos”, no por microservicios individuales.
En los dos ejemplos siguientes se describe cómo utilizar el patrón de puerta de enlace de la API para integrar los microservicios mediante varias puertas de enlace de la API o de una sola.
Varias puertas de enlace de la API
En la siguiente ilustración, cada microservicio tiene su propia puerta de enlace de la API. El microservicio “Pagos” identifica los sistemas individuales e implementa el patrón de puerta de enlace de la API.
Puerta de enlace única de API
En la siguiente ilustración, cada microservicio se implementa como una función de Lambda, pero todos los microservicios están conectados mediante la misma puerta de enlace de la API.
