Un ambiente fornisce un contesto isolato o una "sandbox" per l'esecuzione di proxy API. In un'unica organizzazione, puoi creare più ambienti. Per ulteriori informazioni, vedi Informazioni sugli ambienti e sui gruppi di ambienti.
Durante un'installazione di base, hai aggiunto un dell'ambiente per i test. È consigliabile, tuttavia, creare più ambienti ed eseguire il deployment di un numero limitato di proxy a ciascuno.
Informazioni sugli ambienti e sugli host virtuali
Apigee hybrid utilizza Gateway in entrata Istio per gestire il traffico API in entrata. Il MART e i servizi di runtime sono entrambi configurati con gateway in entrata Istio per gestire i propri di connessioni esposte all'esterno del cluster. Questo significa, ad esempio, che tutte le richieste HTTP e HTTPS a un proxy API vengono prima gestite da un gateway in entrata Istio.
Nella modalità ibrida, puoi creare uno o più ambienti e assegnare a ciascun ambiente un alias host. L'alias host è un nome DNS. Il traffico in entrata verso quel nome DNS viene instradato dal traffico in entrata verso quel nome completamente gestito di Google Cloud. Internamente, ogni ambiente è assegnato a un solo processore di messaggi, che si occupa di elaborare le richieste proxy, applicare criteri e instradare il traffico dai servizi di destinazione. Di conseguenza, l'alias host determina quale processore di messaggi riceve una data richiesta in arrivo.
Il codice seguente mostra una configurazione di esempio in cui più ambienti sono definito. Queste configurazioni appartengono al file degli override. Tieni presente che gli ambienti dev1 e prod1 hanno alias host diversi:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
Supponiamo che sia stato eseguito il deployment nell'ambiente di un proxy con percorso di base /foo1
dev1. Potresti chiamare il proxy nel seguente modo:
curl -k https://apitest.mydomain.net/foo1
Quando questa chiamata raggiunge il traffico in entrata, il componente in entrata sa di inviarla al processore di messaggi
associati all'ambiente dev1, che gestisce la richiesta.
Allo stesso modo, se il deployment di foo1 viene eseguito anche nell'ambiente prod1,
potresti creare un proxy
come questa, all'alias host apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
La chiamata viene instradata dal server in entrata al MP associato a quell'host.
Riassumendo, a ogni ambiente che crei deve essere assegnato un alias host. Ogni ambiente viene mappato a un solo processore di messaggi e l'alias host determina quale processore di messaggi riceve una determinata richiesta.
Gli ambienti possono condividere lo stesso alias host
Apigee hybrid ti consente di creare più ambienti da gestire come preferisci. Per Ad esempio, puoi creare diversi ambienti di sviluppo: dev1, dev2, dev3 e così via e mappa una un singolo alias host a ciascuno. Inoltre, puoi eseguire il deployment di più proxy in ciascun ambiente.
Antipattern: esegui il deployment di tutti i proxy in un ambiente ibrido.
Best practice: crea più ambienti ed esegui il deployment di un numero limitato di proxy a ciascuno. La tecnica per gestire il modo in cui ibridi instradano le chiamate proxy all'indirizzo un ambiente che condivide un alias host è chiamato routing del percorso di base.
Ad esempio, nella configurazione seguente, gli ambienti dev1 e dev2 condivide lo stesso alias host:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
Quando più ambienti condividono lo stesso alias host, devi utilizzare la tecnica di configurazione chiamata instradamento dei percorsi di base per mappare percorsi di base dei proxy specifici ad ambienti specifici. Consulta instradamento del percorso di base per ulteriori informazioni.
Limita il numero di deployment proxy
Nel caso dell'ibrido, il fatto che molti ambienti possano condividere lo stesso host virtuale significa che devi pensare attentamente a come gestire le tue distribuzioni proxy per qualsiasi completamente gestito di Google Cloud. Nel caso di ambienti ibridi, la best practice consiste nel creare più ambienti ed eseguire il deployment a ciascuno di essi è associato un numero limitato di proxy.
Quanti proxy dovresti eseguire per il deployment in un ambiente? Non c'è una risposta impostata a questa domanda: tuttavia, la tabella seguente fornisce indicazioni generali sul motivo per cui si tratta di un è buona norma limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e il numero devi pensare quando gestisci i deployment proxy:
| Problema da considerare | Descrizione |
|---|---|
| Tempo di avvio del processore di messaggi | Esiste una correlazione diretta tra la quantità di tempo in cui un processore di messaggi (MP) per l'avvio e il numero di proxy di cui è stato eseguito il deployment su quel MP. In una scalabilità automatica Kubernetes, un aumento del tempo di avvio potrebbe rappresentare un problema. Maggiore è il numero di proxy deployment al MP, più tempo impiegherà quell'MP deve essere scalato o ricreato. |
| Scalabilità del rendimento | Se hai più proxy di cui è stato eseguito il deployment in un ambiente e uno dei proxy viene molto traffico, in modo che spesso venga scalato automaticamente, tutti i proxy dell'ambiente di rete lo scalerà di conseguenza. L'effetto sulle prestazioni della scalabilità con un singolo proxy a traffico elevato potrebbe essere un problema. |
| Vicino rumoroso | Se hai eseguito il deployment di più proxy nello stesso ambiente, si arresta in modo anomalo, tutti i proxy nell'ambiente vengono rimossi mentre I MP vengono riavviati. Se limiti il numero di proxy di cui è stato eseguito il deployment in un ambiente, minimizzare l'impatto dell'arresto anomalo di un singolo proxy. |
Riferimento per la configurazione dell'ambiente
Per un elenco completo degli elementi di configurazione dell'ambiente, consulta envs nella
Riferimento alle proprietà di configurazione.
Utilizzo degli ambienti
Per ulteriori informazioni sulla configurazione, consulta i seguenti argomenti: