Questa è una domanda aperta con un sacco di possibili risposte che dipendono da ciò che stai cercando di fare. Tuttavia aggiungerò alcune cose come risposta, poiché un commento non sarà abbastanza grande.
The service would act as a database connection pool (I think 2000+ connections on a database would cause problems);
Sì, è una buona idea. Mantieni aperto un numero ridotto di connessioni e le riutilizzi man mano che le richieste arrivano al servizio. Ma è necessario sapere con quanta rapidità saranno fornite le richieste e quanto ogni richiesta usa il
database, altrimenti un piccolo pool può essere facilmente esaurito e altre richieste verranno bloccate mentre si attende il rilascio di una connessione al database.
Il caching può aiutare lì, per restituire dati già recuperati (come ho detto, dipende
su cosa stai cercando di fare - se le query sono uniche non puoi memorizzare molto nella cache).
Si noti inoltre che le dimensioni del pool verranno moltiplicate per il numero di servizi che vengono installati. Alcuni servizi ed è possibile utilizzare dimensioni di pool di database di grandi dimensioni; più servizi ed è necessario ridurre la dimensione del pool, in modo da avere lo stesso numero di connessioni aperte al database, nel complesso.
It is possible to have a database with log shipping to other read-only database to serve some queries;
Il database può facilmente diventare il collo di bottiglia. Troppe connessioni e / o troppe query e puoi romperle. A quel punto non importa che puoi scalare orizzontalmente i tuoi servizi su qualsiasi numero. Tutte le richieste lo faranno
alla fine raggiungere lo stesso database.
Ci sono vari modi per proteggerlo: il caching che ho già menzionato (dipende dal tuo caso d'uso), duplica alcune informazioni su altri server per servire alcune query come dici, CQRS (dipende dal tuo caso d'uso), usa un rapporto relazionale vs non relazionale (dipende di nuovo dal tuo caso d'uso), ecc.
Nota che quando distribuisci dati del genere, inizia a essere applicato il teorema CAP . Siate consapevoli di ciò poiché potrebbe essere necessario un compromesso tra coerenza e disponibilità.
It would scale better as we can add more machines to run the REST services;
Sì, il servizio REST si ridimensionerà, ma come detto sopra, se non proteggi il database, questo può facilmente diventare un collo di bottiglia.
It is possible to use HTTPS with compression for security and bandwidth saving reasons;
Sì, così come altre cose ... forse vuoi un'autenticazione / autorizzazione più tardi, ecc.
It is possible to make some centralized changes on business entities without redeploying the 2000+ machines;
Sì, ma fino a un certo limite e non tutti i tipi di modifiche. Se si apportano modifiche di rottura, è necessario aggiornare anche i client. Quindi pensa a una strategia per aggiornare i client alla versione più recente o se permetti ai client più vecchi di continuare a lavorare e utilizzare l'applicazione.
It integrates better with other systems (just point it to the REST service).
Sì, ma ciò significa che i clienti per il tuo servizio potrebbero non essere controllati.
Se si apportano cambiamenti improvvisi e si dispone di una buona strategia per aggiornare i client JavaFX 2000+, nessun problema. Ma se esistono altri client e tu non hai
controllandoli, potrebbe essere necessario implementare il controllo delle versioni sul servizio REST e supportare più di una versione fino a quando tutti potranno aggiornarsi al più tardi.
Come ho detto, dipende da cosa stai cercando di fare. Nel complesso, la tua è una buona idea. Ma sappi che roba non arriverà gratis solo perché tieni un servizio REST davanti a un database.
Solo i miei 2 centesimi!