Panoramica dell'architettura Apigee

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza la 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 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 i 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 ancora comunicare tra loro. È necessaria una configurazione aggiuntiva per consentire la comunicazione bidirezionale. Vedi 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à degli indirizzi IP interni su due reti Virtual Private Cloud (VPC), indipendentemente dal fatto che appartengano allo stesso progetto o alla stessa organizzazione Google Cloud. Al termine del 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 le VPC.

    Per instradare il traffico dalle app client su internet ad Apigee, utilizziamo un bilanciatore del carico HTTPS esterno globale (XLB). Un XLB può comunicare tra progetti Google Cloud, ad esempio tra il progetto Google Cloud del cliente e il progetto Google Cloud di Apigee, utilizzando il riferimento ai 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 flusso di richieste e risposte tra le reti con accoppiamento.

    In questa configurazione, il traffico viene indirizzato da Apigee (ad esempio dal criterio di registrazione dei messaggi) a un carico di lavoro in esecuzione nella tua VPC interna. In questo caso, la comunicazione con il VPC interno non passano attraverso un IP NAT del traffico in uscita. In alternativa, puoi instradare il traffico tramite 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 componenti di sistema Apigee di cui è stato eseguito il provisioning (Figura 5):

    Figura 5: traffico indirizzato in modo privato a un carico di lavoro nella VPC interna.
    1. Un'app client chiama un proxy API Apigee.
    2. La richiesta viene inoltrata a un bilanciatore del carico HTTPS esterno L7 (XLB) globale. XLB è configurato con un IP esterno/pubblico e un certificato TLS.
    3. L'XLB invia la richiesta a una macchina virtuale (VM). La VM funge da ponte 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 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 con l'opzione peering VPC.

    Durante il provisioning, vengono configurati e creati componenti che consentono la comunicazione bidirezionale tra una rete VPC (Virtual Private Cloud) 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. È necessaria un'ulteriore configurazione per consentire la 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 le VPC, utilizziamo Private Service Connect (PSC) per instradare il traffico in entrata ad Apigee e il traffico in uscita ai servizi target in esecuzione nei tuoi progetti Google Cloud.

    PSC consente la 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 un bilanciatore del carico esterno globale o un bilanciatore del carico esterno regionale a un singolo punto di attacco, chiamato attacco del 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. Vedi 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 informazioni dettagliate su questa architettura, consulta la panoramica dell'architettura Apigee.