asp.net - Azure 云服务与现有 Asp.Net 网站的 VM

Question

我已经看到了这个问题的变体，但找不到任何涉及我们特定场景的问题。

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

我们最初想使用虚拟机作为数据库，使用云服务作为前端，但后来出现了一些问题:

1. 我们使用 StateServer 来存储状态，但 Azure 不支持。我们需要配置表存储、SQL 数据库或专用于状态管理的辅助角色(新的辅助角色会增加成本)。由于性能原因，表存储并不理想。其他两个选项更可取，但它们会带来成本或应用程序重新配置的缺点。
2. 我们使用 SimpleMembership 进行用户管理。我们需要将成员资格表从虚拟机实例 SQL 服务器迁移到 Azure 的 SQL 数据库。这很不便，因为我们希望将所有表保留在同一个数据库中，而将这两个表分开可能需要进行一些代码更改。

我们正在寻找一种快速解决方案，以便以可管理的成本尽快推出此应用程序。我们拼命地试图避免仅仅为了在 Azure 云服务中托管部分应用程序而重构我们的代码。

问题:

• 我们应该采用虚拟机路线来托管所有内容吗？
• 利用虚拟机实例(用于 SQL Server)和云服务实例(用于前端)是否有任何成本优势？
• 在我看来，云服务中每一个添加的“后台进程”都需要一个新的辅助角色。例如，如果我们想为电子邮件服务启用 smtp，则需要新角色，因此成本更高。这是正确的吗？

Answer 1

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

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

让我纠正您关于后台进程的第三个要点。云服务的 Web 角色(或辅助角色)实例仅仅是 Windows Server VM，带有一些用于启动和进程监控的脚手架代码。您不需要为每个角色分配单独的角色。您可以随意在单个 Web 角色上运行整个应用程序并进行横向扩展；您只会在非常粗粒度的级别上进行缩放。