Dies ist eine offene Frage mit vielen möglichen Antworten, die davon abhängen, was Sie versuchen zu tun. Trotzdem werde ich ein paar Dinge als Antwort hinzufügen, da ein Kommentar nicht groß genug ist.
Der Dienst würde als Datenbankverbindungspool fungieren (ich denke, dass mehr als 2000 Verbindungen in einer Datenbank Probleme verursachen würden);
Ja, das ist eine gute Idee. Sie lassen eine geringere Anzahl von Verbindungen geöffnet und verwenden sie wieder, wenn Anforderungen an den Dienst eingehen. Sie müssen jedoch wissen, wie schnell Anforderungen bearbeitet werden und wie oft jede Anforderung die Datenbank verwendet. Andernfalls kann ein kleiner Pool leicht aufgebraucht werden und andere Anforderungen werden blockiert, während auf die Freigabe einer Datenbankverbindung gewartet wird.
Caching kann dort helfen, bereits abgerufene Daten zurückzugeben (wie gesagt, hängt davon ab, was Sie versuchen - wenn Abfragen eindeutig sind, können Sie nicht viel zwischenspeichern).
Beachten Sie auch, dass die Poolgröße mit der Anzahl der von Ihnen eingerichteten Services multipliziert wird. Ein paar Dienste und Sie können große Datenbankpoolgrößen verwenden; mehr Dienste und Sie müssen die Poolgröße verringern, damit insgesamt die gleiche Anzahl von Verbindungen zur Datenbank geöffnet ist.
Es ist möglich, eine Datenbank mit Protokollversand an eine andere schreibgeschützte Datenbank zu haben, um einige Abfragen zu bearbeiten.
Die Datenbank kann leicht zu Ihrem Engpass werden. Zu viele Verbindungen und / oder zu viele Abfragen und Sie können es brechen. An diesem Punkt spielt es keine Rolle, dass Sie Ihre Dienste horizontal auf eine beliebige Anzahl skalieren können. Alle Anfragen erreichen schließlich dieselbe Datenbank.
Es gibt verschiedene Möglichkeiten, es zu schützen: Caching, das ich bereits erwähnt habe (abhängig von Ihrem Anwendungsfall), Duplizieren einiger Informationen auf anderen Servern, um einige von Ihnen erwähnte Abfragen zu bedienen, CQRS (abhängig von Ihrem Anwendungsfall), Verwenden eines relationalen oder eines nicht relationalen (hängt wieder von Ihrem Anwendungsfall ab) usw.
Beachten Sie jedoch, dass bei der Verteilung solcher Daten das CAP-Theorem angewendet wird. Beachten Sie dies, da Sie möglicherweise Kompromisse zwischen Konsistenz und Verfügbarkeit eingehen müssen.
Es wäre besser skalierbar, da wir mehr Maschinen hinzufügen können, um die REST-Services auszuführen.
Ja, der REST-Service wird skaliert, aber wie oben erwähnt, kann dies leicht zu einem Engpass werden, wenn Sie die Datenbank nicht schützen.
Aus Sicherheits- und Bandbreitenspargründen kann HTTPS mit Komprimierung verwendet werden.
Ja, und andere Dinge ... vielleicht möchten Sie später eine Authentifizierung / Autorisierung usw.
Es ist möglich, einige zentralisierte Änderungen an Geschäftseinheiten vorzunehmen, ohne die über 2000 Computer erneut bereitzustellen.
Ja, aber bis zu einem gewissen Grad und nicht alle Arten von Änderungen. Wenn Sie eine wichtige Änderung vornehmen, müssen Sie auch die Clients aktualisieren. Überlegen Sie sich also eine Strategie, um die Clients auf die neueste Version zu aktualisieren, oder ob Sie älteren Clients erlauben, weiterhin zu arbeiten und die Anwendung zu verwenden.
Es lässt sich besser in andere Systeme integrieren (verweisen Sie einfach auf den REST-Service).
Ja, aber das bedeutet Clients für Ihren Service, die Sie möglicherweise nicht kontrollieren können.
Wenn Sie eine wichtige Änderung vornehmen und eine gute Strategie zum Aktualisieren Ihrer über 2000 JavaFX-Clients haben, ist dies kein Problem. Wenn jedoch andere Clients vorhanden sind und Sie keine Kontrolle über sie haben, müssen Sie möglicherweise die Versionierung im REST-Service implementieren und mehr als eine Version unterstützen, bis alle auf die neueste Version aktualisieren können.
Wie ich schon sagte, es hängt davon ab, was Sie versuchen zu tun. Insgesamt ist Ihre eine gute Idee. Beachten Sie jedoch, dass Inhalte nicht kostenlos sind, nur weil Sie einen REST-Service vor eine Datenbank stellen.
Nur meine 2 Cent!