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 Apigee. È destinata ad aiutarti a capire quali componenti vengono creati durante il provisioning e il loro scopo nel sistema generale.

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 di Apigee quando viene eseguito il provisioning di Apigee 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 Virtual cloud privato (VPC) gestita da te e una rete VPC gestita da Apigee. Dopo aver completato i primi passaggi di provisioning, esistono i due VPC, ma ancora non possono comunicare tra loro. Sono necessarie ulteriori configurazioni per consentire la comunicazione bidirezionale. Vedi la Figura 1.

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

    Per abilitare le comunicazioni tra VPC, utilizziamo il peering di rete VPC. Il peering di rete consente la connettività degli indirizzi IP interni tra due reti Virtual Private Cloud (VPC), indipendentemente dal fatto che appartengano allo stesso progetto o alla stessa organizzazione Google Cloud. Una volta completato il passaggio di peering di rete, la comunicazione è possibile 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 esterno globale (XLB). Un XLB può comunicare tra progetti Google Cloud, ad esempio tra il progetto Google Cloud del cliente e il progetto Apigee Google Cloud, utilizzando il riferimento al servizio multiprogetto.

    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 sono in grado di comunicare in modo bidirezionale attraverso 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 flusso 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 instradare il traffico tramite uno degli IP dell'istanza Apigee.

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

    Ciclo di vita delle chiamate 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 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 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 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 Virtual cloud privato (VPC) gestita da te e una rete VPC gestita da Apigee. Dopo aver completato i primi passaggi di provisioning, esistono i due VPC, ma ancora non possono comunicare tra loro. Sono necessarie ulteriori configurazioni per consentire la comunicazione bidirezionale. Vedi la Figura 6.

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

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

    Per connettere privatamente Apigee a una destinazione del 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. Vedi Pattern di networking in Sud.

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

    Figura 7. Architettura Apigee senza peering VPC. Per i dettagli di questa architettura, consulta la panoramica dell'architettura Apigee.