Implementazione dell'heartbeat utilizzando l'API REST

Is it good enough to just define a REST end-point (say ping) which will return the status of the server and API? The client side will call this REST API every few seconds.

Dipende. È importante associare frequenza a concorrenza perché una manciata di client che eseguono ping sul server potrebbe non causare un carico evidente sul lato server, ma centinaia o migliaia di clienti potrebbero. Immagina 1000, 10000, 100000 client che eseguono la stessa richiesta ogni 3 secondi. È probabile che il picco faccia sudare il tuo server. Quindi fai attenzione.

Le connessioni HTTP sono costose da eseguire su entrambi i lati, affidabili ma lente e complessive, stanno bloccando le comunicazioni I / O . Qualcosa che devi mitigare se il tuo sistema è esposto a una concorrenza frequente e alta. Ad ogni modo, se il numero di client che consumano l'endopoint è basso (quindi la concorrenza), come ha commentato @JimmyJames, una soluzione RESTful è più che sufficiente. È affidabile, sicuro e scalabile perfettamente.

D'altro canto, le comunicazioni Websockets non bloccano l'I / O, ma funzionano abbastanza bene con una concorrenza elevata in cui server e client scambiano poche informazioni e il tempo di elaborazione su entrambi i lati è breve. Questo è il caso dei battiti del cuore.

Inoltre, Websockets implementa un protocollo "Ping-Pong" all'interno del suo "quadro di controllo" attraverso il quale è possibile ottenere lo stesso risultato. Per ulteriori informazioni, consulta la RFC .

A mio parere, se implementare WebSockets o endpoint REST HTTP, dipenderà dal fatto che ci si aspetta una concorrenza elevata e la sua frequenza (in questo caso, ogni 3 secondi).

Vorrei prendere in considerazione un paio di volte:

• se i client possono (o non possono) adottare nuovi protocolli di comunicazione. Se non possono, non c'è spazio per la discussione.

• se l'infrastruttura consente di esporre WebSockets. Ho lavorato per i clienti con regole molto rigide, laddove nulla, tranne SMTP, SFTP, HTTPS e altri protocolli non erano consentiti. Quindi, prendilo anche in considerazione.

Diciamo ora, ci aspettiamo ancora una concorrenza elevata ma, per qualche ragione, decidiamo che websockets è un no.

Se mi venisse richiesto di farlo in questo modo, preferirei che il server "spingesse" il suo stato da qualche parte a un ritardo fisso. Quindi sposterei la responsabilità di esporre lo stato a un altro servizio in grado di implementare l'I / O asincrono e il capble per esporre gli endpoint REST HTTP (come ad esempio un servizio Web NodeJS).

Vorrei reindirizzare le richieste a questo nuovo servizio. Vorrei dire ai clienti di mantenere l'ultimo stato recuperato. Se lo stato non cambia in ulteriori richieste, significa che il servizio non sta aggiornando il suo stato e qualcosa di sbagliato sta andando sul lato server. Questo approccio si adatta bene poiché è possibile mantenere lo stato di diversi servizi senza influire sulle rispettive prestazioni e tracciare ciascuno di essi, nel suo insieme o indipendentemente, da un singolo endpoint.

La mia opinione è che dovresti limitarti a REST. Non c'è bisogno di aggiungere un altro protocollo / tecnologia con tutti i potenziali problemi che ne derivano, mentre non hai nemmeno bisogno di alcuna funzionalità da WebSockets. Inoltre questa soluzione rimane il più vicino possibile all'API reale. Esiste (a seconda dell'implementazione) una piccola possibilità che il WebSocket rimanga aperto mentre la API REST non accetta alcuna nuova richiesta.

Anche una parte della tecnologia abbastanza collaudata, chiamata Spring Actuator, funziona anche su endpoint REST, anche se questo fa ben più che controllare i battiti del cuore.

Sono d'accordo con @Laiv e gli ho dato un +1, ma vorrei aggiungere un po 'di esercizio di riflessione per te.

Che cosa dovrebbe dirti il battito cardiaco e chi dovrebbe controllarlo?

So che pensi di aver risposto alla prima domanda, ma non proprio.

Hai detto "per monitorare il servizio e la disponibilità dell'API". Questo include solo i processi API effettivi? O vuoi dire da una prospettiva di applicazione consumante? Se l'API supporta e funziona, ma un client non può colpirlo perché il firewall o il bilanciamento del carico non sono configurati correttamente, è qualcosa che dovrebbe interrompere l'heartbeat? Che cosa succede se il carico viene bilanciato su più server, ti interessa che uno sia inattivo, ma due sono attivi? Che cosa succede se la tua API dipende da elementi a monte come un database o un servizio di terze parti, anche l'heartbeat controlla tutto questo?

Per quanto riguarda la domanda "who", vuoi che tutti i tuoi clienti colpiscano il servizio heartbeat e controllino la tua disponibilità, o è qualcosa per te da tenere d'occhio? Quante informazioni vuoi che il battito cardiaco esporti a loro?

Nel complesso, non sono d'accordo con il principio di un servizio heartbeat che viene gestito e mantenuto in modo specifico nella maggior parte dei casi. Non riesco ad ottenere abbastanza dalla tua domanda per verificare se la tua è una delle eccezioni, ma in generale preferirei una registrazione robusta e un aggregatore di registri come ElasticStack o NewRelic per fornire il monitoraggio e se voglio davvero provarlo, roba sta funzionando end-to-end dal punto di vista dei clienti, lo farei contro uno o più endpoint GET esistenti, o anche solo su client di installazione in grado di eseguire alcuni set di test di integrazione regolarmente per colpire più endpoint chiave (con tracciabilità a " prova "account per ripulire eventuali artefatti), ma non dovrebbe essere ogni 3 minuti (né è necessario che sia se l'infrastruttura di logging è configurata correttamente).