现有Asp.Net网站的Azure云服务与虚拟机

Question

我已经看到了这个问题的变体，但找不到任何与我们的特定场景有关的内容。

我们现有一个链接到SQL Server数据库的aps.net网站。 数据库具有clr用户定义的类型，因此它只能在Azure VM中托管，因为云服务不支持所述类型。

我们最初想使用vm作为前端的数据库和云服务，但随后出现了一些问题：

1. 我们使用StateServer存储State，但Azure不支持。我们需要配置表存储，SQL数据库或专用于状态管理的工作者角色（新的工作者角色是一个额外的成本）。由于性能，表存储不是理想的。其他两个选项更可取，但它们会带来成本或应用程序重新配置的缺点。
2. 我们使用SimpleMembership进行用户管理。我们需要将成员资格表从我们的vm实例sql server迁移到Azure的SQL数据库。这是一个不方便，因为我们希望将所有表保留在同一个数据库中，并且拆分2可能需要进行一些代码更改。

我们正在寻找一种快速解决方案，让这款应用程序尽快上线，并且成本可控。我们正在拼命试图避免重新分解我们的代码，以适应Azure云服务中托管部分应用程序。

问题：

• 我们应该选择VM路由来托管所有内容吗？
• 利用VM实例（针对sql server）和Cloud Service实例（针对前端）是否有任何成本优势？
• 在我看来，每个为Cloud Service添加的“后台进程”都需要一个新的工作者角色。例如，如果我们想为电子邮件服务启用smtp，则需要新角色，因此需要更多成本。这是对的吗？

Answer 1

要使用CLR等运行SQL Server，您需要在虚拟机中运行SQL Server。

对于Web层，云服务（Web角色）具有优势，因为它们是无状态 - 非常容易扩展/扩展而无需担心操作系统设置。应用程序设置是在启动时通过启动脚本完成的。如果您可以适当地托管会话内容，则无状态模型将更易于扩展和维护。但是：如果您要执行任何类型的复杂安装需要一段时间（或手动干预），那么虚拟机可能确实是更好的路径，因为您可以构建VM，然后从该VM创建主映像。您仍然需要处理操作系统和应用程序维护问题，就像在本地环境中一样。

让我在关于后台流程的第3篇子弹中纠正你。云服务的Web角色（或工作者角色）实例仅仅是Windows Server VM，其中包含一些用于启动和进程监视的脚手架代码。每个人都不需要单独的角色。随意在单个Web角色上运行您的整个应用程序并向外扩展;你只是在非常粗糙的水平上进行缩放。

Answer 2

要考虑的一些事情......

如果您想要便宜，可以通过添加RoleEntryPoint让您的web / worker角色在一台计算机上共享相同的代码。这是一篇文章，实际上展示了如何通过发送电子邮件来做你想做的事情： http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx

在SQL Azure数据库中会话管理非常缓慢，如果可以，我会使用Azure缓存。这很快。

带有VM的SQL Server会给您带来麻烦，因为您还需要在该服务与任何云服务之间创建虚拟网络。这真的很愚蠢，但如果您部署云服务和VM，它们会通过PUBLIC LOAD BALANCER进行通信，从而导致潜在的安全问题和网络延迟。所以，首先你需要虚拟网络（这是一个额外的成本）..然后你还需要托管DNS服务器来解决SQL Server VM。是的，这真的很愚蠢，除非您的网络/工作人员角色可以通过互联网与您的SQL Server进行通信：）

编辑：将“公共互联网”更改为“公共负载均衡器”（并注明延迟）

编辑：上述信息100％正确，与David下面的评论相反。请阅读Microsoft的指导：

http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario

直接来自MICROSOFT GUIDANCE谈论跨云服务通信（VM->网络/工作者角色）：

“我们建议您实施第一个选项，因为连接过程不需要通过公共互联网。因此，它将提供更好的网络性能。”

截至今天（2013年8月29日）Azure虚拟机和工作人员/ Web角色已部署到不同的“云服务”中。因此，需要通过在实例之间公开私有IP地址的虚拟网络来保护它们之间的通信。

跟进David的观点，关于添加ACL。您仍在使用TDS（SQL Server协议）通过Internet发送数据包。这可以加密，但没有理智的架构师/企业治理/安全治理会“允许”在生产环境中发生这种情况。