Panoramica dell'architettura Apigee

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

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

Apigee offre due opzioni per il provisioning: con peering VPC e senza peering VPC. Entrambe le opzioni sono descritte nelle sezioni che seguono.

  • Architettura con il peering VPC abilitato
  • Architettura con il peering VPC disattivato

    • Architettura con il peering VPC abilitato

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

    Panoramica del provisioning

    Durante il provisioning, vengono configurati e creati componenti che consentono 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. È 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 le VPC, utilizziamo il peering di rete VPC. 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 di un gruppi 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. Al termine del provisioning, le app su internet comunicano con l'XLB, l'XLB con la VM bridge e la VM bridge con la rete Apigee. Vedi la Figura 3 e la 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 avviene tramite un IP NAT dell'egress. In alternativa, puoi instradare il traffico tramite uno degli IP delle istanze Apigee.

    Figura 4: traffico indirizzato in privato a un carico di lavoro nella VPC interna.

    Ciclo di vita delle chiamate del proxy API

    La seguente illustrazione mostra il ciclo di vita di una chiamata proxy API mentre si sposta tra i 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. L'XLB è configurata con un indirizzo 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 del proxy API.
    5. Apigee invia la richiesta al servizio di backend e la risposta viene inviata al client.

    Architettura con il peering VPC disabilitato

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

    Durante il provisioning vengono configurati e creati componenti che consentono 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. È necessaria una configurazione aggiuntiva 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 abilitare la comunicazione tra le VPC, utilizziamo Private Service Connect (PSC) per instradare il traffico in entrata verso Apigee e il traffico in uscita verso i 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 un target di backend, devi creare due entità: un collegamento di servizio nella rete VPC in cui è dipiegato il target e un collegamento di endpoint nel VPC di Apigee. Queste 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 da riga di comando senza peering VPC.

    Figura 7. Architettura Apigee senza peering VPC. Per informazioni dettagliate su questa architettura, consulta la panoramica dell'architettura Apigee.