Esta página se aplica a Apigee y Apigee Hybrid.
Consulta la documentación de
Apigee Edge.
En este tema, se proporciona una descripción general de la arquitectura del sistema de Apigee. Está diseñada con el fin de ayudarte a comprender qué componentes se crean durante el aprovisionamiento y su propósito en el sistema general.
Apigee proporciona dos opciones para el aprovisionamiento: con intercambio de tráfico entre VPC y sin intercambio de tráfico entre VPC. Ambas opciones se describen en las siguientes secciones.
- Arquitectura con intercambio de tráfico entre VPC habilitado
- Arquitectura con intercambio de tráfico entre VPC inhabilitado
- Una app cliente llama a un proxy de API de Apigee.
- La solicitud llega a un balanceador de cargas de HTTPS externo (XLB) global L7. El XLB se configura con una IP pública y externa, y un certificado TLS.
- XLB envía la solicitud a una máquina virtual (VM). La VM funciona como un puente entre tu VPC y la VPC de Google (administrada 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 de backend y la respuesta se envía al cliente.
Arquitectura con intercambio de tráfico entre VPC habilitado
En esta sección, se describe la arquitectura del sistema de Apigee cuando Apigee se aprovisiona con la opción de intercambio de tráfico entre 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) administrada que administras y una red de VPC administrada por Apigee. Después de completar los primeros pasos de aprovisionamiento, las dos VPC existen, pero aún no pueden 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 las VPC, usamos el intercambio de tráfico entre redes de VPC. El intercambio de tráfico de red permite la conectividad de direcciones IP internas entre dos redes de nube privada virtual (VPC), sin importar si pertenecen al mismo proyecto o a la misma organización de Google Cloud. Después de completar el paso de intercambio de tráfico de red, es posible la comunicación entre las dos VPC. Consulta la Figura 2.
Para enrutar el tráfico de las aplicaciones cliente de Internet a Apigee, usamos un balanceador de cargas de HTTPS externo (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 con la referencia del servicio entre proyectos.
También puedes aprovisionar un grupo de instancias administrado (MIG) de máquinas virtuales (VM) que funcionen como un puente de red. Las VM de MIG tienen la capacidad de comunicarse bidireccionalmente en las redes con intercambio de tráfico. Cuando se completa el aprovisionamiento, las apps en Internet se comunican con la XLB, el XLB se comunica con la VM del puente y la VM del 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 a tu VPC interna no pasa por una IP de NAT de salida. En su lugar, puedes enrutar el tráfico a través de una de las IP de la instancia de Apigee.
Ciclo de vida de la llamada al proxy de API
En la siguiente ilustración, se muestra el ciclo de vida de una llamada al proxy de API cuando se mueve a través de los componentes del sistema de Apigee aprovisionados (Figura 5):
Arquitectura con intercambio de tráfico entre VPC inhabilitado
En esta sección, se describe la arquitectura del sistema de Apigee cuando Apigee no se aprovisiona con la opción de intercambio de tráfico entre VPC.
Durante el aprovisionamiento, se configuran y se crean componentes que permiten la comunicación bidireccional entre una red de nube privada virtual (VPC) administrada que administras y una red de VPC administrada por Apigee. Después de completar los primeros pasos de aprovisionamiento, las dos VPC existen, pero aún no pueden 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 las VPCs, usamos Private Service Connect (PSC) para enrutar el tráfico ascendente a Apigee y el tráfico descendente a los servicios de destino que se ejecutan en tus proyectos de Google Cloud.
PSC habilita la conexión privada entre un productor de servicios (Apigee) y un consumidor del servicio (uno o más proyectos de Cloud que tú controlas). Con este método (Figura 7), las solicitudes pasan a través de un balanceador de cargas externo global o un balanceador de cargas externo regional a un único punto de adjunto, llamado adjunto de servicio.
Para conectar Apigee de forma privada a un destino de backend, debes crear dos entidades: un adjunto de servicio en la red de VPC en la que se implementa el destino y un adjunto de extremo en la VPC de Apigee. Estas dos entidades permiten que Apigee se conecte al servicio de destino. Consulta Patrones de herramientas de redes descendentes.
Los pasos para aprovisionar Apigee con PSC (sin intercambio de tráfico de VPC) se describen en Aprovisionamiento de línea de comandos sin intercambio de tráfico entre VPC.
