Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza la documentazione di
Apigee Edge.
La configurazione di TargetEndpoint definisce il modo in cui Apigee si connette a un'API o a un servizio di backend. Invia le richieste e riceve le risposte da/verso il servizio di backend. Il servizio di backend può essere un server HTTP/HTTPS o NodeJS.
Il servizio di backend in TargetEndpoint può essere richiamato in uno dei seguenti modi:
- URL diretto a un server HTTP o HTTPS
- Configurazione di TargetServer
Allo stesso modo, il criterio ServiceCallout può essere utilizzato per effettuare una chiamata a qualsiasi servizio esterno dal flusso proxy API. Questo criterio supporta la definizione di URL di destinazione HTTP/HTTPS direttamente nel criterio stesso o utilizzando una configurazione TargetServer.
Configurazione di TargetServer
La configurazione TargetServer disaccoppia gli URL effettivi degli endpoint dalle configurazioni di TargetEndpoint o nei criteri di callout del servizio. A un TargetServer viene fatto riferimento da un nome anziché dall'URL in TargetEndpoint. La configurazione di TargetServer avrà il nome host del servizio di backend, il numero di porta e altri dettagli.
Ecco un esempio di configurazione di TargetServer:
<TargetServer name="target1"> <Host>www.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
TargetServer consente di avere diverse configurazioni per ogni ambiente. Un criterio TargetEndpoint/Callout di servizio può essere configurato con uno o più TargetServer denominati utilizzando un LoadBalancer. Il supporto integrato per il bilanciamento del carico migliora la disponibilità delle API e il failover tra le istanze del server di backend configurate.
Ecco un esempio di configurazione di TargetEndpoint che utilizza TargetServers:
<TargetEndpoint name="default"> <HTTPTargetConnection>> <LoadBalancer> <Server name="target1"/> <Server name="target2"/> </LoadBalancer> </HTTPTargetConnection> </TargetEndpoint>
MaxFailures
La configurazione MaxFailures
specifica il numero massimo di errori di richiesta al server di destinazione dopo i quali il server di destinazione deve essere contrassegnato come inattivo e rimosso dalla rotazione per tutte le richieste successive.
Una configurazione di esempio con MaxFailures
specificato:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1"/> <Server name="target2"/> <MaxFailures>5</MaxFailures> </LoadBalancer> </HTTPTargetConnection> </TargetEndpoint>
Nell'esempio precedente, se cinque richieste consecutive non sono riuscite per "target1", "target1" verrà rimosso dalla rotazione e tutte le richieste successive verranno inviate solo a target2.
Antipattern
Non è consigliabile avere un singolo TargetServer in una configurazione LoadBalancer
del criterio
TargetEndpoint o Service callout con MaxFailures
impostato su un valore diverso da zero
in quanto può avere implicazioni negative.
Considera la seguente configurazione di esempio con un singolo TargetServer
denominato "target1" con MaxFailures
impostato su 5 (valore diverso da zero):
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <MaxFailures>5</MaxFailures> </LoadBalancer> </HTTPTargetConnection>
Se le richieste al TargetServer "target1" hanno esito negativo per cinque volte (numero specificato in MaxFailures
),
TargetServer viene rimosso dalla rotazione. Poiché non esistono altri TargetServer a cui eseguire il failover,
tutte le successive richieste al proxy API con questa configurazione non andranno a buon fine con
503 Service Unavailable
errore.
Anche se il TargetServer "target1" torna allo stato normale ed è in grado di inviare risposte riuscite, le richieste al proxy API continueranno a restituire errori 503. Questo perché Apigee non rimette automaticamente il TargetServer in rotazione anche dopo che la destinazione è nuovamente attiva e in esecuzione. Per risolvere il problema, è necessario eseguire nuovamente il deployment del proxy API affinché Apigee possa rimettere in rotazione TargetServer.
Se nel criterio callout di servizio viene utilizzata la stessa configurazione, le richieste API riceveranno un errore 500 dopo che le richieste al TargetServer "target1" non hanno esito positivo per 5 volte.
Impatto
L'utilizzo di un singolo TargetServer in una configurazione LoadBalancer
del criterio
TargetEndpoint o Service Callout con MaxFailures
impostato su un valore diverso da zero causa:
- Le richieste API hanno esito negativo con errori 503/500 in modo continuo (dopo che le richieste non riescono per un numero di volte massimo) fino a quando non viene eseguito nuovamente il deployment del proxy API.
- Interruzione di maggiore durata in quanto è complessa e può richiedere più tempo per diagnosticare la causa di questo problema (senza alcuna conoscenza preliminare di questo antipattern).
Best practice
- Avere più di un TargetServer nella configurazione
LoadBalancer
per una maggiore disponibilità. Definisci sempre un monitoraggio di integrità quando
MaxFailures
è impostato su un valore diverso da zero. Un server di destinazione verrà rimosso dalla rotazione quando il numero di errori raggiunge il numero specificato inMaxFailures
. Avere un HealthMonitor assicura che TargetServer venga rimesso in rotazione non appena il server di destinazione diventa di nuovo disponibile, il che significa che non è necessario eseguire nuovamente il deployment del proxy.Per garantire che il controllo di integrità venga eseguito sullo stesso numero di porta utilizzato da Apigee per la connessione ai server di destinazione, Apigee consiglia di omettere l'elemento figlio
<Port>
in<TCPMonitor>
, a meno che non sia diverso dalla porta TargetServer. Per impostazione predefinita,<Port>
corrisponde alla porta TargetServer.Esempio di configurazione con HealthMonitor:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> </TargetEndpoint>
Se esiste un vincolo che prevede un solo TargetServer e se HealthMonitor non viene utilizzato, non specificare
MaxFailures
nella configurazione diLoadBalancer
.Il valore predefinito di MaxFailures è 0. Ciò significa che Apigee tenta sempre di connettersi alla destinazione per ogni richiesta e non rimuove mai il server di destinazione dalla rotazione.
Per approfondire
- Bilanciamento del carico tra i server di backend
- Come utilizzare i server di destinazione nei proxy API