Esta arquitectura de referencia usa Azure Integration Services para orquestar las llamadas a los sistemas de back-end empresariales. Los sistemas de back-end pueden incluir sistemas de software como servicio (SaaS), servicios de Azure y servicios web existentes de su empresa.
Architecture
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
Application. La aplicación es un cliente que llama a la puerta de enlace de API después de autenticarse con Microsoft Entra. La aplicación puede ser una aplicación web, una aplicación móvil o cualquier otro cliente que pueda realizar solicitudes HTTP.
Microsoft Entra ID. Se usa para autenticar la aplicación cliente. La aplicación cliente obtiene un token de acceso de Microsoft Entra ID e lo incluye en la solicitud a la puerta de enlace de API.
Azure API Management. API Management consta de dos componentes relacionados:
Puerta de enlace de API. La puerta de enlace de API acepta una llamada HTTP desde la aplicación cliente, valida el token de Microsoft Entra ID y reenvía la solicitud al servicio back-end. La puerta de enlace de API también puede transformar solicitudes y respuestas, y almacenar en caché las respuestas.
Portal para desarrolladores. Los desarrolladores usan la del portal para desarrolladores de
para detectar e interactuar con las API. El portal para desarrolladores se puede personalizar para que coincida con la personalización de marca de la organización.
Azure Logic Apps. Las aplicaciones lógicas se usan para organizar las llamadas a los servicios back-end. Las aplicaciones lógicas se pueden desencadenar mediante una variedad de eventos y pueden llamar a una variedad de servicios. En esta solución, Logic Apps se usa para llamar a los servicios back-end y proporcionar una conectividad sencilla a través de conectores de reducir la necesidad de código personalizado.
servicios back-end. Los servicios back-end pueden ser cualquier servicio o aplicación de línea de negocio, como una base de datos, un servicio web o una aplicación SaaS. Los servicios back-end se pueden hospedar en Azure o en el entorno local.
Componentes
-
Integration Services es una colección de servicios que puede usar para integrar aplicaciones, datos y procesos. En esta solución, se usan dos de estos servicios: Logic Apps y API Management. Logic Apps se usa para facilitar la integración basada en mensajes entre sistemas y facilitar la conectividad con conectores. API Management se usa para proporcionar una fachada para los servicios back-end, lo que permite una interfaz coherente con la que los clientes interactúan.
- Logic Apps es una plataforma sin servidor para la creación de flujos de trabajo empresariales que integran aplicaciones, datos y servicios. En esta solución, Logic Apps se usa para orquestar las llamadas a los servicios back-end y proporcionar una conectividad sencilla a través de conectores que reducen la necesidad de código personalizado.
- API Management es un servicio administrado para la publicación de catálogos de API de HTTP. Puede usarla para promover la reutilización y la detectabilidad de las API e implementar una puerta de enlace de API para solicitudes de API de proxy. En esta solución, API Management proporciona funcionalidades adicionales, como la limitación de velocidad, la autenticación y el almacenamiento en caché en los servicios back-end. Además, API Management proporciona un portal para desarrolladores para que los clientes detecten e interactúen con las API.
- Azure DNS es un servicio de hospedaje para dominios DNS. Azure DNS hospeda los registros DNS públicos para el servicio API Management. Esto permite a los clientes resolver el nombre DNS en la dirección IP del servicio API Management.
- Microsoft Entra ID es un servicio de administración de identidades y accesos basado en la nube. Los empleados de la empresa pueden utilizar Microsoft Entra ID para acceder a recursos internos y externos. Aquí entra ID se usa para proteger el servicio API Management mediante OAuth 2.0 y el portal para desarrolladores mediante Entra B2C.
Detalles del escenario
Integration Services es una colección de servicios que puede usar para integrar aplicaciones, datos y procesos en la empresa. Esta arquitectura emplea dos de esos servicios: Logic Apps para orquestar los flujos de trabajo, y API Management para crear catálogos de API.
En esta arquitectura, se crean API compuestas mediante la importando de aplicaciones lógicas como API. También se pueden importar servicios web existentes mediante la importación de especificaciones de OpenAPI (Swagger) o la importación de API SOAP a partir de especificaciones WSDL.
La puerta de enlace de API ayuda a desacoplar los clientes de front-end del back-end. Por ejemplo, puede reescribir las direcciones URL o transformar las solicitudes antes de que lleguen al back-end. También controla muchos aspectos transversales como la autenticación, la compatibilidad con uso compartido de recursos entre orígenes (CORS) y el almacenamiento en caché de respuestas.
Posibles casos de uso
Esta arquitectura es suficiente para los escenarios de integración básica en los que las llamadas sincrónicas a servicios back-end desencadenan el flujo de trabajo. Una arquitectura más sofisticada que usa colas y eventos se basa en esta arquitectura básica.
Recomendaciones
Los requisitos específicos pueden diferir de la arquitectura genérica que se describe aquí. Use las recomendaciones de esta sección como punto de partida.
API Management
Use los niveles Básico, Estándar o Premium de API Management. Estos niveles ofrecen un acuerdo de nivel de servicio (SLA) de producción y admiten el escalado horizontal dentro de la región de Azure. La capacidad de rendimiento de API Management se mide en unidades. Cada plan de tarifa tiene un escalado horizontal máximo. El nivel Premium también admite el escalado horizontal en varias regiones de Azure. Elija su nivel en función de su conjunto de características y el nivel de rendimiento necesario. Para más información, consulte Precios de API Management y Capacidad de una instancia de Azure API Management.
No se recomienda el nivel consumo de API Management para esta solución porque no es compatible con el portal para desarrolladores que es necesario para esta arquitectura. El nivel de desarrollador está específicamente para entornos que no son de producción y no se recomienda para cargas de trabajo de producción. Puede encontrar una matriz de características que detalla las diferencias entre los niveles aquí.
Cada instancia de Azure API Management tiene un nombre de dominio predeterminado, que es un subdominio de azure-api.net, por ejemplo, contoso.azure-api.net. Considere la posibilidad de configurar un dominio personalizado para su organización.
Logic Apps
Logic Apps funciona mejor en escenarios que no requieren baja latencia para una respuesta, como por ejemplo las llamadas a API asincrónicas o de ejecución semiprolongada. Si se requiere una latencia baja, por ejemplo en una llamada que bloquea una interfaz de usuario, use otra tecnología. Por ejemplo, use Azure Functions o una API web implementada en Azure App Service. Use API Management para enfrentar la API a los consumidores de API.
Region
Para minimizar la latencia de red, coloque API Management y Logic Apps en la misma región. En general, elija la región más cercana a los usuarios (o más cercana a los servicios de back-end).
Consideraciones
Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Confiabilidad
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, vea Lista de comprobación de revisión de diseño para lade confiabilidad.
Revise los Acuerdos de Nivel de Servicio para cada servicio aquí
Si implementa API Management en dos o más regiones con el nivel Premium, es apto para un Acuerdo de Nivel de Servicio superior. Consulte Precios de API Management.
Copias de seguridad
Realice una copia de seguridad periódica de la configuración de API Management. Almacene los archivos de copia de seguridad en una ubicación o región de Azure diferente de la región donde se implementa el servicio. En función de su RTO, elija una estrategia de recuperación ante desastres:
En un evento de recuperación ante desastres, aprovisione una nueva instancia de API Management, restaure la copia de seguridad en la instancia nueva y redirija los registros DNS.
Mantenga una instancia pasiva del servicio API Management en otra región de Azure. Restaure con regularidad las copias de seguridad a esa instancia para mantenerlas sincronizadas con el servicio activo. Para restaurar el servicio durante un evento de recuperación ante desastres, solo es necesario redirigir los registros DNS. Este enfoque conlleva costos adicionales, ya que se paga por la instancia pasiva, pero se reduce el tiempo de recuperación.
Para las aplicaciones lógicas, se recomienda un enfoque de configuración como código para la copia de seguridad y la restauración. Dado que las aplicaciones lógicas son sin servidor, puede volver a crearlas rápidamente a partir de plantillas de Azure Resource Manager. Guarde las plantillas en el control de código fuente e integre las plantillas con el proceso de implementación continua e integración continua (CI/CD). En un evento de recuperación ante desastres, implemente la plantilla en una nueva región.
Si implementa una aplicación lógica en una región diferente, actualice la configuración en API Management. Puede actualizar la propiedad Backend de la API mediante un script de PowerShell básico.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, vea Lista de comprobación de revisión de diseño para security.
Aunque esta lista no describe completamente todos los procedimientos recomendados de seguridad, estas son algunas consideraciones de seguridad que se aplican específicamente a esta arquitectura:
El servicio Azure API Management tiene una dirección IP pública fija. Restrinja el acceso para llamar a los puntos de conexión de Logic Apps a solo la dirección IP de API Management. Para obtener más información, vea Restricción de las direcciones IP entrantes.
Para asegurarse de que los usuarios tienen niveles de acceso adecuados, utilice el control de acceso basado en roles de Azure (Azure RBAC).
Proteja los puntos de conexión de API públicos en API Management con OAuth o bien OpenID Connect. Para proteger los puntos de conexión de API públicos, configure un proveedor de identidades y agregue una directiva de validación de JSON Web Token (JWT). Para obtener más información, consulte Proteger una API mediante OAuth 2.0 con Microsoft Entra ID y API Management.
Conéctese a servicios back-end desde API Management mediante certificados mutuos.
Exija HTTPS en las API de API Management.
Almacenamiento de secretos
Nunca compruebe contraseñas, claves de acceso ni cadenas de conexión en el control de código fuente. Si estos valores son necesarios, protéjalos e impleméntelos mediante las técnicas oportunas.
Si una aplicación lógica funciona con datos confidenciales, consulte Protección del acceso y los datos para flujos de trabajo en Azure Logic Apps para obtener instrucciones detalladas.
API Management administra los secretos con objetos denominados valores con nombre o propiedades. Estos objetos almacenan de forma segura los valores a los que se puede acceder a través de directivas de API Management. Para más información, consulte Cómo usar valores con nombre en las directivas de Azure API Management.
Optimización de costos
La optimización de costos consiste en examinar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.
En general, use la calculadora de precios de Azure para calcular los costos. Estas son algunas otras consideraciones.
API Management
Se le cobra por todas las instancias de API Management cuando están en ejecución. Si ha escalado verticalmente y no necesita ese nivel de rendimiento todo el tiempo, reduzca verticalmente de forma manual o configure la escalabilidad automática.
Logic Apps
Logic Apps usa un modelo sin servidor. La facturación se calcula en función de la acción y la ejecución del conector. Para obtener más información, consulte Precios de Logic Apps.
Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.
Excelencia operativa
La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, vea Lista de comprobación de revisión de diseño para la excelencia operativa.
DevOps
Cree grupos de recursos independientes para entornos de producción, desarrollo y pruebas. Los grupos de recursos independientes facilitan la administración de implementaciones, la eliminación de implementaciones de prueba y la asignación de derechos de acceso.
Cuando asigna recursos a los grupos de recursos, debe considerar estos factores:
Ciclo de vida. En general, coloque los recursos que tienen el mismo ciclo de vida en el mismo grupo de recursos.
Acceso. Puede usar el control de acceso basado en roles de Azure (Azure RBAC) para aplicar directivas de acceso a los recursos de un grupo.
Facturación. Puede ver los costos acumulados del grupo de recursos.
Plan de tarifa de API Management. Use el nivel Desarrollador para los entornos de desarrollo y pruebas. Para minimizar los costos durante la preproducción, implemente una réplica del entorno de producción, ejecute las pruebas y, a continuación, apáguela.
Implementación
Use plantillas de Azure Resource Manager para implementar los recursos de Azure, según el proceso de infraestructura como código (IaC). Las plantillas facilitan la automatización de las implementaciones mediante Azure DevOps Services u otras soluciones de CI/CD.
Ensayo
Considere el almacenamiento provisional de las cargas de trabajo, lo que significa realizar las implementaciones en varias fases y ejecutar validaciones en cada una de ellas antes de pasar a la siguiente. Si aplica este enfoque, puede enviar actualizaciones a los entornos de producción de una manera muy controlada y minimizar los problemas de implementación imprevistos. La implementación azul-verde y las versiones de valores controlados son estrategias de implementación recomendadas para actualizar entornos de producción en directo. Considere también la posibilidad de tener una buena estrategia de reversión en caso de que se produzca un error en una implementación. Por ejemplo, puede volver a implementar automáticamente una implementación anterior exitosa desde el historial de implementación. El parámetro de marca --rollback-on-error en la CLI de Azure es un buen ejemplo.
Aislamiento de cargas de trabajo
Coloque las instancias de Azure API Management y cualquier aplicación lógica individual en sus propias plantillas independientes de Resource Manager. Mediante el uso de plantillas independientes, puede almacenar los recursos en sistemas de control de código fuente. Puede implementar las plantillas en conjunto o por separado como parte de un proceso de CI/CD.
Versiones
Cada vez que realiza un cambio en la configuración de una aplicación lógica o implementa una actualización con una plantilla de Resource Manager, Azure guarda una copia de dicha versión y mantiene todas las versiones que tengan un historial de ejecución. Puede usar estas versiones para hacer el seguimiento de los cambios históricos o promover una versión como configuración actual de la aplicación lógica. Por ejemplo, puede revertir una aplicación lógica a una versión anterior.
Azure API Management admite dos conceptos de control de versiones distintos, pero complementarios:
Las versiones permiten a los consumidores de API elegir una versión de API en función de sus necesidades, por ejemplo, v1, v2, beta o producción.
Las revisiones permiten a los administradores de API realizar cambios no importantes en una API e implementar esos cambios, junto con un registro de los cambios para informar a los consumidores de API sobre ellos.
Puede crear una revisión en el entorno de desarrollo e implementar ese cambio entre otros entornos con el uso de plantillas de Resource Manager. Para obtener más información, vea Publicación de varias versiones de la API
También puede usar las revisiones para probar una API antes de realizar los cambios actuales y permitir que los usuarios puedan acceder a ella. Sin embargo, este método no se recomienda para pruebas de carga o pruebas de integración. En su lugar, use entornos de prueba o preproducción independientes.
Diagnóstico y supervisión
Puede usar Azure Monitor para la supervisión operativa tanto en API Management como en Logic Apps. Azure Monitor proporciona información según las métricas que se configuran para cada servicio y está habilitado de manera predeterminada. Para más información, consulte:
- Supervisión de las API publicadas
- Supervisar el estado, configurar el registro de diagnósticos y activar alertas para Azure Logic Apps
Cada servicio también tiene estas opciones:
Para realizar análisis más exhaustivos y agregarlos a los paneles, envíe registros de Logic Apps a Azure Log Analytics.
Para la supervisión de DevOps, puede configurar Azure Application Insights para API Management.
API Management admite la plantilla de solución de Power BI para análisis de API personalizados. Puede usar esta plantilla de solución para crear su propia solución de análisis. Los informes están disponibles en Power BI para los usuarios empresariales.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar a fin de satisfacer las demandas que los usuarios ponen en ella de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
Para aumentar la escalabilidad de API Management, agregue directivas de almacenamiento en caché donde corresponda. El almacenamiento en caché también ayuda a reducir la carga de sus servicios back-end.
Para ofrecer mayor capacidad, puede escalar horizontalmente los niveles Básico, Estándar y Premium de Azure API Management en una región de Azure. Para analizar el uso del servicio, en el menú Métricas, seleccione Métrica de capacidad y, luego, escale verticalmente u horizontalmente según corresponda. El proceso de actualización o escalado puede tardar entre 15 y 45 minutos en aplicarse.
Recomendaciones de escalado de un servicio API Management:
Considere los patrones de tráfico al escalar. Los clientes con patrones de tráfico más volátiles necesitan más capacidad.
Una capacidad coherente superior al 66 % puede indicar la necesidad de escalar verticalmente.
Una capacidad coherente inferior al 20 % puede indicar una oportunidad para reducir verticalmente.
Antes de habilitar la carga en producción, realice siempre una prueba de carga del servicio API Management con una carga representativa.
Con el nivel Premium, puede escalar una instancia de API Management entre varias regiones de Azure. Esto hace que API Management sea apto para un Acuerdo de Nivel de Servicio superior y le permite aprovisionar servicios cercanos a los usuarios en varias regiones.
El modelo sin servidor de Logic Apps significa que no es necesario que los administradores planifiquen la escalabilidad del servicio. El servicio se escala automáticamente para satisfacer la demanda.
Pasos siguientes
Recursos relacionados
Para obtener mayor confiabilidad y escalabilidad, utilice colas de mensajes y eventos para desacoplar los sistemas de back-end. Esta arquitectura se muestra en el siguiente artículo de esta serie:
También pueden interesarle estos artículos del Centro de arquitectura de Azure: