Archiviare e inoltrare richieste HTTP con tentativi?

Question

Twilio e altri servizi Web basati su HTTP hanno il concetto di fallback URL, in cui i servizi Web inviano un GET o POST a un URL di propria scelta se l'URL principale scade o non funziona. Nel caso di Twilio, non ripeteranno la richiesta se fallisce anche l'URL di fallback. Vorrei che l'URL di fallback fosse ospitato su una macchina separata in modo che l'errore non si perdesse nell'etere se il server primario è inattivo o irraggiungibile.

mi piacerebbe un modo per le secondarie a:

1. richieste di memorizzazione alla URL di fallback
2. Replay le richieste a un URL leggermente diversa sul server primario
3. Riprova # 2 fino successo , quindi eliminare la richiesta dalla coda/database

Esiste qualche software esistente in grado di farlo? Posso costruire qualcosa io stesso, se necessario, ho pensato che sarebbe stato qualcosa che qualcuno avrebbe già fatto. Non conosco abbastanza bene l'HTTP e gli strumenti circostanti (proxy, proxy inversi, ecc.) Per conoscere la parola chiave giusta da cercare.

Answer 1

Ci sono un paio di possibilità.

Un'opzione è utilizzare il protocollo di ridondanza o carpa di indirizzo comune. Segue una breve descrizione dalla pagina man.

"carp consente a più host sulla stessa rete locale di condividere un insieme di indirizzi IP. Il suo scopo principale è quello di garantire che questi indirizzi siano sempre disponibili, ma in alcune configurazioni la carp può anche fornire funzionalità di bilanciamento del carico."

Dovrebbe essere possibile configurare il bilanciamento IP in modo tale che quando un servizio http primario o master non riesce, il servizio http secondario o di backup diventa il master. la carpa è orientata all'host in contrapposizione al servizio di applicazione. Quindi, quando il servizio http non funziona, dovrebbe anche rimuovere l'interfaccia di rete affinché la carpa faccia il suo esempio. Ciò significa che è necessario più di un indirizzo IP per accedere alla macchina e fare manutenzione. Avresti bisogno di uno script per eseguire le azioni di follow-up una volta che il servizio originale torna online.

La seconda opzione è utilizzare nginx. Questo probabilmente è più adatto a quello che stai cercando di fare.

Molti anni fa avevo bisogno di qualcosa di simile a quello che sto cercando di fare e ho finito per hacking insieme qualcosa che lo ha fatto. Essenzialmente era un interruttore. Quando "A" fallisce, passa a "B". La procedura di risincronizzazione consisteva nel prendere i log con timestamp da "B" e riprodurli su "A", una volta che "A" era di nuovo online.