Azure Web 角色 - 混合 MVC 和 WCF - 最佳实践
我正在寻找一些有关构建公开 ASP.NET MVC 2 UI 和 WCF 服务的 Azure 应用程序的建议。
两者都通过 Internet 向消费者公开，并且 UI 也使用 WCF 服务。
为了最大限度地降低小型部署的运营成本，同时能够横向扩展，我希望在同一个 Web 角色中托管 UI 和 WCF 服务。但在其他情况下，我可能希望将 WCF 服务部署到它们自己的 Web 角色或辅助角色，以便它们可以独立扩展。
当 UI 和服务共同托管时，我非常确定我希望 UI 使用由同一 Web 角色实例托管的服务实例。引起负载均衡器的延迟并可能转到不同的主机来使用我旁边的服务似乎没有多大意义。在这种情况下我是否想使用 WCF，或者直接使用服务类？但如果我这样做，如果我选择重新配置应用程序拓扑，就无法利用位置透明性。
我无法找到有关 Azure 中共同托管 UI 和 WCF 服务的太多指导。
我应该遵循什么模式？
I'm looking for some advice on building Azure applications that expose both an ASP.NET MVC 2 UI and WCF services.
Both are to be exposed to consumers over the Internet and the UI also consumes the WCF services.
In order to minimise operational costs for small deployments, yet be able to scale out, I want to host both the UI and the WCF services within the same Web Role. Though in other cases, I might want to deploy the WCF services to their own Web Role or Worker Role so that they can be scaled independently.
When the UI and Services are co-hosted, I'm pretty certain that I want the UI to consume instances of the Services that are hosted by the same Web Role instance. It doesn't seem to make much sense to incur the latency of the load balancer and potentially going to a different host to consume a service that's right there next to me. Do I even want to use WCF at all in this case, or consume the service classes directly? But if I do that, it precludes being able to exploit location transparency if I choose to reconfigure the application topology.
I've not been able to find much guidance on co-hosted UI and WCF services within Azure.
What patterns should I be following?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我同意使用 WCF 接口仍然是一个好主意，每当您需要分解配置时，让事情正常工作所需的更改应该是最小的。
在 WCF 中，您应该能够公开内部端点并通过 127.0.0.1 或 localhost 连接到它。这应该绕过数据中心边界的交叉，从而避免额外的费用和延迟。
I agree that using WCF interface would still be a good idea, whenever you'll need to break the configuration apart, the changes needed to get things to work should be minimal.
In WCF, you should be able to expose an internal endpoint and connect to it via 127.0.0.1 or localhost. This should bypass the crossing of data center boundary and thus, extra fees and latency.
考虑将应用程序作为完整的 IIS 角色运行，并将服务和站点作为两个不同的站点/角色运行。这样，如果您需要在任何阶段拆分它们，只需配置即可。
除了 IgoreK 之外，WCF 的优点在于实现的抽象。如果您想运行单个实例，请循环 - 您甚至可以使用命名管道绑定以获得更好的性能。
如果您在任何时候需要横向扩展，这只是一个配置更改，您可以通过负载均衡器执行 http 甚至 tcp。
Consider running your Application as a Full IIS Role, and run the Services and Site as two different Sites/Roles. That way, if you need to split them at any stage it's just configuration.
Adding to IgoreK, the beauty of WCF is abstraction of implementation. If you want to run a single instance, loop back - you can even use a named pipe binding for better performance.
Should you at any point need to scale out, once again, it's just a configuration change and you can do http or even tcp through the load balancer.