Best practice per gli utenti con limitazione della velocità di un'API REST?

Question

Sto mettendo insieme un'API REST e, dato che non sono sicuro di come si ridimensionerà o quale sarà la sua domanda, mi piacerebbe essere in grado di valutare gli usi limitati di esso e di essere in grado temporaneamente rifiuta le richieste quando la casella è troppo piena o se esiste una sorta di scenario slashdotted.

Mi piacerebbe anche essere in grado di disattivare temporaneamente il servizio (fornendo al contempo i risultati dei clienti che indicano che il servizio principale è offline per un po ') quando / se devo ridimensionare il servizio aggiungendo più capacità.

Esistono buone pratiche per questo tipo di cose? L'implementazione è Rails con mysql.

Answer 1

Questo è tutto fatto con un webserver esterno, che ascolta il mondo (consiglio nginx o lighttpd).

Per quanto riguarda i limiti di velocità, nginx è in grado di limitare, vale a dire 50 req / minuto per ogni IP, ottenendo ovunque 503 pagine, che è possibile personalizzare.

Per quanto riguarda il down temporaneo previsto, nel mondo delle rotaie questo viene fatto tramite la pagina maintainance.html speciale. Esiste un tipo di automazione che crea o collega simbolicamente quel file quando i server delle app di rails non funzionano. Consiglio di non fare affidamento sulla presenza dei file, ma sull'effettiva disponibilità del server delle app.

Ma davvero sei in grado di avviare / interrompere i servizi senza perdere alcuna connessione. Cioè puoi eseguire un'istanza separata del server delle app su una diversa porta socket / IP UNIX e fare in modo che il bilanciamento (nginx / lighty / haproxy) utilizzi anche quella nuova istanza. Quindi si chiude la vecchia istanza e tutti i client vengono serviti solo con uno nuovo. Nessuna connessione persa. Naturalmente questo scenario non è sempre possibile, dipende dal tipo di modifica introdotto nella nuova versione.

haproxy è una soluzione solo per il bilanciamento. Può bilanciare in modo estremamente efficiente le richieste ai server delle app nella tua farm.

Per un servizio abbastanza grande si finisce con qualcosa del tipo:

• api.domain risolto in bilanciatori round-robin N
• ogni bilanciamento inoltra richieste ai server web M per server di app statici e P per contenuti dinamici. Oh bene la tua API REST non ha file statici, vero?

Per un servizio abbastanza piccolo (meno di 2K rps) tutto il bilanciamento viene eseguito all'interno di uno o due server web.

Answer 2

Buone risposte già - se non vuoi implementare tu stesso il limitatore, ci sono anche soluzioni come 3scale ( http: / /www.3scale.net ) che limita la velocità, analisi, ecc. per le API. Funziona utilizzando un plug-in (vedi qui per il plug-in ruby ??api ) che si collega all'architettura 3scale. Puoi anche usarlo tramite vernice e far agire la vernice come proxy limitatore di velocità.

Answer 3

Consiglio di implementare i limiti di velocità al di fuori della tua applicazione poiché altrimenti l'alto traffico avrà comunque l'effetto di uccidere la tua app. Una buona soluzione è implementarla come parte del tuo proxy apache, con qualcosa come mod_evasive