Come essere robusti contro i tempi di inattività del servizio web causati da terze parti

Question

Come essere robusti contro i tempi di inattività del servizio web causati da terze parti

#1 da (1 voti)
#2 da (1 voti)

2

Uso iPage come provider di server basato su cloud. Non ho ancora avuto problemi con loro. Conservano gli script per i miei servizi RESTful per l'app mobile che sto sviluppando. Il mio problema però è che stasera il servizio è andato giù. Ho ricevuto un errore "Questo è un 500".

Mi chiedo come faccio a creare ridondanza nei miei servizi RESTful per evitare che ciò accada. Dicono che ci vorranno almeno 2 ore finché non saranno in grado di risolvere questo problema. Se la mia app è in diretta, non posso aspettare 2 ore. I miei utenti si annoieranno. So che questo succede comunque, ma come posso creare ridondanze per impedirlo.

errors web-development rest mobile cloud

posta Curtis Sumpter 08.05.2013 - 05:15

fonte

2 risposte

Leggi altre domande sui tag errors web-development rest mobile cloud

Modern REPL for Haskell - qualcuno ci sta lavorando? [chiuso] Quali algoritmi caratterizzano il potere di Lisp? [chiuso]

score 1 · Answer 1

Un tradizionale compromesso nell'esternalizzazione di qualsiasi parte del business a un fornitore, non solo al cloud computing: si rinuncia a lavorare sui bit che "plumbing" in ciò che offri, e concentrati sulle parti in cui pensi di poter aggiungere più valore. D'altra parte, si rinuncia a control dell'impianto idraulico a un'altra società, che introduce i propri rischi.

Le tue opzioni sono:

accetta che si verifichino interruzioni del genere.
per avere un Accordo sul livello di servizio con il tuo fornitore in modo che se non riescono a soddisfare i tuoi requisiti di disponibilità puoi penalizzarli. Ciò non impedisce ai tuoi clienti di arrabbiarsi, ma fornisce una restituzione finanziaria nel caso in cui il servizio non fosse disponibile.
utilizza un fornitore diverso con una capacità migliore per soddisfare le tue esigenze.
gestisci tu stesso la fornitura del server. Ciò comporta alcuni costi in termini di hardware, larghezza di banda, alimentazione, raffreddamento, tempi di amministrazione e così via, ma ti consente di controllare ciò che dici è una parte fondamentale del tuo lavoro.
esternalizzare il back-end a più fornitori. È possibile ospitare un bilanciatore del carico, in modo che le richieste vengano inviate a server di società diverse. Se un backend scende, è possibile configurare il load balancer per non puntarlo. Tuttavia, si noti che questo sposta semplicemente il problema sulla catena: il bilanciamento del carico è ora un singolo punto di errore. Come ti assicuri che la casella non vada offline per due ore? Inoltre, questa soluzione introduce nuovi problemi: i backend devono essere sincronizzati? Come è gestito? Come si ripristina la sincronizzazione da un'interruzione? Puoi permetterti di pagare più fornitori? E così via.

score 1 · Answer 2

Posso pensare ai tipi di ridondanza:

Avere un secondo provider di fallback che ospita una copia del tuo servizio REST e un mirror dei tuoi dati e lasciare che la tua app chiami il fallback se il sistema principale è inattivo.
avere una copia del file locale dei tuoi ultimi risultati del servizio di restituzione per chiamate nel caso in cui il server sia offline.

Entrambe le soluzioni possono essere costose. L'alternativa è accettare il tempo di inattività e dirlo ai tuoi utenti dell'app

"Sorry, the Servers is down for maintanance reasons. Please try again later"