Il s'agit d'une question ouverte avec de nombreuses réponses possibles qui dépendent de ce que vous essayez de faire. Néanmoins, je vais ajouter quelques éléments comme réponse, car un commentaire ne sera pas assez volumineux.
Le service agirait comme un pool de connexions de base de données (je pense que plus de 2000 connexions sur une base de données causeraient des problèmes);
Oui, c'est une bonne idée. Vous gardez un plus petit nombre de connexions ouvertes et vous les réutilisez à mesure que les demandes arrivent au service. Mais vous devez savoir à quelle vitesse les demandes seront traitées et combien chaque demande utilise la base de données, sinon un petit pool peut facilement être épuisé et d'autres demandes seront bloquées en attendant qu'une connexion à la base de données soit libérée.
La mise en cache peut y aider, pour renvoyer des données déjà récupérées (comme je l'ai dit, cela dépend de ce que vous essayez de faire - si les requêtes sont uniques, vous ne pouvez pas mettre en cache beaucoup).
Notez également que la taille du pool sera multipliée par le nombre de services que vous mettez en place. Quelques services et vous pouvez utiliser de grandes tailles de pool de bases de données; plus de services et vous devez réduire la taille du pool, afin d'avoir globalement le même nombre de connexions ouvertes à la base de données.
Il est possible d'avoir une base de données avec envoi de journaux vers une autre base de données en lecture seule pour répondre à certaines requêtes;
La base de données peut facilement devenir votre goulot d'étranglement. Trop de connexions et / ou trop de requêtes et vous pouvez les interrompre. À ce stade, peu importe que vous puissiez adapter horizontalement vos services à n'importe quel nombre. Toutes les demandes finiront par atteindre la même base de données.
Il existe différentes façons de le protéger: la mise en cache que j'ai déjà mentionnée (dépend de votre cas d'utilisation), dupliquer des informations sur d'autres serveurs pour servir certaines requêtes comme vous le mentionnez, CQRS (dépend de votre cas d'utilisation), utiliser un relationnel vs non relationnel (dépend à nouveau de votre cas d'utilisation), etc.
Notez cependant que lorsque vous distribuez des données comme celles-ci, le théorème CAP commence à s'appliquer. Soyez conscient de cela car vous devrez peut-être faire un compromis entre cohérence et disponibilité.
Cela évoluerait mieux car nous pouvons ajouter plus de machines pour exécuter les services REST;
Oui, le service REST évoluera, mais comme je l'ai mentionné ci-dessus, si vous ne protégez pas la base de données, cela peut facilement devenir un goulot d'étranglement.
Il est possible d'utiliser HTTPS avec compression pour des raisons de sécurité et d'économie de bande passante;
Oui, ainsi que d'autres choses ... peut-être que vous voulez une authentification / autorisation plus tard, etc.
Il est possible d'effectuer des modifications centralisées sur les entités commerciales sans redéployer les machines 2000+;
Oui, mais dans une certaine mesure et pas toutes sortes de changements. Si vous effectuez un changement de rupture, vous devrez également mettre à jour les clients. Pensez donc à une stratégie pour mettre à jour les clients vers la dernière version ou si vous autorisez les anciens clients à continuer à travailler et à utiliser l'application.
Il s'intègre mieux avec d'autres systèmes (il suffit de le pointer vers le service REST).
Oui, mais cela signifie des clients pour votre service que vous ne pouvez peut-être pas contrôler.
Si vous effectuez un changement de rupture et que vous avez une bonne stratégie pour mettre à jour vos clients JavaFX 2000+, aucun problème. Mais si d'autres clients existent et que vous n'avez aucun contrôle sur eux, vous devrez peut-être implémenter le contrôle de version sur le service REST et prendre en charge plusieurs versions jusqu'à ce que tout le monde puisse mettre à jour avec la dernière version.
Comme je l'ai dit, cela dépend de ce que vous essayez de faire. Dans l'ensemble, la vôtre est une bonne idée. Mais sachez que ce ne sera pas gratuit simplement parce que vous collez un service REST devant une base de données.
Juste mes 2 cents!