1

我们使用 Windows Azure 云服务来托管我们的应用程序。Windows Azure 的一大特色是生产/登台模型。您可以将应用程序的客户端路由到生产服务器，同时可以测试在暂存服务器上运行的新代码。例如，您可以将 Azure 配置为将生产服务器指向http://www.coolapp.com，同时将同一应用程序的临时服务器指定为类似以下内容：http: //7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net。

从物理上讲，这两个服务器都是面向公众的。如果您知道暂存服务器的神秘 URL，您将能够像浏览 www.coolapp.com 一样轻松浏览应用程序。但是，URL 中 GUID 的存在使得人们几乎不可能猜到它，从而使登台服务器“私有”。这为应用程序的开发人员提供了一种很好的机制，可以在将新位发布到公众之前在登台服务器上部署和测试新位。一旦他们确保事情看起来不错，只需轻按一下开关，他们就会交换两台服务器，使登台服务器成为生产服务器，反之亦然。

这个模型给我们带来了一个与 Facebook 集成相关的小问题。为了能够集成 Facebook 插件，您必须向它们注册您的应用程序。然后 FB 将发出一个 AppId 和一个 AppSecret 密钥。这些键与您的应用程序的 URL 相关联。因此，为了让我的应用程序能够使用 FB 插件，我需要获得一组与 7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net 相关联的密钥，以及另一组与 www.coolapp.com 相关联的密钥。

当我阅读有关 Windows Azure 的信息时，他们确实敦促开发人员将登台服务器与生产服务器视为相同。它们之间的唯一区别应该是 URL。换句话说，Azure 不建议您的应用程序逻辑基于代码恰好在哪个服务器上运行，因为 Azure 对此没有固有的知识。如果您愿意，分期与生产只是一个方便的“抽象”。我想你在这里看到了问题。在上面的示例中，我必须使用 FB 发布的一组密钥，而不是另一组密钥，具体取决于我的应用程序在哪个 URL（生产与暂存）上运行。我想我不是第一个遇到这个问题的人。处理这个的正确方法是什么？一种明显的方法是嗅探 Request 对象的 URL 属性并以此方式分支我的逻辑。然而，直觉告诉我这是一个hack。还有其他想法吗？

问候，

阿基尔

4

1 回答 1

1

我知道的机制是：

  • 在一个完全独立的服务帐户中使用“生产”来“测试”——这使得生产服务中的“登台”被用作“部署候选者”的区域，并提供一个单独的干净的测试域和一个不变的 URL “开发和测试”工作。
  • 使用不同的 .cscfg 文件进行暂存和生产 - 并在进行任何实时切换之前小心更新此 .cscfg。
  • 嗅探传入的 URL - 正如你所建议的那样

就我个人而言，我使用了这些技术中的第一个——它很容易并且有助于防止严重的事故

顺便说一句，我们用于从暂存中“删除” Guid 的技术之一是在 DNS 上使用非常短的 TTL 对 Guid 进行 CNAME - 这使我们能够在以下情况下快速自动更新暂存服务器的 CNAME 记录我们部署。

于 2011-05-19T10:20:40.903 回答