Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Ver documentação do
Apigee Edge.
Este tópico oferece uma vista geral da arquitetura do sistema Apigee. Destina-se a ajudar a compreender que componentes são criados durante o aprovisionamento e a sua finalidade no sistema geral.
O Apigee oferece duas opções de aprovisionamento: com interligação de VPCs e sem interligação de VPCs. Ambas as opções são descritas nas secções seguintes.
Arquitetura com intercâmbio de VPC ativado
Esta secção descreve a arquitetura do sistema Apigee quando o Apigee é aprovisionado com a opção de interligação de VPC.
Vista geral do aprovisionamento
Durante o aprovisionamento, são configurados e criados componentes que permitem a comunicação bidirecional entre uma rede da nuvem virtual privada (VPC) gerida por si e uma rede da VPC gerida pelo Apigee. Depois de concluir os primeiros passos de aprovisionamento, as duas VPCs existem, mas ainda não conseguem comunicar entre si. É necessária uma configuração adicional para permitir a comunicação bidirecional. Veja a Figura 1.
Para ativar a comunicação entre VPCs, usamos o intercâmbio de redes da VPC. O intercâmbio de redes permite a conetividade de endereços IP internos em duas redes da nuvem virtual privada (VPC), independentemente de pertencerem ao mesmo projeto ou à mesma organização do Google Cloud. Após a conclusão do passo de interligação de redes, a comunicação é possível entre as duas VPCs. Veja a Figura 2.
Para encaminhar o tráfego de apps de cliente na Internet para o Apigee, usamos um Application Load Balancer (XLB) externo. Um XLB pode comunicar entre projetos do Google Cloud, como entre o projeto do Google Cloud do cliente e o projeto do Google Cloud do Apigee, através da referência de serviços entre projetos.
Também pode aprovisionar um grupo de instâncias geridas (GIG) de máquinas virtuais (VMs) que funcionam como uma ponte de rede. As VMs do MIG têm a capacidade de comunicar bidirecionalmente nas redes com intercâmbio. Quando o aprovisionamento estiver concluído, as apps na Internet comunicam com o XLB, o XLB comunica com a VM de ponte e a VM de ponte comunica com a rede Apigee. Consulte a Figura 3 e a Figura 4.
Nesta configuração, o tráfego é encaminhado do Apigee (por exemplo, da política MessageLogging) para uma carga de trabalho em execução na sua VPC interna. Neste caso, a comunicação com a sua VPC interna não passa por um IP NAT da saída. Em alternativa, pode encaminhar o tráfego através de um dos IPs da instância do Apigee.
Ciclo de vida da chamada de proxy de API
A ilustração seguinte mostra o ciclo de vida de uma chamada de proxy de API à medida que se move através dos componentes do sistema Apigee aprovisionados (Figura 5):
- Uma app cliente chama um proxy de API do Apigee.
- O pedido chega a um balanceador de carga HTTPS externo (XLB) global de camada 7. O XLB está configurado com um IP externo/público e um certificado TLS.
- O XLB envia o pedido para uma máquina virtual (MV). A VM funciona como uma ponte entre a sua VPC e a VPC da Google (gerida pela Apigee).
- A MV envia o pedido para o Apigee, que processa o pedido de proxy de API.
- O Apigee envia o pedido para o serviço de back-end e a resposta é enviada de volta para o cliente.
Arquitetura com intercâmbio da VPC desativado
Esta secção descreve a arquitetura do sistema Apigee quando o Apigee não é aprovisionado com a opção de interligação de VPC.
Durante o aprovisionamento, são configurados e criados componentes que permitem a comunicação bidirecional entre uma rede da nuvem virtual privada (VPC) gerida por si e uma rede da VPC gerida pelo Apigee. Depois de concluir os primeiros passos de aprovisionamento, as duas VPCs existem, mas ainda não conseguem comunicar entre si. É necessária uma configuração adicional para permitir a comunicação bidirecional. Veja a Figura 6.
Para ativar a comunicação entre VPCs, usamos o Private Service Connect (PSC) para encaminhar o tráfego a montante para o Apigee e o tráfego a jusante para os serviços de destino em execução nos seus projetos do Google Cloud.
O PSC permite uma ligação privada entre um produtor de serviços (Apigee) e um consumidor de serviços (um ou mais outros projetos na nuvem que controla). Com este método (Figura 7), os pedidos passam por um Application Load Balancer externo ou um equilibrador de carga externo regional para um único ponto de ligação, denominado ligação de serviço.
Para ligar o Apigee de forma privada a um destino de back-end, tem de criar duas entidades: um anexo de serviço na rede da VPC onde o destino está implementado e um anexo de ponto final na VPC do Apigee. Estas duas entidades permitem que o Apigee se ligue ao serviço de destino. Consulte Padrões de rede de saída.
Os passos para o aprovisionamento do Apigee com o PSC (sem o intercâmbio da VPC) são descritos no artigo Aprovisionamento da linha de comandos sem o intercâmbio da VPC.
