web-dev-qa-db-ja.com

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

2000以上のマシンにデプロイされるjavaFxのUIを備えたシステムを構築します（最低でも2000ですが、それ以上になります-5000マシンに到達できます）。

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

2000以上のマシンは、地理的に異なる場所のグループに配置されます。一般的に接続は良好ですが、離れた場所ではそれほど良好ではない場合があります。

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

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

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

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

本当にいいアイデアですか？

プラスまたはマイナスの経験を共有できますか？

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

javadesignrestspring
11
Thiago Sayão

これは自由回答形式の質問であり、何をしようとしているかに応じてさまざまな回答が可能です。それでも、コメントが十分に大きくないため、いくつかのことを回答として追加します。

サービスはデータベース接続プールとして機能します（データベースへの2000以上の接続は問題を引き起こすと思います）。

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

キャッシュは、既にフェッチしたデータを返すために役立ちます（前述のように、何をしようとしているのかによって異なります。クエリが一意の場合は、あまりキャッシュできません）。

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

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

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

それを保護するさまざまな方法があります：私がすでに述べたキャッシング（ユースケースによって異なります）、他のサーバーにいくつかの情報を複製して、あなたが述べたようにいくつかのクエリを処理します [〜＃〜] cqrs [〜＃〜] （ユースケースによって異なります）、リレーショナルvs非リレーショナルを使用します（ユースケースによって異なります）など。

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

より多くのマシンを追加してRESTサービス;

はい、RESTサービスはスケーリングしますが、前述のように、データベースを保護しないと、ボトルネックになりやすくなります。

セキュリティと帯域幅の節約のために、HTTPSと圧縮を併用することが可能です。

はい、他のことも...後で認証/承認が必要な場合など.

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

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

他のシステムとよりよく統合されます（RESTサービスをポイントするだけです）。

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

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

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

ちょうど私の2セント！

3
Bogdan