私のスタートアップは、オンライン/モバイル労働市場を構築しています。そこには、企業が仕事を掲載するためのビジネス インターフェースがあり、これらの仕事をモバイル インターフェースを介してユーザーに配布しています。Rails、REST、Amazon RDS & EC2、mysql を使用しています。
私の質問は: サーバー側のアーキテクチャの観点から、それは理にかなっていますか?:
a) 2 つのアプリケーションを用意し、1 つは Web インターフェースを提供し、もう 1 つはモバイル インターフェースのサーバー側 (API) として機能し、両方とも DB および 2 つの異なる EC2 インスタンスを介して通信します。
b) 両方のインターフェースを提供する 1 つの包括的なアプリケーションの構築を試みる
賛否両論についての意見や見方は大歓迎です
ありがとう
全体的な目標は、モバイルアプリケーションとWebアプリケーションの間で最も多くのコードを共通にすることです。それ以外の場合は、バグの修正や、少なくとも2か所での機能の追加などのメンテナンスの問題が発生します。
理想的には、フロントエンドの下のすべてが共通である必要があります。Web UI自体が、モバイルアプリケーションに必要なサーバー側APIを呼び出す必要があります。また、ほとんどのロジックをこれらのAPIに配置し、プレゼンテーションの詳細のみをUIに残す必要があります。これは、MVCなどの多くのパターンで規定されているとおりです。
私は自分で実行しているモバイルサイトとデスクトップサイトを持っています。コードベースはPHPレベルでもまったく同じです。スマートなテンプレートだけが2つの間で異なります。モバイルアプリケーションはモバイルサイトとは異なりますが、基本的な原則は引き続き適用されます。
アマゾン ウェブ サービスは、システムをより小さくシンプルで独立したコンポーネントに分解する場合に、アーキテクチャをよりシンプルで堅牢でスケーラブルにするためのいくつかのツールを提供しています。
マイクロからエクストララージ (およびいくつかのサイズのエクストララージ) まで、さまざまなサイズのインスタンスが設定されているため、各サービスタイプを適切なサイズ、構成、ソフトウェアの依存関係、更新サイクルなどに柔軟に組み合わせることができます。開発者、テスター、および管理者の生活がはるかに楽になります。
また、各レイヤーとサービスを個別にスケーリングおよび自動スケーリングすることもできます。どちらか一方のインターフェイスのユーザーが増えた場合、またはインターフェイスの 1 つを介して供給されるデータ サイズが増加した場合は、関連するサービスのみをスケーリングできます。これにより、システム全体を全体としてスケーリングする複雑さとコストを節約できます。
AWS のもう 1 つの特徴は、ニーズに基づいてスケールアップ、ダウン、アウト、およびインできることです。たとえば、いずれかのインターフェイスのユーザー数が平日に多く、週末には少ない場合、このインターフェイスを週末または夜間にスケールダウンして、このインスタンスの計算コストを 50% 節約できます。この点で、より静的なインターフェイスのオンデマンド モデルから予約済みインスタンスに切り替えることで、コストを 50% 節約できます。
異なるインターフェース間の通信を可能にするために DB を使用できますが、ユースケースに基づいてさらにいくつかのオプションがあります。1 つのオプションは、キューイング システムをSQSとして使用することです。キューはインターフェイス間のバッファとして使用され、1 つのコンポーネントの障害 (ソフトウェアのバグ、ハードウェアの障害など) のリスクを軽減し、システム全体に影響を与えます。インターフェイス間通信のもう 1 つのオプションは、パフォーマンスに合わせて調整され、メモリ内キャッシュを使用することです。AWS は、そのようなサービスとしてElasticCacheを提供しています。このような一時的なデータを短期間かつ高負荷で更新するよりも効率的です。
1 台のマシンに 1 つのサービスをすばやく (そしてダーティに) 実装する以外に、長期的な短所はないと思います。