Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este escenario, una empresa de comercio electrónico del sector de viajes migra una aplicación web heredada mediante Azure API Management. La empresa hospeda la nueva interfaz de usuario como una aplicación de plataforma como servicio (PaaS) en Azure. La nueva interfaz de usuario depende de las API HTTP existentes y nuevas. Estas API se implementan con interfaces diseñadas de forma más eficaz que mejoran el rendimiento, simplifican la integración y permiten la extensibilidad futura.
Architecture
Descargue un archivo de Visio de esta arquitectura.
Workflow
El siguiente flujo de trabajo corresponde al diagrama anterior:
La aplicación web local existente continúa consumiendo directamente los servicios web locales existentes.
Las llamadas desde la aplicación web existente a los servicios HTTP existentes permanecen sin cambios. Estas llamadas son internas en la red corporativa.
API Management realiza llamadas de Azure a los servicios internos existentes.
El equipo de seguridad permite que el tráfico de la instancia de API Management pase a través del firewall corporativo hacia los servicios locales existentes mediante protocolos de transporte seguros como Hypertext Transfer Protocol Secure (HTTPS) sobre TLS.
El equipo de operaciones solo permite las llamadas entrantes a los servicios desde la instancia de API Management. Cumple este requisito agregando la dirección IP de la instancia de API Management a la lista de permitidos dentro del perímetro de red corporativa.
Un nuevo módulo de la canalización de solicitudes local para los servicios del Protocolo de transferencia de hipertexto (HTTP) solo actúa en conexiones que se originan externamente. La canalización valida un certificado que proporciona API Management.
La nueva API tiene las siguientes características:
Solo la instancia de API Management, que proporciona la fachada de la API, expone la nueva API. Usted no accede directamente a la nueva API.
Desarrolle y publique la nueva API como una aplicación de API web paaS de Azure.
Configura la nueva API mediante la configuración de la característica Web Apps de Azure App Service para aceptar solo la dirección IP virtual (VIP) de API Management.
Web Apps hospeda la nueva API con protocolos de transporte seguros como HTTPS o TLS activados.
Azure App Service proporciona funcionalidades de autorización a través de Microsoft Entra ID y Open Authorization (OAuth) 2.
La nueva aplicación web basada en explorador depende de la instancia de API Management para la API HTTP existente y la nueva API.
La empresa de comercio electrónico de viajes puede dirigir a algunos usuarios a la nueva interfaz de usuario para la versión preliminar o las pruebas, a la vez que conserva la interfaz de usuario antigua y la funcionalidad existente en paralelo.
Configure la instancia de API Management para asignar los servicios HTTP heredados a un nuevo contrato de API. En esta configuración, la nueva interfaz de usuario web no es consciente de la integración con un conjunto de servicios o API heredados y nuevas API.
En el futuro, el equipo del proyecto puede mover gradualmente la funcionalidad a las nuevas API y retirar los servicios originales. El equipo controla estos cambios dentro de la configuración de API Management, dejando la interfaz de usuario de front-end sin verse afectada y evitando el trabajo de redesarrollo.
Components
API Management es una plataforma de administración y una puerta de enlace para las API en todos los entornos. En esta arquitectura, sirve como fachada para las API tanto heredadas como nuevas. La nueva aplicación de cliente utiliza una interfaz única y coherente, lo que permite al equipo modernizar de manera incremental los sistemas heredados detrás de esa interfaz, con un impacto mínimo en el desarrollo de front-end.
App Service es una solución PaaS llave en mano para el hospedaje web que proporciona características integradas como seguridad, equilibrio de carga, escalado automático y administración automatizada. En esta arquitectura, App Service proporciona hospedaje flexible llave en mano para que el equipo de DevOps pueda centrarse en la entrega de características.
Alternatives
Si la organización planea mover su infraestructura, incluidas las máquinas virtuales (VM) que hospedan las aplicaciones heredadas, por completo a Azure, API Management puede servir como fachada para cualquier punto de conexión HTTP direccionable.
Si la organización mantiene los puntos de conexión existentes privados y no los expone públicamente, la instancia de API Management de la organización puede vincularse a una red virtual de Azure.
Cuando API Management está vinculado a una red virtual de Azure, la organización puede dirigir directamente el servicio back-end a través de direcciones IP privadas.
En el escenario local, la instancia de API Management puede conectarse al servicio interno de forma privada a través de Azure VPN Gateway y una conexión VPN de protocolo de Internet (IPsec) de sitio a sitio o Azure ExpressRoute. A continuación, este escenario se convierte en un híbrido de Azure y local.
La organización puede mantener privada la instancia de API Management mediante su implementación en modo interno. Después, la organización puede usar la implementación con Azure Application Gateway para permitir el acceso público a algunas API, mientras que otras siguen siendo internas. Para más información, consulte Integración de API Management en una red virtual interna mediante Application Gateway.
La organización puede decidir hospedar sus API en el entorno local. Una razón para este cambio podría ser que la organización no puede mover las dependencias de base de datos de bajada que están en el ámbito de este proyecto a la nube. En este escenario, la organización puede aprovechar API Management localmente mediante una puerta de enlace autohospedada.
La puerta de enlace autohospedada es una implementación en contenedores de la puerta de enlace de API Management que se conecta a Azure en un socket de salida. Para usar puertas de enlace autoalojadas, debe cumplir los siguientes requisitos previos:
Debe implementar puertas de enlace autohospedadas mediante un recurso primario en Azure, lo que agrega un costo adicional.
Debe usar el nivel Premium de API Management.
Detalles del escenario
Una empresa de comercio electrónico en el sector de viajes quiere modernizar su pila de software heredada basada en exploradores. La pila existente es principalmente monolítica, pero algunos servicios HTTP basados en protocolo simple de acceso a objetos (SOAP) existen desde un proyecto reciente. La empresa considera la creación de flujos de ingresos adicionales para monetizar parte de su propiedad intelectual interna.
Los objetivos del proyecto incluyen abordar la deuda técnica, las mejoras continuas de mantenimiento y la aceleración del desarrollo de características con menos errores de regresión. El proyecto usa un proceso iterativo para evitar riesgos y realiza los pasos siguientes en paralelo:
El equipo de desarrollo moderniza el back-end de la aplicación, que consta de bases de datos relacionales hospedadas en máquinas virtuales.
El equipo de desarrollo interno escribe una nueva funcionalidad empresarial y la expone a través de nuevas API HTTP.
Un equipo de desarrollo de contratos crea una nueva interfaz de usuario basada en explorador, que hospeda Azure.
La empresa ofrece nuevas características de aplicación en fases. Estas características reemplazan gradualmente la funcionalidad de interfaz de usuario de servidor y cliente basada en explorador existente hospedada en el entorno local que impulsa el negocio de comercio electrónico de la empresa.
Los miembros del equipo de administración no quieren modernizar innecesariamente. También desean mantener el control del ámbito y los costos. Para lograr estos objetivos, deciden conservar sus servicios HTTP de SOAP existentes. También pretenden minimizar los cambios en la interfaz de usuario existente. Pueden usar API Management para abordar muchos de los requisitos y restricciones del proyecto.
Posibles casos de uso
En este escenario se resalta cómo modernizar las pilas de software heredadas basadas en navegador.
Puede usar este escenario para las siguientes tareas:
- Ver cómo su empresa puede beneficiarse del uso del ecosistema de Azure.
- Planee una migración de servicio a Azure.
- Obtenga información sobre cómo un cambio a Azure podría afectar a las API existentes.
Considerations
Estas consideraciones implementan los pilares de Azure Well-Architected Framework, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.
Reliability
La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
Active las zonas de disponibilidad al implementar la instancia de API Management. La opción de implementar API Management en zonas de disponibilidad solo está disponible en los niveles de servicio Premium.
Use zonas de disponibilidad que tengan instancias de puerta de enlace adicionales implementadas en regiones diferentes. Esta combinación mejora la disponibilidad del servicio si una región se queda sin conexión. La implementación de varias regiones solo está disponible en el nivel de servicio Premium.
Integración con Application Insights, que muestra las métricas a través de Azure Monitor para la supervisión. Por ejemplo, puede utilizar la métrica de capacidad para determinar la carga general en el recurso de API Management y evaluar si necesita más unidades de escalado horizontal. Realice un seguimiento de la capacidad y el estado de los recursos para mejorar la confiabilidad.
Asegúrese de que las dependencias aguas abajo, como los servicios back-end que hospedan las API que cubre API Management, también sean resilientes.
Optimización de costos
La optimización de costos se centra en 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.
API Management tiene ocho niveles:
- Consumo
- Desarrollador
- Básico y Básico v2
- Standard y Standard v2
- Premium y Premium v2
Para obtener más información sobre las diferencias en estos niveles, consulte Precios de API Management.
Puede escalar API Management agregando o quitando unidades. Cada unidad tiene una capacidad que depende de su nivel.
Note
Puede usar el nivel Desarrollador para evaluar las características de API Management. No lo use para producción.
Para ver los costos previstos para sus necesidades de implementación, puede modificar el número de unidades de escalado y las instancias de App Service en la calculadora de precios de Azure.
Contributors
Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.
Autor principal:
- Ben Gimblett | Ingeniero superior de clientes
Otro colaborador:
- Andrew Cardy | Ingeniero sénior de software
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Información general de App Service
- Introducción a API Management
- Configuración de entornos de ensayo en App Service
- Transformación y protección de la API
- Explora App Service