Web サイト (マルチインスタンス) がアプリケーション サーバー (マルチインスタンス) によって支えられている分散 Web サイトを考えています。これらの間の通信メカニズムを定義するのに苦労しています。WCF やメッセージング サービスなど、多くの選択肢があり、単純に App Server を完全に排除することで提案されます。
では、何百万人もの訪問者を期待するグローバル レベルの Web サイトに対してはどうしますか。
さて、これらはたくさんの質問ですが、何らかの形で関連しています。サービス バスはスケーラブルな分散サイトに役立ちますか ... または、ここで言葉を混ぜています。
どんなガイダンスも大歓迎です
また、メッセージの負荷分散またはルーティングとフィルタリングを行う場合は、Service Bus でトピック/サブスクリプションを使用できます: http://code.msdn.microsoft.com/windowsazure/Multi-Tier-application-6c033cad
I think this depends on the direction and importance of the communication. It some cases you will have two way communication that will require typical request/response transports(HTTP, etc.). In some cases you'll be able to use one way communication. This would open you up to using a messaging transport, and supplying the ability to move some processing "offline". This could help you scale the site, but you may just move your problems somewhere else without some careful design.
Importance matters because if you have some information from the user you don't want to lose, say orders, then that may also push you towards something more durable like messaging. You don't necessarily need a Service Bus to use one way, durable communication, but the feature set provided may make things easier.
Service Bus がシナリオに役立つ方法がいくつかあります。耐久性と一時的な分離が必要な場合に Adam が言及しているように、Service Bus の耐久性のあるキューを使用するのが適切なオプションです。 -ティア-アプリケーション/
一方、アプリケーション サーバーがファイアウォールの背後にあり、全二重通信による NAT/ファイアウォール トラバーサルのみが必要な場合は、サービス バス リレーを使用してそれを実現できます: http://www.windowsazure.com/en-us/開発/ネット/チュートリアル/ハイブリッド ソリューション/