我们使用Windows Azure Cloud 服务来托管我们的应用程序 . 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属性并以这种方式分支我的逻辑 . 然而，直觉告诉我这是一个黑客 . 还有其他想法吗？
问候，
阿尔奇尔
1 回答
我所知道的机制是：
在一个完全独立的服务帐户中使用"production"到"testing" - 这使得 生产环境 服务中的"staging"用作"deployment candidates"的一个区域，并为早期"dev and test"工作提供了一个单独的干净测试域，其中包含一个不变的URL .
使用不同的.cscfg文件进行登台和制作 - 并且在进行任何实时切换之前要小心更新此.cscfg .
嗅探传入的URL - 正如您的建议
就个人而言，我使用了第一种技术 - 它很容易，它有助于防止令人讨厌的事故
顺便说一下，我们用来“移除”Guid的一种技术就是在NID上用一个非常短的TTL CNAME Guid - 这使我们可以快速自动更新登台服务器的CNAME记录 . 我们部署 .