65.9K
CodeProject 正在变化。 阅读更多。
Home

如何为小型网站使用 Windows Azure

avsol
starIconstarIconstarIconstarIconemptyStarIcon

4.00/5 (1投票)

2012年5月2日

CPOL

6分钟阅读

viewsIcon

28908

一些可能有助于您经济高效地构建 Windows Azure 网站的技巧。

引言

凡是比较过 Windows Azure 定价与其他托管选项的人都知道，Windows Azure 可能比共享主机更贵。Windows Azure 提供了出色的可伸缩性和可靠性，但对于小型网站所有者来说，很难判断其功能是否真的物有所值。

以下是一些可能帮助您有效降低 Windows Azure 网站建设成本的技巧。

您可以将所有内容打包到一个 Web Role 中

Windows Azure 中的 Role 类似于虚拟机，实际上是构成该服务最昂贵的部分之一。

假设您正在构建一个网站、一个 Web 服务和一个后端处理模块。在大多数教程中，Microsoft 会告诉您需要三个 Role：一个用于您的网站的 Web Role，另一个用于您的 Web 服务的 Web Role，以及一个用于后端处理器的 Worker Role。Microsoft 还建议您至少为每个 Role 设置两个实例以提高可靠性，这很好，但对于您的小型网站来说，总共将需要六个实例。这听起来似乎有点过头，但别担心，有办法解决这个问题。大多数情况下，您可以将整个系统打包到一个 Role 中（并部署两个负载均衡的实例以提高可靠性）。

这是一个将公共网站（使用 HTTP）、用户管理网站（使用标准端口 443 上的 HTTPS）、Web 服务（使用自定义端口 12345 上的 HTTPS）以及计划的 Worker 进程放在一个 Web Role 中的示例。

像往常一样构建您的网站项目（很可能是 Web 应用程序项目）和 Worker DLL 项目。创建一个 Windows Azure Web Role 项目用于您的公共网站，让 Visual Studio 创建一个 ServiceDefinition.csdef 文件，其中包含在 Windows Azure 中运行公共网站所需的一切。

现在您需要教会 Azure 部署工具如何将您的附加 Web 应用程序传输到 Windows Azure，以及如何配置 IIS 以按您希望的方式运行它们。您可以通过更改 ServiceDefinition.csdef 文件来实现，如下所示：

<WebRole name="MySingleWebRole" vmsize="Extra small">
  <Sites>
    <Site name="MyWebSite" physicalDirectory="..\MyWebSite">
      <Bindings>
        <Binding name="BindingPublic" endpointName="EndpointPublic" hostHeader="www.example.com" />
  <Binding name="BindingPublic2" endpointName="EndpointSecure" hostHeader="www.example.com" />
      </Bindings>
    </Site>
    <Site name="MyUserManagement" physicalDirectory="..\PublishedSites\MyUserManagement">
      <Bindings>
        <Binding name="BindingAdmin" endpointName="EndpointSecure" hostHeader="admin.example.com" />
        <Binding name="BindingAdmin2" endpointName="EndpointPublic" hostHeader="admin.example.com" />
      </Bindings>
    </Site>
    <Site name="MyService" physicalDirectory="..\PublishedSites\MyService">
      <Bindings>
        <Binding name="BindingService" endpointName="EndpointService" hostHeader="service.example.com" />
      </Bindings>
    </Site>
  </Sites>
  <Endpoints>
    <InputEndpoint name="EndpointPublic" protocol="http" port="80" />
    <InputEndpoint name="EndpointSecure" protocol="https" port="443" certificate="wwwssl" />
    <InputEndpoint name="EndpointService" protocol="https" port="12345" certificate="servicessl" />
  </Endpoints>
  <Certificates>
    <Certificate name="wwwssl" storeLocation="LocalMachine" storeName="My" />
    <Certificate name="servicessl" storeLocation="LocalMachine" storeName="My" />
  </Certificates>
</WebRole>

在此，我们添加了另外两个 Site 元素，并将它们指向适当的物理目录，其中包含项目文件。在此示例中，MyWebSite 的 physicalDirectory 指向实际的 Visual Studio 项目文件夹 - 它已列在 Web Role 的配置中，因此部署工具知道它需要构建项目并在运行时部署所需的文件。

您不必将其他项目添加到与 Azure 项目相同的解决方案中。您的附加文件放在哪里并不重要，将所有内容都放在一个解决方案中会更方便。

无论如何，请不要将其他 Web 站点的物理目录指向您的 Visual Studio 项目的实际文件夹。如果您这样做，部署工具会将这些文件夹中的所有内容复制到 Web 服务器，包括所有源代码文件。网站可以正常工作，但您可能希望将源代码保存在自己的计算机上，而不是将其复制到 Windows Azure 上的生产服务器。

