facebook - Windows Azure 生产与临时服务器和 Facebook 集成

Question

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

实际上，这两个服务器都是面向公众的。如果您知道临时服务器的神秘 URL，您将能够像浏览 www.coolapp.com 一样轻松地浏览该应用程序。然而，URL 中 GUID 的存在使得其他人几乎不可能猜测它，从而使登台服务器变得“私有(private)”。这为应用程序的开发人员提供了一种很好的机制，可以在向公众发布之前在临时服务器上部署和测试新的部分。一旦他们确保一切顺利，只需按一下开关，他们就会交换两台服务器，使登台服务器成为生产服务器，反之亦然。

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

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

问候，

阿奇尔

Answer 1

我所知道的机制是:

• 在完全独立的服务帐户中使用“生产”来“测试” - 这使得生产服务中的“暂存”可用作“部署候选”区域，并提供一个独立的、干净的测试域，且该域不会发生变化早期“开发和测试”工作的网址。
• 使用不同的 .cscfg 文件进行暂存和生产 - 并在进行任何实时切换之前小心更新此 .cscfg。
• 嗅探传入的 URL - 按照您的建议

就我个人而言，我使用第一种技术 - 它很简单，并且有助于防止发生严重事故

<小时/>

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