Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Veja a 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 balanceador de carga (XLB) HTTPS externo global. 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 da API proxy
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 VM 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 no sentido ascendente para o Apigee e o tráfego no sentido descendente 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 do Google Cloud que controla). Com este método (Figura 7), os pedidos passam por um balanceador de carga externo global ou um balanceador 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.
