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 composición de API
Este patrón utiliza un redactor o agregador de API para implementar una consulta mediante la invocación de microservicios individuales que son propietarios de los datos. A continuación, combina los resultados realizando una unión en memoria.
El siguiente diagrama ilustra cómo se implementa este patrón.
En el diagrama, se muestra el siguiente flujo de trabajo:
-
Una puerta de enlace de API sirve a la API “Clientes”, que tiene un microservicio de “Orders” que rastrea los pedidos de los clientes en una base de datos de Aurora.
-
El microservicio «Support» rastrea los problemas de soporte al cliente y los almacena en una base de datos de Amazon OpenSearch Service.
-
El microservicio CustomerDetails "" mantiene los atributos del cliente (por ejemplo, dirección, número de teléfono o detalles de pago) en una tabla de DynamoDB.
-
La función Lambda «GetCustomer» ejecuta las API de estos microservicios y realiza una unión en memoria de los datos antes de devolverlos al solicitante. Esto ayuda a recuperar fácilmente la información del cliente en una llamada de red a la API orientada al usuario y hace que la interfaz sea muy sencilla.
El patrón de composición de la API ofrece la forma más sencilla de recopilar datos de varios microservicios. Sin embargo, el uso del patrón de composición de la API presenta las siguientes desventajas:
-
Puede que no sea adecuado para consultas complejas y conjuntos de datos grandes que requieren uniones en memoria.
-
Su sistema en general pierde disponibilidad si aumenta el número de microservicios conectados al redactor de API.
-
El aumento de las solicitudes a las bases de datos genera más tráfico de red, lo que aumenta los costos operativos.
