To są pytania otwarte z mnóstwem możliwych odpowiedzi, które zależą od tego, co próbujesz zrobić. Niemniej jednak dodam kilka rzeczy jako odpowiedź, ponieważ komentarz nie będzie wystarczająco duży.
Usługa działałaby jak pula połączeń z bazą danych (myślę, że 2000+ połączeń z bazą danych spowodowałoby problemy);
Tak, to dobry pomysł. Utrzymujesz mniejszą liczbę otwartych połączeń i używasz ich ponownie, gdy żądania docierają do usługi. Ale musisz wiedzieć, jak szybko będą obsługiwane żądania i ile każde żądanie wykorzystuje bazę danych, w przeciwnym razie mała pula może zostać łatwo wyczerpana, a inne żądania zostaną zablokowane podczas oczekiwania na połączenie z bazą danych.
Buforowanie może pomóc w zwróceniu już pobranych danych (tak jak powiedziałem, zależy od tego, co próbujesz zrobić - jeśli zapytania są unikalne, nie możesz dużo buforować).
Pamiętaj również, że rozmiar puli zostanie pomnożony przez liczbę wprowadzonych usług. Kilka usług i możesz użyć dużych rozmiarów pul bazy danych; więcej usług i musisz zmniejszyć rozmiar puli, aby ogólnie rzecz biorąc mieć taką samą liczbę połączeń z bazą danych.
Możliwe jest posiadanie bazy danych z dziennikiem wysyłanym do innej bazy danych tylko do odczytu w celu obsługi niektórych zapytań;
Baza danych może łatwo stać się wąskim gardłem. Zbyt wiele połączeń i / lub zbyt wiele zapytań i możesz je przerwać. W tym momencie nie ma znaczenia, że możesz skalować w poziomie swoje usługi do dowolnej liczby. Wszystkie żądania w końcu dotrą do tej samej bazy danych.
Istnieją różne sposoby jej ochrony: buforowanie, o którym już wspomniałem (zależy od przypadku użycia), powielanie niektórych informacji na innych serwerach w celu obsługi niektórych zapytań, jak wspomniałeś, CQRS (zależy od przypadku użycia), użyj relacji relacyjnej vs nierelacyjnej (zależy ponownie od przypadku użycia) itp.
Zauważ jednak, że kiedy dystrybuujesz takie dane, zacznie obowiązywać twierdzenie CAP . Pamiętaj o tym, ponieważ może być konieczne kompromis między spójnością a dostępnością.
Skalowałoby się lepiej, ponieważ możemy dodać więcej maszyn do obsługi usług REST;
Tak, usługa REST będzie skalowana, ale jak wspomniałem powyżej, jeśli nie zabezpieczysz bazy danych, może to łatwo stać się wąskim gardłem.
Możliwe jest użycie HTTPS z kompresją ze względów bezpieczeństwa i oszczędności pasma;
Tak, a także inne rzeczy ... może chcesz później uwierzytelnić / autoryzację itp.
Możliwe jest wprowadzenie scentralizowanych zmian w jednostkach biznesowych bez ponownego wdrażania ponad 2000 maszyn;
Tak, ale do pewnego stopnia i nie wszystkie rodzaje zmian. Jeśli dokonasz przełomowej zmiany, musisz także zaktualizować klientów. Pomyśl więc o strategii aktualizacji klientów do najnowszej wersji lub jeśli pozwolisz starszym klientom nadal działać i korzystać z aplikacji.
Lepiej integruje się z innymi systemami (wystarczy skierować go na usługę REST).
Tak, ale to oznacza klientów dla Twojej usługi, których być może nie możesz kontrolować.
Jeśli dokonujesz przełomowej zmiany i masz dobrą strategię aktualizacji ponad 2000 klientów JavaFX, nie ma problemu. Ale jeśli istnieją inni klienci i nie masz nad nimi kontroli, może być konieczne wdrożenie kontroli wersji w usłudze REST i obsługa więcej niż jednej wersji, dopóki wszyscy nie będą mogli zaktualizować do najnowszej wersji.
Tak jak powiedziałem, zależy to od tego, co próbujesz zrobić. Ogólnie rzecz biorąc, twój jest dobrym pomysłem. Ale pamiętaj, że rzeczy nie przyjdą za darmo tylko dlatego, że przyklejasz usługę REST przed bazą danych.
Tylko moje 2 centy!