Um ambiente oferece um contexto isolado ou uma "sandbox" para executar proxies de API. Numa única organização, pode criar vários ambientes. Para mais informações, consulte o artigo Acerca dos ambientes e dos grupos de ambientes.
Durante uma instalação básica, adicionou um ambiente para testes. No entanto, é uma prática recomendada criar vários ambientes e implementar um número limitado de proxies em cada um.
Acerca dos anfitriões e ambientes virtuais
O Apigee hybrid usa gateways de entrada do Istio para processar o tráfego de API recebido. Os serviços de tempo de execução e MART estão ambos configurados com gateways de entrada do Istio para gerir as respetivas ligações expostas fora do cluster. Isto significa, por exemplo, que todos os pedidos HTTP e HTTPS a um proxy de API são processados primeiro por um gateway de entrada do Istio.
No modo híbrido, cria um ou mais ambientes e atribui a cada ambiente um alias de anfitrião. O alias do anfitrião é um nome DNS. O tráfego recebido para esse nome DNS é encaminhado pela entrada para esse ambiente. Internamente, cada ambiente é atribuído a um e apenas um processador de mensagens, que processa pedidos de proxy, aplica políticas e encaminha o tráfego para e a partir dos serviços de destino. Por conseguinte, o alias do anfitrião determina que processador de mensagens recebe qualquer pedido recebido.
O código seguinte mostra um exemplo de configuração em que são definidos vários ambientes. (Essas configurações pertencem ao ficheiro de substituições.) Tenha em atenção que os ambientes dev1 e prod1 têm aliases de anfitrião diferentes:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
Suponhamos que um proxy com o caminho base /foo1 é implementado no ambiente dev1. Pode chamar o proxy da seguinte forma:
curl -k https://apitest.mydomain.net/foo1
Quando esta chamada atinge a entrada, a entrada sabe que a deve enviar para o processador de mensagens associado ao ambiente dev1, que processa o pedido.
Da mesma forma, se foo1 também estiver implementado no ambiente prod1, pode fazer um pedido de proxy da seguinte forma para o alias de anfitrião apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
A chamada é encaminhada pela entrada para o MP associado a esse anfitrião.
Em resumo, cada ambiente que criar tem de ter um alias de anfitrião atribuído. Cada ambiente é mapeado para um único processador de mensagens, e o alias do anfitrião determina que processador de mensagens recebe um determinado pedido.
Os ambientes podem partilhar o mesmo alias de anfitrião
O Apigee Hybrid permite-lhe criar vários ambientes que pode gerir como quiser. Por exemplo, pode criar vários ambientes de desenvolvimento, dev1, dev2, dev3 e assim sucessivamente, e mapear um único alias de anfitrião para cada um. Além disso, pode implementar vários proxies em cada ambiente.
Antipattern: implemente todos os seus proxies num ambiente híbrido.
Prática recomendada: crie vários ambientes e implemente um número limitado de proxies em cada um deles. A técnica para gerir a forma como as rotas híbridas encaminham as chamadas para o ambiente correto que partilha um alias de anfitrião é denominada encaminhamento de caminho base.
Por exemplo, na seguinte configuração, os ambientes dev1 e dev2 partilham o mesmo alias de anfitrião:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
Quando vários ambientes partilham o mesmo alias de anfitrião, tem de usar a técnica de configuração denominada encaminhamento de caminho base para mapear caminhos base de proxy específicos para ambientes específicos. Consulte o encaminhamento do caminho base para mais informações.
Limite o número de implementações de proxy
Para o híbrido, o facto de muitos ambientes poderem partilhar o mesmo anfitrião virtual significa que tem de pensar cuidadosamente na forma como gere as implementações de proxy em qualquer ambiente específico. No modo híbrido, a prática recomendada é criar vários ambientes e implementar um número limitado de proxies em cada um.
Quantos proxies deve implementar num ambiente? Não existe uma resposta definida para esta pergunta. No entanto, a tabela seguinte fornece orientações gerais sobre o motivo pelo qual é uma boa ideia limitar o número de proxies implementados em cada ambiente e o que tem de ter em atenção ao gerir implementações de proxies:
| Problema a considerar | Descrição |
|---|---|
| Tempo de arranque do processador de mensagens | Existe uma correlação direta entre o tempo que um processador de mensagens (MP) demora a arrancar e o número de proxies implementados nesse MP. Num ambiente do Kubernetes com escala automática, um aumento no tempo de arranque pode ser um problema. Quanto mais proxies forem implementados no MP, mais tempo demorará a que esse MP seja apresentado se precisar de ser dimensionado ou recriado. |
| Desempenho de escalabilidade | Se tiver vários proxies implementados num ambiente e um dos proxies receber muito tráfego, de modo que seja frequentemente dimensionado automaticamente, todos os proxies nesse ambiente são dimensionados com ele. O efeito no desempenho da expansão de vários proxies com um único proxy de tráfego elevado pode ser um problema. |
| Vizinho ruidoso | Se tiver vários proxies implementados no mesmo ambiente e um proxy falhar, todos os proxies no ambiente são desativados enquanto os MPs são reiniciados. Ao limitar o número de proxies implementados num ambiente, minimiza o impacto de uma falha de um único proxy. |
Referência de configuração do ambiente
Para ver uma lista completa de elementos de configuração do ambiente, consulte envs na
Referência da propriedade de configuração.
Trabalhar com ambientes
Para mais informações sobre a configuração, consulte os seguintes tópicos: