Panoramica dell'architettura Apigee

Questa pagina si applica a Apigee e Apigee ibrido.

Visualizza la documentazione di Apigee Edge.

Questo argomento fornisce una panoramica dell'architettura di sistema di Apigee. Ha lo scopo di aiutarti a comprendere quali componenti vengono creati durante il provisioning e il loro scopo nel sistema complessivo.

Apigee offre due opzioni per il provisioning: con peering VPC e senza peering VPC. Entrambe le opzioni 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 di sistema Apigee quando viene fornito l'opzione di peering VPC ad Apigee.

    Panoramica del provisioning

    Durante il provisioning, vengono configurati e creati componenti in modo da consentire la comunicazione bidirezionale tra una rete VPC (Virtual cloud privato) 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 ancora comunicare tra loro. Sono necessarie ulteriori configurazioni per consentire la comunicazione bidirezionale. 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, viene utilizzato il peering di rete VPC. 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 la comunicazione tra i due VPC. Vedi la Figura 2.

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

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

    Puoi anche eseguire il provisioning di un 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. Una volta completato il provisioning, le app su internet comunicano con il protocollo XLB, quest'ultimo comunica con la VM bridge e 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 le reti in peering.

    In questa configurazione, il traffico viene instradato da Apigee (ad esempio, dal criterio MessageLogging) a un carico di lavoro in esecuzione nel VPC interno. In questo caso, la comunicazione con il VPC interno non passa attraverso un IP NAT del traffico in uscita. Puoi invece instradare il traffico attraverso uno degli 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 i 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. Il protocollo 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 il tuo VPC 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 client.

    Architettura con peering VPC disabilitato

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

    Durante il provisioning, vengono configurati e creati componenti in modo da consentire la comunicazione bidirezionale tra una rete VPC (Virtual cloud privato) 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 ancora comunicare tra loro. Sono necessarie ulteriori configurazioni per consentire la comunicazione bidirezionale. Vedi la Figura 6.

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

    Per consentire la comunicazione tra i VPC, utilizziamo Private Service Connect (PSC) per instradare il traffico diretto ad Apigee e il traffico verso sud verso i servizi in esecuzione nei 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 controllati da te). Con questo metodo (Figura 7), le richieste passano attraverso un bilanciatore del carico esterno globale o un bilanciatore del carico esterno regionale a un singolo punto di collegamento, chiamato collegamento di servizio.

    Per connettere privatamente Apigee a una destinazione di backend, devi creare due entità: un collegamento al servizio nella rete VPC in cui viene eseguito il deployment della destinazione e un collegamento endpoint nel VPC Apigee. Queste 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 di questa architettura, consulta la panoramica dell'architettura di Apigee.