2000以上のクライアントマシンのアプリケーションサーバーとしてのRESTサービス。それは良い考えですか？

2000以上のマシンにデプロイされるjavaFxのUIを使用してシステムを構築します（最小は2000ですが、さらに多くなります-5000台のマシンに到達できます）。

他の理由/制限のため、マシンにインストールする必要があるため、Webブラウザーインターフェイスでは実行できません。

2000台以上のマシンは、異なる地理的ロケーショングループに属します。一般に接続は良好ですが、より多くの遠隔地ではそれほど良好ではない場合があります。

データベースに直接アクセスする代わりに、Spring + Spring Boot + Spring Data（java）を使用してRESTサービスクラスターを構築することを考えています。

RESTサービスはJsonを受け入れて返します。

私はそれが良い考えだと思う：

• サービスはデータベース接続プールとして機能します（データベースで2000以上の接続を行うと問題が発生すると思います）。
• 一部のクエリを処理するために、他の読み取り専用データベースへのログ配布を備えたデータベースを使用することができます。
• より多くのマシンを追加してRESTサービスを実行できるため、スケーラビリティが向上します。
• セキュリティおよび帯域幅節約の理由で、圧縮されたHTTPSを使用することができます。
• 2000以上のマシンを再デプロイせずに、ビジネスエンティティに集中的な変更を加えることができます。
• 他のシステムとの統合性が向上します（RESTサービスをポイントするだけです）。

それは本当に良いアイデアですか？

肯定的または否定的な経験を共有できますか？

ありがとうございました。

これは、あなたがやろうとしていることに依存する可能性のある応答がたくさんある自由回答形式の質問です。それにもかかわらず、コメントは十分に大きくないので、答えとしていくつかのことを追加します。

サービスはデータベース接続プールとして機能します（データベースで2000以上の接続を行うと問題が発生すると思います）。

はい、それは良い考えです。少数の接続を開いたままにして、リクエストがサービスに到着するときにそれらを再利用します。ただし、リクエストの処理速度と各リクエストがデータベースを使用する量を知る必要があります。そうしないと、小さなプールが簡単に使い果たされ、他のリクエストがデータベース接続の解放を待つ間にブロックされます。

既に取得したデータを返すには、キャッシュが役立ちます（先ほど言ったように、何をしようとしているかに依存します-クエリが一意である場合、あまりキャッシュできません）。

また、プールサイズには、配置したサービスの数が乗算されることに注意してください。いくつかのサービスと大きなデータベースプールサイズを使用できます。より多くのサービスがあるため、プールサイズを小さくする必要があります。そのため、データベースに対して開かれる接続の数が全体的に同じになります。

一部のクエリを処理するために、他の読み取り専用データベースへのログ配布を備えたデータベースを使用することができます。

データベースは簡単にボトルネックになる可能性があります。接続が多すぎたり、クエリが多すぎたり、それを破ることができます。その時点で、サービスを任意の数に水平にスケーリングできるかどうかは関係ありません。すべての要求は、最終的に同じデータベースに到達します。

それを保護するためのさまざまな方法があります：既に述べたキャッシング（ユースケースに依存）、他のサーバーにいくつかの情報を複製してあなたが言及するいくつかのクエリを提供する、CQRS（ユースケースに依存）、リレーショナルvs非リレーショナルを使用します（ユースケースに再び依存します）など。

ただし、そのようなデータを配布すると、CAP定理が適用され始めることに注意してください。一貫性と可用性の間で妥協する必要がある場合があることに注意してください。

より多くのマシンを追加してRESTサービスを実行できるため、スケーラビリティが向上します。

はい、RESTサービスはスケーリングされますが、前述したように、データベースを保護しないと、簡単にボトルネックになる可能性があります。

セキュリティおよび帯域幅節約の理由で、圧縮されたHTTPSを使用することができます。

はい、他のものと同様に...多分あなたは後で認証/許可などをしたいかもしれません

2000以上のマシンを再デプロイせずに、ビジネスエンティティに集中的な変更を加えることができます。

はい、ただし、ある程度までであり、すべての種類の変更ではありません。重大な変更を行う場合は、クライアントも更新する必要があります。したがって、クライアントを最新バージョンに更新する戦略を検討するか、古いクライアントが引き続きアプリケーションを使用して使用できるようにする場合を考えてください。

他のシステムとの統合性が向上します（RESTサービスをポイントするだけです）。

はい、しかしそれはあなたがコントロールできないかもしれないあなたのサービスのクライアントを意味します。

重大な変更を行い、2000 + JavaFXクライアントを更新するための優れた戦略があれば問題ありません。ただし、他のクライアントが存在し、それらを制御できない場合は、RESTサービスにバージョン管理を実装し、全員が最新に更新できるようになるまで複数のバージョンをサポートする必要があります。

私が言ったように、それはあなたが何をしようとしているかに依存します。全体的に、あなたのものは良い考えです。ただし、RESTサービスをデータベースの前に置いたからといって、無料のものは提供されないことに注意してください。

ちょうど私の2セント！