Visão geral da arquitetura da Apigee

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Neste tópico, apresentamos uma visão geral da arquitetura do sistema da Apigee. Isso ajuda você a entender quais componentes são criados durante o provisionamento e sua finalidade no sistema geral.

A Apigee oferece duas opções de provisionamento: com peering de VPC e sem peering de VPC. As duas opções estão descritas nas seções a seguir.

  • Arquitetura com peering de VPC ativado
  • Arquitetura com peering de VPC desativado

    • Arquitetura com peering de VPC ativado

    Nesta seção, descrevemos a arquitetura do sistema da Apigee quando ela é provisionada com a opção de peering de VPC.

    Visão geral do provisionamento

    Durante o provisionamento, os componentes são configurados e criados para permitir a comunicação bidirecional entre uma rede de nuvem privada virtual (VPC) gerenciada por você e uma rede VPC gerenciada pela Apigee. Depois de concluir as primeiras etapas de provisionamento, as duas VPCs existem, mas ainda não conseguem se comunicar entre si. Mais configurações são necessárias para permitir a comunicação bidirecional. Veja a Figura 1.

    Figura 1: sua VPC e a VPC da Apigee não podem se comunicar entre si sem configuração adicional.

    Para permitir a comunicação entre VPCs, usamos o peering de rede VPC. O peering de rede permite a conectividade de endereço IP interno em duas redes de nuvem privada virtual (VPC) pertencentes ou não ao mesmo projeto ou organização do Google Cloud. Após a conclusão da etapa de peering de rede, a comunicação entre as duas VPCs será possível. Veja a Figura 2.

    Figura 2: o peering de rede de VPC permite a comunicação entre VPCs.

    Para rotear o tráfego de apps clientes na Internet para a Apigee, usamos um balanceador de carga de HTTPS externo global (XLB, na sigla em inglês). Um XLB pode se comunicar entre projetos do Google Cloud, por exemplo, entre o projeto do Google Cloud do cliente e o projeto do Google Cloud da Apigee, usando referenciamento de serviço entre projetos.

    Também é possível provisionar um grupo de instâncias gerenciadas (MIG, na sigla em inglês) de máquinas virtuais (VM, na sigla em inglês) que servem como ponte de rede. As VMs do MIG podem se comunicar bidirecionalmente nas redes com peering. Quando o provisionamento é concluído, os apps na Internet se comunicam com o XLB, que se comunica com a VM de ponte. E a VM da ponte se comunica com a rede da Apigee. Veja as Figuras 3 e 4.

    Figura 3: as VMs gerenciadas permitem que solicitações e respostas fluam entre as redes com peering.

    Nesta configuração, o tráfego é roteado da Apigee (por exemplo, da política MessageLogging) para uma carga de trabalho em execução na VPC interna. Nesse caso, a comunicação com a VPC interna não passa por um IP NAT da saída. Em vez disso, é possível rotear o tráfego por meio de um dos IPs de instância da Apigee.

    Figura 4: tráfego roteado de forma particular para uma carga de trabalho em sua VPC interna
    .

    Ciclo de vida da chamada do proxy da API

    A ilustração a seguir mostra o ciclo de vida de uma chamada de proxy de API conforme ela avança pelos componentes provisionados do sistema da Apigee (Figura 5):

    Figura 5: tráfego roteado de forma particular para uma carga de trabalho na sua VPC interna.
    1. Um app cliente chama um proxy de API da Apigee.
    2. A solicitação chega a um balanceador de carga de HTTPS externo (XLB) global L7. O XLB é configurado com um IP externo/público e um certificado TLS.
    3. O XLB envia a solicitação para uma máquina virtual (VM). Ela serve como ponte entre sua VPC e a VPC do Google (gerenciada pela Apigee).
    4. A VM envia a solicitação para a Apigee, que processa a solicitação de proxy da API.
    5. A Apigee envia a solicitação ao serviço de back-end e a resposta é enviada de volta ao cliente.

    Arquitetura com peering de VPC desativado

    Nesta seção, descrevemos a arquitetura do sistema da Apigee quando a Apigee não é provisionada com a opção de peering de VPC.

    Durante o provisionamento, os componentes são configurados e criados para permitir a comunicação bidirecional entre uma rede de nuvem privada virtual (VPC) gerenciada por você e uma rede VPC gerenciada pela Apigee. Após a conclusão das primeiras etapas de provisionamento, as duas VPCs existem, mas ainda não conseguem se comunicar entre si. Mais configurações são necessárias para permitir a comunicação bidirecional. Veja a Figura 6.

    Figura 6: sua VPC e a VPC da Apigee não podem se comunicar entre si sem configuração adicional.

    Para ativar a comunicação entre as VPCs, usamos o Private Service Connect (PSC) para rotear o tráfego no sentido norte para a Apigee e o tráfego no sentido sul para os serviços de destino em execução nos projetos do Google Cloud.

    O PSC permite uma conexão particular entre um produtor de serviços (Apigee) e um consumidor de serviço (um ou mais projetos do Cloud que você controla). Com esse método (Figura 7), as solicitações são transmitidas por um balanceador de carga externo global ou regional para um único ponto de anexo, chamado anexo de serviço.

    Para conectar a Apigee de maneira particular a um destino de back-end, é preciso criar duas entidades: um anexo de serviço na rede VPC em que o destino está implantado e um anexo de endpoint na VPC da Apigee. Essas duas entidades permitem que a Apigee se conecte ao serviço de destino. Consulte Padrões de rede no sentido sul.

    As etapas para provisionar a Apigee com PSC (sem peering de VPC) são descritas em Provisionamento de linha de comando sem peering de VPC.

    Figura 7. Arquitetura da Apigee sem peering de VPC. Para detalhes sobre essa arquitetura, consulte Visão geral da arquitetura da Apigee.