Panoramica dell'architettura Apigee

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

Questo argomento fornisce una panoramica dell'architettura di sistema di Apigee. È destinato per aiutarti a capire quali componenti vengono creati provisioning e relativi uno scopo nel sistema generale.

Apigee offre due opzioni per il provisioning: con il peering VPC e senza peering VPC. Entrambi sono descritte nelle sezioni seguenti.

  • Architettura con peering VPC abilitato
  • Architettura con peering VPC disabilitato

    • Architettura con peering VPC abilitato

    Questa sezione descrive l'architettura del sistema Apigee quando viene eseguito il provisioning di Apigee con l'opzione peering VPC.

    Panoramica del provisioning

    Durante il provisioning, vengono configurati e creati componenti in modo da consentire la comunicazione tra una rete cloud privato (VPC) gestita da te e una rete VPC gestita da Apigee. Dopo aver completato i primi passaggi di provisioning, i due VPC esistono, ma non possono comunicare tra loro. È necessaria un'ulteriore configurazione per consentire comunicazione. Vedi la Figura 1.

    Figura 1: il tuo VPC e il VPC di Apigee non possono comunicare tra loro senza ulteriore configurazione.

    Per abilitare la comunicazione tra i VPC, utilizziamo VPC peering di rete. Il peering di rete consente la connettività di indirizzi IP interni tra due Reti Virtual Private Cloud (VPC) a prescindere dalla loro appartenenza allo stesso progetto o alla stessa organizzazione Google Cloud. Una volta completato il passaggio di peering di rete, è possibile tra i due VPC. Vedi la Figura 2.

    Figura 2: il peering di rete VPC consente la comunicazione tra i VPC.

    Per indirizzare il traffico dalle app client su internet ad Apigee, utilizziamo un protocollo HTTPS esterno globale il bilanciatore del carico più rapido (XLB). Un XLB può comunicare tra progetti Google Cloud, ad esempio tra il progetto Google Cloud del cliente e il progetto Apigee Google Cloud, riferimenti di servizi tra progetti.

    Puoi anche eseguire il provisioning gruppo di istanze gestite (MIG) di macchine virtuali (VM) che fungono da bridge di rete. Le VM MIG hanno la capacità di comunicare in modo bidirezionale tra le reti in peering. Quando il provisioning sia completato, le app su Internet comunicano con la XLB, la XLB comunica la VM bridge, quindi la VM bridge comunica con la rete Apigee. Vedi Figura 3 e Figura 4.

    Figura 3: le VM gestite consentono il passaggio di richieste e risposte tra i dispositivi in peering reti.

    In questa configurazione, il traffico viene instradato da Apigee (ad esempio, dal criterio MessageLogging) a un carico di lavoro in esecuzione nel tuo VPC interno. In questo caso, la comunicazione con il VPC interno non passano attraverso un IP NAT del traffico in uscita. Puoi invece instradare il traffico attraverso una delle IP delle istanze Apigee.

    Figura 4: traffico instradato privatamente a un carico di lavoro nel VPC interno.

    Ciclo di vita della chiamata proxy API

    L'illustrazione seguente mostra il ciclo di vita di una chiamata proxy API mentre si sposta attraverso componenti di sistema Apigee di cui è stato eseguito il provisioning (Figura 5):

    Figura 5: traffico instradato privatamente a un carico di lavoro nel VPC interno.
    1. Un'app client chiama un proxy API Apigee.
    2. La richiesta arriva su un bilanciatore del carico HTTPS (XLB) esterno L7 globale. XLB è configurato con un IP esterno/pubblico e un certificato TLS.
    3. Il XLB invia la richiesta a una macchina virtuale (VM). La VM funge da bridge tra e il VPC di Google (gestito da Apigee).
    4. La VM invia la richiesta ad Apigee, che elabora la richiesta di proxy API.
    5. Apigee invia la richiesta al servizio di backend e la risposta viene inviata al servizio di alto profilo.

    Architettura con peering VPC disabilitato

    Questa sezione descrive l'architettura del sistema Apigee quando non viene eseguito il provisioning di Apigee l'opzione peering VPC.

    Durante il provisioning, vengono configurati e creati componenti in modo da consentire la comunicazione tra una rete cloud privato (VPC) gestita da te e una rete VPC gestita da Apigee. Dopo aver completato i primi passaggi di provisioning, i due VPC esistono, ma non possono comunicare tra loro. È necessaria un'ulteriore configurazione per consentire comunicazione. Vedi la Figura 6.

    Figura 6: il tuo VPC e il VPC di Apigee non possono comunicare tra loro senza ulteriore configurazione.

    Per abilitare la comunicazione tra i VPC, utilizziamo Private Service Connect (PSC) per instradare il traffico verso nord ad Apigee e il traffico verso sud verso i servizi in esecuzione nei tuoi progetti Google Cloud.

    PSC consente una connessione privata tra un producer di servizi (Apigee) e un consumer di servizi (uno o più altri progetti Cloud sotto il tuo controllo). Con questo metodo (Figura 7), le richieste passano attraverso tramite un bilanciatore del carico esterno globale o esterno a livello di regione in un unico punto di collegamento, chiamato collegamento a un servizio.

    Per connettere privatamente Apigee a una destinazione di backend, devi creare due entità: una collegamento del servizio nella rete VPC in cui viene eseguito il deployment del target e di un collegamento endpoint nel VPC Apigee. Questi due entità consentono ad Apigee di connettersi al servizio di destinazione. Consulta Pattern di networking verso sud.

    I passaggi per il provisioning di Apigee con PSC (senza peering VPC) sono descritti in Provisioning a riga di comando senza peering VPC.

    Figura 7. di Apigee senza peering VPC. Per maggiori dettagli su questa architettura, vedi Panoramica dell'architettura di Apigee.