Commutazione della "modalità di manutenzione" nell'app Java EE

Question

Commutazione della "modalità di manutenzione" nell'app Java EE

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

4

Ho giocato con l'idea delle levette di funzionalità per vari scopi di configurazione / accesso, ma sono stato un po 'insicuro di me stesso quando si tratta di attivare qualcosa come un downtime o una modalità di manutenzione, in cui gli utenti non possono accedere a nulla durante quel tempo.

Sembra una cosa così semplice da fare in termini di implementazione, ma volevo ottenere un input da quelli più esperti di me sull'argomento.

Il mio primo pensiero è stato semplicemente il controllo di un flag in un database (questo è un ambiente cluster, quindi un flag basato su file sembra non ideale nel nostro setup), ma si sente sbagliato con il database colpito ad ogni richiesta. Così, mi sono mosso per farlo in modo simile a una cache in memoria temporizzata, ma anche questo non mi sembra giusto, dato che non vorrei che la cache fosse così di breve durata che deve essere aggiornata troppo frequentemente dal db, ma non voglio attivare la modalità di manutenzione e potenzialmente avere utenti in grado di entrare durante il tempo che precede l'aggiornamento. Dovrei forse avere una cache con un trigger di aggiornamento forzato separato come menzionato qui ?

In che modo hai gestito la commutazione di una modalità di manutenzione o di interruzione a livello di app?

maintenance java-ee

posta whitlaaa 18.12.2014 - 01:29

fonte

2 risposte

Leggi altre domande sui tag maintenance java-ee

Gli oggetti dominio / modello attribuiscono buone pratiche Come mettere in sicurezza diverse richieste API per un singolo utente

score 1 · Answer 1

Interruttore a due passaggi

Una possibilità è usare l'interruttore a due fasi.

Immagina di dover eseguire un'attività di manutenzione durante la quale gli utenti non dovrebbero poter accedere al database.

Passaggio 1

Si inizia cambiando un flag in un database. Questo flag non è un flag della modalità di manutenzione, ma indica che i client non devono più utilizzare il database poiché sarà presto messo in modalità di manutenzione.

Il valore di questo flag può essere memorizzato nella cache per, ad esempio, cinque minuti per evitare ripetuti interrogazioni al database.

Passaggio 2

Cinque minuti più tardi , avvii l'attività di manutenzione effettiva.

Ora sei sicuro che tutti hanno annullato la cache, quindi il client ha già richiesto il flag e sa che il database sta per entrare in modalità di manutenzione, o sarà necessariamente per questo valore prima di eseguire qualsiasi altra query.

Pro

Non è necessario interrogare il database troppo spesso per il valore del flag di pre-manutenzione.
Non è possibile per il client avviare l'interrogazione del database mentre viene eseguita la manutenzione.

Contro

È necessario attendere alcuni minuti (cinque nel mio esempio) prima di eseguire l'operazione di manutenzione. Questo è OK se si tratta di un'attività pianificata o qualcosa che può essere pianificata, ma sarebbe un problema per le attività di manutenzione che dovrebbero essere eseguite il prima possibile, come le modifiche alla configurazione relative a un problema di sicurezza appena scoperto o le misure utilizzate per prevenire un attacco in corso.

Connessione a due vie

Se è necessario essere in grado di eseguire rapidamente le attività di manutenzione senza pianificazione aggiuntiva (vedere Cons sopra), potrebbe essere necessario implementare una connessione a due vie che consente a te, il fornitore di servizi, di inviare un messaggio a i tuoi clienti, notificandoli che il servizio passerà alla modalità di manutenzione.

Sebbene questo tipo di comunicazione diventi sempre più popolare per le applicazioni web con il supporto di Web socket da parte di tutti i principali browser, se capisco bene, hai a che fare con le applicazioni desktop. Se l'ecosistema Java non ha una tecnologia simile per le app desktop (sono abbastanza sicuro che lo faccia) o se per qualche motivo non puoi usarlo, potresti essere interessato alle tecniche legacy utilizzate nelle app web, come ad esempio sondaggio lungo . Puoi leggere queste tecniche nella pagina Cometa , in particolare in che modo influiscono sulla larghezza di banda e quali effetti collaterali hanno.

Pro

È possibile eseguire l'attività di manutenzione quasi immediatamente pur sapendo che i clienti sono informati del passaggio alla modalità di manutenzione.

Contro

Queste tecniche potrebbero essere difficili da implementare correttamente (ad esempio, come gestiresti il caso in cui hai inviato un messaggio a un client, ma il client non ha risposto né ha abbandonato la connessione?)

score 1 · Answer 2

Per fare questo esiste uno strumento specifico all'interno di Java EE. Estensioni di gestione Java alias JMX (Opzioni pratiche di Oracle )

Con, si dovrebbe impostare un "bean gestito" (noto anche come MBean) che può quindi eseguire il polling esternamente (utile per impostare notifiche su prestazioni, risorse, problemi) o essere utilizzato per richiamare i dati nell'applicazione (andare in mantieni la modalità ora ).

Molti contenitori servlet supportano l'amministrazione JMX. Ad esempio, Tomcat . È proprio lì - nessuna dipendenza esterna di un database o di memorizzazione nella cache o altri approcci. Questo è ciò a cui è destinato: l'amministrazione remota di un'applicazione (sia essa autonoma Java o un'applicazione web all'interno di un contenitore).

Il motivo per cui sono così di alto livello è che si tratta di un'area tecnologica abbastanza ampia. È il modo giusto per gestire questo tipo di operazione, ma ciò equivale anche a dire "per un'app CRUD utilizzare REST" - il dominio del problema è molto ampio e una risposta più specifica non può realmente effettuare un'analisi approfondita.