Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info
Per mantenere le prestazioni e la disponibilità su una base diversificata di app client, è fondamentale mantenere il traffico delle app entro i limiti della capacità delle API e dei servizi di backend. È inoltre importante assicurarsi che le app non consumino più risorse del consentito.
Apigee Edge fornisce due meccanismi che ti consentono di ottimizzare la gestione del traffico per ridurre al minimo la latenza per le app, mantenendo al contempo l'integrità dei servizi di backend. Ogni tipo di criterio affronta un aspetto distinto della gestione del traffico. In alcuni casi, potresti utilizzare entrambi i tipi di criteri in un unico proxy API.
Guarda questo video per un'introduzione ai criteri di gestione del traffico delle API.
SpikeArrest
Questo criterio riduce gli picchi di traffico dividendo un limite definito in intervalli più piccoli. Ad esempio, se definisci un limite di 100 messaggi al secondo, il criterio SpikeArrest applica un limite di circa 1 richiesta ogni 10 millisecondi (1000 / 100); e 30 messaggi al minuto vengono uniformati in circa 1 richiesta ogni 2 secondi (60 / 30). Il limite SpikeArrest deve essere vicino alla capacità calcolata per il servizio di backend o per il proxy API stesso. Il limite deve essere configurato anche per intervalli di tempo più brevi, come secondi o minuti. Questo criterio deve essere utilizzato per impedire picchi improvvisi di traffico causati da utenti malintenzionati che tentano di interrompere un servizio utilizzando un attacco denial of service (DoS) o da applicazioni client con bug.
Consulta le norme su SpikeArrest.
Quota
Questo criterio applica limiti di consumo alle app client mantenendo un "contatore" distribuito che conteggia le richieste in arrivo. Il contatore può conteggiare le chiamate API per qualsiasi entità identificabile, tra cui app, sviluppatori, chiavi API, token di accesso e così via. In genere, le chiavi API vengono utilizzate per identificare le app client. Questo criterio è dispendioso in termini di risorse di calcolo, pertanto per le API con traffico elevato deve essere configurato per intervalli di tempo più lunghi, ad esempio un giorno o un mese. Queste norme devono essere utilizzate per applicare contratti commerciali o SLA con sviluppatori e partner, anziché per la gestione del traffico operativo.
Consulta le norme relative alle quote.