Accoppiamento lento del processo daemon e dell'interfaccia di amministrazione

Question

Accoppiamento lento del processo daemon e dell'interfaccia di amministrazione

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

2

Ho un processo daemon, scritto in Java, che mi piacerebbe essere configurabile in fase di runtime tramite un'API basata su HTTP.

Per una serie di motivi, preferisco che l'API di amministrazione sia separata dal processo daemon stesso:

resilienza: se l'API di amministrazione fallisce, il demone deve continuare a funzionare.
separazione delle preoccupazioni: l'API di amministrazione e il daemon sono due componenti distinti (ma correlati) dell'intera applicazione.
accoppiamento lento: è più semplice aggiornare uno o l'altro componente se non sono strettamente accoppiati.

Al momento, gli approcci che ho considerato includono:

Incorporare sia il daemon che l'API di amministrazione in un'applicazione JAX-WS. Funzionerebbe, ma fallisce su tutti i punti precedenti.
Il processo daemon espone l'API di amministrazione tramite un servizio Web incorporato (ad esempio Jetty). Questo sarebbe meglio dell'approccio precedente (il demone non dipende più da un contenitore web), ma condivide molti degli stessi problemi.
Hanno due applicazioni separate (daemon e API), che condividono un database di configurazione comune. Ciò consentirebbe un accoppiamento lento, ma porterebbe a un'interazione imbarazzante tra i componenti (ad esempio, ogni componente che ha bisogno di interrogare il database per le modifiche apportate dall'altro).
Avere due applicazioni separate, comunicanti tramite un'interfaccia a basso livello basata su socket o pipe. Questo è il migliore in termini di ottenere un accoppiamento libero efficiente, ma (presumibilmente) a un costo maggiore in termini di complessità del codice.

Se accettiamo che sia preferibile mantenere i due componenti liberamente accoppiati, qual è l'approccio migliore (cioè più flessibile e idiomatico) per ottenere questo in Java? C'è un'alternativa che non ho considerato?

java coupling architecture api

posta Mac 02.06.2017 - 05:32

fonte

2 risposte

Leggi altre domande sui tag java coupling architecture api

Aggiorna e verifica automaticamente le dipendenze di npm Tracciamento e priorità di PBI quando è diviso per piattaforma

score 1 · Answer 1

La sfida è che il Daemon ha bisogno di funzionare continuamente, ma di aggiornare la sua configurazione su richiesta in modo robusto ma in un modo che possa essere spiegato sul caffè. In molti modi, dipende in realtà da cosa deve fare il daemon e dalla frequenza con cui queste configurazioni devono essere aggiornate. Esistono alcune opzioni che posso aiutare.

Elaborazione batch

Ho avuto un lavoro che essenzialmente ho suddiviso in parti separate:

Demone dello scheduler - responsabile della determinazione del lavoro da svolgere e della gestione del processo del processore.
App della riga comandi Processore - responsabile della lettura della configurazione all'avvio e dell'elaborazione effettiva.

Questa disposizione è stata incredibilmente semplice da capire e siamo stati in grado di convivere con la configurazione rimanendo invariata durante l'elaborazione di un file. Parte della configurazione riguardava i campi di mappatura nel documento su disco nei campi di un database. Ritarderemmo a leggere la configurazione per quel pezzo fino a poco prima di elaborare quel tipo di informazione. Quando siamo arrivati al prossimo documento, abbiamo controllato se c'erano modifiche al mapping.

Near Real Time Processing

Avevamo un'applicazione con requisiti di reporting e controllo per un motore remoto. Il motore doveva essere eseguito vicino all'hardware che stava monitorando in modo che potesse leggere la telemetria e sintetizzarlo. A causa della natura del problema, abbiamo dovuto fornire un'interfaccia UDP molto semplice con piccoli pacchetti JSON.

Sia il client che il motore dovevano avere 2 connessioni aperte: una per la ricezione e una per la trasmissione. Avevamo una serie di messaggi ben definiti per gestire le comunicazioni semplici necessarie:

Ping: messaggio dal client al motore per registrare o fornire una funzione keep-alive. Qualsiasi messaggio dal client al motore è servito a questo scopo.
Pong: messaggio dal motore al client per rispondere e fornire una funzione keep-alive. Qualsiasi messaggio dal motore al client è servito a questo scopo.
Aggiornamento: messaggio dal motore al client di dati di telemetria riepilogati per la visualizzazione.
Comando: messaggio dal client al motore per eseguire un'azione (potrebbe essere la modifica della configurazione, cessare il comando di monitoraggio, avviare il comando di monitoraggio, ecc.)

Le esigenze di questo strumento erano relativamente semplici, quindi non c'era davvero molta riconfigurazione che doveva accadere. La maggior parte dei comandi riguardava la gestione della connessione con il client e la maggior parte dello stato doveva ripristinare l'impostazione predefinita al riavvio del motore comunque.

L'ultima opzione sarebbe quella di incorporare un microservizio JSON (Spring Boot viene in mente) per gestire le esigenze dell'API di configurazione. L'interfaccia utente stessa sarebbe un'app a una sola pagina (SPA) che ha solo bisogno di un file system per servire i file.

score 1 · Answer 2

Per capire qual è la soluzione migliore devi determinare / definire i tuoi requisiti non funzionali.

Alcuni dei requisiti non funzionali potrebbero essere:

Disponibilità (la modifica della configurazione deve essere possibile al 99,9xxx% di un anno).
Sicurezza (la modifica della configurazione deve essere consentita solo agli utenti amministratori)
Tempo in cui la modifica della configurazione diventa effettiva (una modifica della configurazione deve essere effettiva immediatamente dopo aver premuto il pulsante di invio)
Topologie di rete (i servizi demone non devono essere accessibili da Internet / tramite HTTP)
...

Altre cose che influenzano le decisioni di progettazione sono il numero di demoni in esecuzione. Anche i daemon modificano la configurazione? Quante modifiche di configurazione al giorno / secondi / mese hai? Daemon e servizio Web vengono eseguiti sullo stesso computer, ...

Una soluzione molto semplice per il tuo problema è avere un file di configurazione condiviso (database) e l'interfaccia di amministrazione HTTP e un processo Java daemon separato. Se non si desidera estrarre la configurazione per le modifiche, inviare un evento di notifica (RMI, WebSocket, ...) al daemon in modo che sappia quando riconfigurare se stesso.