相反，对于每个附加的 Web 站点，将其发布到文件系统，目标是与您的主 Web 站点相同的目录结构中的某个文件夹。（您可以通过在 Visual Studio 的“生成”菜单中选择“发布”项，然后选择“文件系统”发布方法来完成此操作。）在我们的示例中，我们在 Azure 项目文件夹旁边创建了 \PublishedSites 文件夹，并将 MyUserManagement 和 MyService 站点发布到了 \PublishedSites\MyUserManagement 和 \PublishedSites\MyService 文件夹。由于这些文件夹现在只包含运行时所需的文件，因此我们可以安全地将它们用作 physicalDirectory 参数。请注意，physicalDirectory 值中的路径是相对于 ServiceDefinition.csdef 文件位置的。

在此示例中，我们使用了三个不同的端口，因此我们声明了三个端点 - EndpointPublic 用于通过标准端口 80 进行不安全的公共访问，EndpointSecure 用于在标准端口 443 上进行 HTTPS 访问，EndpointService 用于在端口 12345 上进行 HTTPS 访问。我们还指示 IIS 使用两个不同的 SSL 证书，分别声明为 wwwssl 和 servicessl。

替换 Worker Role

如果您有需要在固定时间间隔运行并执行后端处理的代码，可以将该代码添加到您单个 Web Role 中。

在您的 Web 应用程序项目中，添加一个继承自 Microsoft.WindowsAzure.ServiceRuntime.RoleEntryPoint 类的类。我们称该类为 WebRole。

public class WebRole : RoleEntryPoint
{
}

然后重写 Run 方法。有一个奇怪的地方需要注意：Run 方法永远不应该返回 - 在最简单的实现中，运行 Run 方法的线程应该永远休眠。在我们的例子中，我们希望它定期唤醒，做一些有用的工作，然后再次休眠。

public override void Run()
{
    while (true)
    {
        try
        {
            DoSomeWork();
            Thread.Sleep(30000);
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.Message);
            System.Threading.Thread.Sleep(30000);
        }
    }
}

另一个需要注意的地方是：您的 Web Role 的所有实例都将运行此 Worker 线程，并发执行工作。请确保这是您需要的。此外，如果 Worker 进程检查某些外部资源，随机化休眠间隔以减少冲突的可能性可能会很有用。

SQL Azure 并不昂贵

SQL Azure 的价格实际上比许多托管公司提供的 SQL Server 数据库更便宜。只要确保您不使用不兼容的 SQL 语句即可。例如，SQL Azure 数据库不支持以下 Transact-SQL 功能：

  • Common Language Runtime (CLR)
  • 数据库文件放置
  • 数据库镜像
  • 分布式查询
  • 分布式事务
  • 文件组管理
  • 全局临时表
  • SQL Server 配置选项
  • SQL Server Service Broker
  • 系统表
  • 跟踪标志

避免使用 Azure Table Storage

乍一看，Azure Table Storage 似乎是 SQL Azure 的更便宜的替代品，但由于您按存储量和请求数量收费，如果您频繁地从存储中检索或写入数据，它可能会花费您很多钱。它还有严重的限制，例如无法创建其他索引，缺乏任何搜索功能。它甚至可能扭曲您的数据，因为它底层使用了 XML - 例如，您可能会丢失一些空格。我建议仅将 Table Storage 用于大量不常用的数据，即使在这种情况下，也要先评估 SQL Azure。

Azure Caching Service 价格昂贵

尝试使用传统的内存缓存 - 它是免费的，并且比 Windows Azure Caching Service 提供更多的空间。仅在您确实需要在 Web 场中进行 singleton 式缓存访问时才使用 Azure Caching Service，例如用于用户会话数据。

使用 Windows Azure Marketplace 中的构建块

访问 Windows Azure Marketplace（https://datamarket.azure.com/browse/Applications?Price=Free）查看是否有免费服务或应用程序可以为您的网站增加价值。

例如，有 Microsoft Translator 服务，它通过简单的 API 提供自动翻译（机器翻译）到指定语言的功能 - 每月最多 2,000,000 个字符免费。

另一个例子是 ElasticWCM，它被描述为一个内容管理系统，但实际上是一套免费的构建块，您可以将它们添加到任何现有的 ASP.NET 网站中，以增强其灵活的内容管理功能。

类似这样的优惠开始出现在 Azure Marketplace 上，为利用 Windows Azure 提供了成本效益高的方式。

© . All rights reserved.