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. È progettato per aiutarti a capire quali componenti vengono creati durante il provisioning e il loro scopo nel sistema complessivo.

Apigee offre due opzioni di provisioning: con peering VPC e senza peering VPC. Entrambe le opzioni sono descritte nelle sezioni seguenti.

Architettura con peering VPC abilitato

Questa sezione descrive l'architettura di sistema di Apigee quando Apigee viene 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 Virtual cloud privato (VPC) gestita da te e una rete VPC gestita da Apigee. Dopo aver completato i primi passaggi di provisioning, le due VPC esistono, ma non possono ancora comunicare tra loro. È necessaria un'ulteriore configurazione 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, 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. 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 bilanciatore del carico cross-project può comunicare tra progetti Google Cloud, ad esempio tra il progetto Google Cloud del cliente e il progetto Google Cloud Apigee, utilizzando il riferimento al servizio cross-project.

Puoi anche eseguire il provisioning di un gruppo di istanze gestite (MIG) di macchine virtuali (VM) che fungono da bridge di rete. Le VM del MIG hanno la capacità di comunicare in modo bidirezionale tra le reti in peering. Al termine del provisioning, le app su internet comunicano con il bilanciatore del carico XLB, che comunica con la VM bridge, che a sua volta comunica 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 peering.

In questa configurazione, il traffico viene instradato da Apigee (ad esempio, dalla norma MessageLogging) a un workload in esecuzione nel tuo VPC interno. In questo caso, la comunicazione con il tuo VPC interno non passa attraverso un IP NAT dell'uscita. In alternativa, puoi instradare il traffico tramite uno degli IP dell'istanza Apigee.

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

Ciclo di vita della chiamata 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 instradato privatamente a un carico di lavoro nel VPC interno.
  1. Un'app client chiama un proxy API Apigee.
  2. La richiesta arriva a un bilanciatore del carico HTTPS esterno L7 globale (XLB). Il bilanciatore del carico esterno è configurato con un IP esterno/pubblico e un certificato TLS.
  3. XLB invia la richiesta a una macchina virtuale (VM). La VM funge da ponte tra la tua rete VPC e la rete VPC di Google (gestita 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 Apigee non viene sottoposto a provisioning 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, le due VPC esistono, ma non possono ancora comunicare tra loro. È necessaria un'ulteriore configurazione 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 i VPC, utilizziamo Private Service Connect (PSC) per il routing del traffico in uscita verso Apigee e del traffico in entrata verso i servizi di destinazione 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 che controlli). Con questo metodo (Figura 7), le richieste passano attraverso un bilanciatore del carico esterno globale o un bilanciatore del carico esterno regionale a un unico punto di collegamento, chiamato collegamento del servizio.

Per connettere privatamente Apigee a un target di backend, devi creare due entità: un collegamento al servizio nella rete VPC in cui è distribuito il target e un collegamento all'endpoint nel VPC 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 i dettagli di questa architettura, consulta la panoramica dell'architettura Apigee.