6

私は、Azure ベースのアプリケーションの設計の初期段階にいます。私が Azure に惹かれる理由の 1 つは、予想される需要の変動性を考えると、スケーラビリティです。そのため、必要に応じてインスタンスを追加できるように、物事を疎結合に保つようにしています。

Azure 用のアプリケーションを設計する際に私が目にした推奨事項には、Web ロール ロジックを最小限に抑えること、worker ロールで処理を実行すること、通信にキューを使用すること、SQL Azure や Azure Tables などのバックエンド ストアを使用することが含まれます。アプリケーションのいずれかまたは両方の部分を問題なくスケールアップできるので、これは良い考えのように思えます。ただし、キューでデータを送信するのではなく、Web ロールをデータ ストアと直接通信させるのが最適な場合のベスト プラクティスがあるかどうか (または誰かが経験を持っている場合) に興味がありますか?

Web ロールから簡単な挿入を行うケースを考えています。これをメッセージとして設定し、キューに送信して、worker ロールにピックアップさせて挿入させることもできますが、ダブルハンドリングが多いようです。ただし、Web ロールが圧倒されたり、より複雑なロジックが挿入に必要になったりした場合に備えて、長期的にはこれがより良い場合があることも理解しています。

これは、答えが「完全に状況に依存するため、パフォーマンス メトリックを確認してください」である場合があることは承知しています。

4

3 に答える 3

5

これが私の比喩です、あなたがそれですることをしてください

危険なエリアに隣接するナイトクラブに入っていると想像してみてください。しかし、中に入ると大丈夫です。

経営陣は、リフラフを整理するためにドアにいくつかの大きな肉付きの良い用心棒を採用しています。あなたがばかなら、あなたは入りません。ここで好きなだけ比喩を拡張してください。

あなたが大丈夫なら、彼らはあなたをドアに入れさせます、そしてあなたはそうです、実際のクラブに入るために興行収入で支払うためにキューに参加します。

フットボールがオンか何かに応じて、ドアにもう少し用心棒が必要な場合がありますが、これは興行収入のスタッフから独立している場合があります。忙しい夜、あなたはより速くお金を手に入れるために別の窓を開けるかもしれません、しかしあなたがおそらくあなたがするつもりはないことは用心棒に現金を処理させるでしょう。彼らは自分たちの手で他のことをしている。

それで：

  • バウンサー-Webロール。着信トラフィックを処理し、無効なリクエストを撃退し、有効なリクエストを次の場所に追加します。
  • キュー-キュー！
  • 興行収入-労働者の役割、ウェブの役割とは異なる役割を実行する

したがって、Webの役割が興行収入の役割を果たせない理由はありませんが、長期的にはおそらく最善ではありません。

それが私の比喩です

トビー

于 2010-03-16T11:52:46.607 に答える
3

挿入のようなものはワーカーの役割を必要としません。いずれにせよ、キューへの挿入があるため、Web ロールには何も保存されません。最善の方法は、挿入 (およびすべてのデータ アクセス) を Web ロール内の別のクラス (または複数のクラス) に分離することです。これにより、Web ロールの残りのコードを、使用している特定のデータ ストレージ システムから切り離すことができます。これにより、後でデータ ストアを簡単に変更できます。挿入にさらに処理が必要になった場合は、必要に応じてキューとワーカー ロールを追加できますが、テーブル ストレージへの挿入を直接実行してから、計算やその他のビジネス ロジックを労働者の役割。

ワーカー ロールと通信するためにキューを使用する方法が最も効果的であると私が考える方法は、データを使用して実行する必要がある計算またはその他の処理がある場合です。私が最もよく使用しているのは、実際には Azure SDK のサンプルの 1 つで、サムネイル画像の作成方法を示しています。私の Web ロールは、アップロードされた画像を A​​zure BLOB ストレージに挿入し、関連する説明とその他のフィールドを Azure テーブル ストレージに挿入します。また、サムネイルを生成する必要がある新しい画像があることを worker ロールに知らせるメッセージをキューに配置します。実際には、サイトのさまざまな部分で使用するために、各画像のいくつかの異なるサイズを生成します。Worker ロールはこれらのサムネイルを生成するだけで、Web ロールに何らかの通知を送信する必要はありません。

キューを完全にスキップしたい場合は、この同じプロセスで、BLOB ストレージに対するクエリを使用して、まだ処理が必要な画像を見つけることができます。Worker ロールの処理が必要なレコードを見つけるために、キューを使用するか、単にデータをポーリングするかを決定していません。キューの方が効率的だと思いますが、複雑さがさらに増し、潜在的な障害点が増えることにもなります。

コメントに応じて編集:この回答を投稿したとき、サムネイルが利用できない場合は、UI でフル解像度の画像を使用するように言いました。現在、生成されたサムネイルが利用可能になるまで「処理中」というデフォルトのサムネイル画像を使用するサイトで作業しています。どちらを選択するかはあなた次第であり、実際にはアプリの UI の要件によって異なります。

できることの 1 つは、SignalR または一部の AJAX を使用して、新しいページの読み込みを待たずに、新しいサムネイルが利用可能になったときにユーザーのブラウザーに通知することです。

ワーカー スレッドで画像処理が行われているときにプレースホルダー サムネイルを表示すると、サムネイルの生成中にページが読み込まれるのを待つよりも、ユーザー エクスペリエンスが大幅に向上します。

于 2010-03-14T01:32:35.820 に答える
1

分散キュー（AzureまたはAmazonなど）の使用は、驚くほど微妙です。AzureQueuesの頻繁な微妙な点をカバーするブログエントリを投稿しました。結論：インフラストラクチャロジック（キューをサポート）をビジネスロジック（キューのコンテンツと処理）から慎重に抽象化することをお勧めします。

于 2010-03-17T11:05:48.960 に答える