我们使用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属性并以这种方式分支我的逻辑。然而，直觉告诉我这是一个黑客。还有其他想法吗？
此致
阿尔奇尔
答案 0 :(得分：1)
我所知道的机制是：
就个人而言，我使用这些技术中的第一种 - 它很容易，它有助于防止令人讨厌的事故
顺便说一句，我们用于“移除”Guid的一种技术是在NID上使用非常短的TTL来指导Guid - 这使我们可以快速自动更新CNAME记录我们部署时暂存服务器。