2

私たちの Rails 3 アプリケーションのアーキテクチャーに関する意見を聞きたいと思っていました。

現在、Rails 3.0.7 アプリケーションを使用して、テレビに表示されるコンテンツ (プロモーション、ビデオ、メニュー、スポーツ統計など) を、接続されたメディア デバイスの 1 つを介してユーザーが管理できるようにしています。これらの接続されたデバイスは 1000 を超え (さらに増え続けています)、毎分システムをポーリングしてコンテンツの変更をチェックし、15 分ごとに統計情報 (CPU、メモリなど) を報告します。

私たちのシステムの主な利点の 1 つは、管理者として、個々のコンテンツ アイテムの外観/動作を変更し、それを使用するすべてのデバイスに配布できることです。この機能の欠点は、変更を加えると、接続されているすべてのデバイスがほぼ同時に更新を要求するため、システムが一時的に使用できなくなることです。

そのため、アプリケーションを再構築してコンテンツ管理を行う予定です。デバイスがアプリケーションと通信している場合、システムは影響を受けません。この問題を解決するには、おそらく数十の方法があります。1 つの方法は、デバイスが表示する必要があるコンテンツを取得するためだけの別の Rails アプリケーションを用意することです。管理者は監視できます。モデル、データベースなどを現在のコンテンツ管理と共有できます。システム。この方法では、モデルや移行などの管理が困難になる可能性があります。明らかに、モデルを複製したくありません。また、コンテンツの管理が理想的です。システムは引き続きアカウントのデバイスのステータスを表示できるため、アカウント管理者はデバイスがオンラインかどうかなどを確認できます。

resque/redis のようなある種のキュー メカニズムが適していると考えています。システムでは、デバイス インスタンスが取得して処理できるジョブをキューに入れることができます。

これをコミュニティに公開して、コネクテッド デバイスを活用するシステムに取り組んでいた、または現在も取り組んでいる他の人々から意見やアイデアを得たいと思いました。ご協力いただきありがとうございます。それは有り難いです!

ルイ

4

1 に答える 1

0

~1 要件の 1000 以上のクライアント。毎分ごとに、通常の操作のためにアーキテクチャの変更を必要とする負荷のようには聞こえません。一般に、単純な 1 つのアプリのアーキテクチャは、長期的には保守が容易になるため、解決できない問題が発生するまで、このアーキテクチャに固執するようにしてください。

パフォーマンス/応答性が主な問題である場合、キャッシング プロキシ サーバーをスタックに追加してみませんか?

その他の簡単なオプションは、アプリを 2 つのサーバーにインストールし、1 つを管理用に、もう 1 つをクライアント デバイス用に使用することです。これは、データベースがボトルネックでない場合にのみ役立つことに注意してください。

于 2012-04-04T23:58:48.237 に答える