Esta página se aplica a Apigee y Apigee Hybrid.
Consulta la documentación de
Apigee Edge.
En este tema se ofrece una descripción general de la arquitectura del sistema de Apigee. Su objetivo es ayudarte a entender qué componentes se crean durante el aprovisionamiento y cuál es su finalidad en el sistema en general.
Apigee ofrece dos opciones de aprovisionamiento: con emparejamiento de VPC y sin emparejamiento de VPC. Ambas opciones se describen en las secciones que aparecen a continuación.
- Arquitectura con el emparejamiento de VPCs habilitado
- Arquitectura con el emparejamiento de VPCs inhabilitado
Arquitectura con el emparejamiento de VPC habilitado
En esta sección se describe la arquitectura del sistema de Apigee cuando Apigee se suministra con la opción de emparejamiento de VPC.
Descripción general del aprovisionamiento
Durante el aprovisionamiento, se configuran y se crean componentes que permiten la comunicación bidireccional entre una red de nube privada virtual (VPC) gestionada por ti y una red de VPC gestionada por Apigee. Una vez que haya completado los primeros pasos de aprovisionamiento, las dos VPCs existirán, pero aún no podrán comunicarse entre sí. Se necesita más configuración para permitir la comunicación bidireccional. Consulta la figura 1.
Para habilitar la comunicación entre VPCs, usamos el emparejamiento entre redes de VPC. El emparejamiento de redes permite la conectividad de direcciones IP internas entre dos redes de nube privada virtual (VPC), independientemente de si pertenecen al mismo proyecto o a la misma organización de Google Cloud. Una vez completado el paso de emparejamiento de redes, se podrá establecer comunicación entre las dos VPCs. Consulta la figura 2.
Para enrutar el tráfico de las aplicaciones cliente en Internet a Apigee, usamos un balanceador de carga HTTPS externo global (XLB). Un XLB puede comunicarse entre proyectos de Google Cloud, como entre el proyecto de Google Cloud del cliente y el proyecto de Google Cloud de Apigee, mediante la referencia de servicios entre proyectos.
También puedes aprovisionar un grupo de instancias gestionado (MIG) de máquinas virtuales que actúen como puente de red. Las VMs de MIG pueden comunicarse bidireccionalmente entre las redes emparejadas. Cuando se completa el aprovisionamiento, las aplicaciones de Internet se comunican con el XLB, el XLB se comunica con la VM puente y la VM puente se comunica con la red de Apigee. Consulta las figuras 3 y 4.
En esta configuración, el tráfico se enruta desde Apigee (por ejemplo, desde la política MessageLogging) a una carga de trabajo que se ejecuta en tu VPC interna. En este caso, la comunicación con tu VPC interna no pasa por una IP de NAT de salida. En su lugar, puede enrutar el tráfico a través de una de las IPs de la instancia de Apigee.
Ciclo de vida de las llamadas a proxies de API
En la siguiente ilustración se muestra el ciclo de vida de una llamada a un proxy de API a medida que se desplaza por los componentes del sistema Apigee aprovisionados (figura 5):
- Una aplicación cliente llama a un proxy de API de Apigee.
- La solicitud llega a un balanceador de carga HTTPS externo de nivel 7 (XLB) global. El XLB se configura con una IP externa o pública y un certificado TLS.
- El XLB envía la solicitud a una máquina virtual. La VM actúa como puente entre tu VPC y la VPC de Google (gestionada por Apigee).
- La VM envía la solicitud a Apigee, que procesa la solicitud del proxy de API.
- Apigee envía la solicitud al servicio backend y la respuesta se devuelve al cliente.
Arquitectura con el emparejamiento de VPC inhabilitado
En esta sección se describe la arquitectura del sistema de Apigee cuando no se aprovisiona con la opción de peer de VPC.
Durante el aprovisionamiento, se configuran y se crean componentes que permiten la comunicación bidireccional entre una red de nube privada virtual (VPC) gestionada por ti y una red de VPC gestionada por Apigee. Una vez que haya completado los primeros pasos de aprovisionamiento, las dos VPCs existirán, pero aún no podrán comunicarse entre sí. Se necesita más configuración para permitir la comunicación bidireccional. Consulta la figura 6.
Para habilitar la comunicación entre VPCs, usamos Private Service Connect (PSC) para enrutar el tráfico hacia Apigee y el tráfico hacia los servicios de destino que se ejecutan en tus proyectos de Google Cloud.
PSC permite establecer una conexión privada entre un productor de servicios (Apigee) y un consumidor de servicios (uno o varios proyectos de Cloud que controles). Con este método (figura 7), las solicitudes pasan por un balanceador de carga externo global o por un balanceador de carga externo regional hasta un único punto de conexión, llamado conexión de servicio.
Para conectar Apigee de forma privada a un destino backend, debes crear dos entidades: una vinculación de servicio en la red de VPC en la que se ha implementado el destino y una vinculación de endpoint en la VPC de Apigee. Estas dos entidades permiten que Apigee se conecte al servicio de destino. Consulta Patrones de red con límites.
Los pasos para aprovisionar Apigee con PSC (sin emparejamiento de VPC) se describen en Aprovisionamiento mediante línea de comandos sin emparejamiento de VPC.
