Это открытые вопросы с множеством возможных ответов, которые зависят от того, что вы пытаетесь сделать. Тем не менее я добавлю несколько вещей в качестве ответа, так как комментарий не будет достаточно большим.
Служба будет действовать как пул соединений с базой данных (я думаю, что более 2000 соединений с базой данных вызовут проблемы);
Да, что это хорошая идея. Вы держите меньшее количество открытых соединений и используете их по мере поступления запросов в службу. Но вам нужно знать, как быстро будут обрабатываться запросы и насколько каждый запрос использует базу данных, в противном случае небольшой пул может быть легко истощен, а другие запросы будут заблокированы во время ожидания соединения с базой данных.
Кэширование может помочь в этом, чтобы вернуть уже извлеченные данные (как я уже сказал, зависит от того, что вы пытаетесь сделать - если запросы уникальны, вы не можете много кешировать).
Также обратите внимание, что размер пула будет умножен на количество услуг, которые вы используете. Несколько сервисов, и вы можете использовать пулы баз данных большого размера; больше сервисов, и вам нужно уменьшить размер пула, чтобы в целом количество открытых соединений с базой данных было одинаковым.
Для обслуживания некоторых запросов можно иметь базу данных с доставкой журналов в другую базу данных только для чтения;
База данных может легко стать вашим узким местом. Слишком много соединений и / или слишком много запросов, и вы можете разорвать его. На этом этапе не имеет значения, что вы можете масштабировать свои услуги по горизонтали до любого числа. Все запросы в конечном итоге попадут в одну базу данных.
Существуют различные способы защиты: кэширование, о котором я уже упоминал (зависит от вашего варианта использования), дублирование некоторой информации на других серверах для обслуживания некоторых запросов, как вы упомянули, CQRS (зависит от вашего варианта использования), использование реляционных и нереляционных (снова зависит от вашего варианта использования) и т. д.
Обратите внимание, что когда вы распространяете такие данные, теорема CAP начинает применяться. Помните об этом, поскольку вам может потребоваться компромисс между согласованностью и доступностью.
Это будет лучше масштабироваться, поскольку мы можем добавить больше машин для запуска сервисов REST;
Да, служба REST будет масштабироваться, но, как я упоминал выше, если вы не защитите базу данных, это может стать узким местом.
Возможно использование HTTPS со сжатием в целях безопасности и экономии пропускной способности;
Да, а также другие вещи ... может быть, вы хотите аутентификацию / авторизацию позже и т. Д.
Можно внести некоторые централизованные изменения в бизнес-объекты без повторного развертывания компьютеров 2000+;
Да, но в определенной степени и не все виды изменений. Если вы вносите критические изменения, вам также необходимо обновить клиентов. Поэтому подумайте о стратегии обновления клиентов до последней версии или если вы разрешите старым клиентам работать и использовать приложение.
Он лучше интегрируется с другими системами (просто укажите на службу REST).
Да, но это означает, что клиенты для вашего сервиса, возможно, вы не можете контролировать.
Если вы делаете серьезные изменения и у вас есть хорошая стратегия для обновления 2000+ JavaFX-клиентов, то нет проблем. Но если существуют другие клиенты, и вы не можете контролировать их, вам может потребоваться реализовать управление версиями в службе REST и поддерживать более одной версии, пока каждый не сможет обновить ее до последней версии.
Как я уже сказал, это зависит от того, что вы пытаетесь сделать. В общем, ваша хорошая идея. Но имейте в виду, что вещи не будут бесплатными только потому, что вы размещаете службу REST перед базой данных.
Просто мои 2 цента!