我什么时候应该在 ASP.NET 网站中使用服务总线？
我正在考虑分布式网站，其中网站（多实例）由应用程序服务器（多实例）支持。 我正在努力定义它们之间的通信机制。我看到了很多选择，例如 WCF、消息服务，或者像许多人建议的那样，只需完全消除应用程序服务器即可。
那么，对于预计有数百万访问者的全球级网站，您会做什么呢？
好吧，这是很多问题，但它们在某种程度上是相关的。服务总线是否有助于可扩展的分布式站点……或者我在这里混淆了这些词。
任何指导都将受到高度赞赏
I'm thinking of distributed website, where a website (Multi-instance) is backed by an App Server (Multi-instance).
I'm struggling with defining the communication mechanism between these. I see a lot of options like WCF, messaging service, or as many would suggest by simply eliminating the App Server altogether.
So what would you do for Global Level websites which expects millions of visitors.
Okay, so these are lots of questions, but they are somehow related. Does a service bus help in scalable distributed sites ... or I'm mixing the words over here.
Any guidance is highly appreciated
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
此外，如果您想要进行负载分配或消息路由和过滤，则可以使用服务总线中的主题/订阅：http://code.msdn.microsoft.com/windowsazure/Multi-Tier-application-6c033cad
Also if you want to do load distribution or routing and filtering of the messages then you can use Topics/Subscriptions in Service Bus: http://code.msdn.microsoft.com/windowsazure/Multi-Tier-application-6c033cad
我认为这取决于沟通的方向和重要性。在某些情况下，您将有两种方式的通信，需要典型的请求/响应传输（HTTP 等）。在某些情况下，您将能够使用单向通信。这将使您能够使用消息传递传输，并提供将某些处理“离线”移动的能力。这可以帮助您扩展站点，但您可能只是将问题转移到其他地方而没有经过仔细的设计。
重要性很重要，因为如果您从用户那里获得了一些您不想丢失的信息（例如订单），那么这也可能会促使您采用更持久的方式（例如消息传递）。您不一定需要服务总线来使用一种持久的通信方式，但提供的功能集可能会让事情变得更容易。
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.
服务总线可以通过多种方式帮助您解决方案。正如 Adam 提到的，如果您需要持久性和时间解耦，那么使用服务总线持久队列是一个不错的选择，这里有一些详细的指导 http://www.windowsazure.com/en-us/develop/net/tutorials/multi-tier-application/
另一方面手，如果你有的话应用程序服务器位于防火墙后面，只需要通过全双工通信进行 NAT/防火墙穿越，那么您可以使用服务总线中继来实现这一点：http://www.windowsazure.com/en-us/develop/net/tutorials/hybrid-solution/
There are several ways in which Service Bus can help with your scenario. As Adam mentions if you need durability and temporal decoupling then using a Service Bus durable Queue is a good option, some detailed guidance for that is here http://www.windowsazure.com/en-us/develop/net/tutorials/multi-tier-application/
On the other hand if you have the application server sitting behind a firewall and just need NAT/Firewall traversal with full duplex communication then you can use Service Bus Relay to achieve that: http://www.windowsazure.com/en-us/develop/net/tutorials/hybrid-solution/