Windows Azure產品與臨時服務器和Facebook集成

Question

我們使用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屬性並以這種方式分支我的邏輯。然而，直覺告訴我這是一個破解。任何其他想法？

問候，

阿爾奇爾

Answer 1

我知道的機制是：

• 使用一個完全獨立的服務帳戶中的「生產」到「測試」 - 這葉內的「升級」生產服務用作「部署候選人」的區域，併爲早期的「開發和測試」工作提供單獨的乾淨測試域和不變的URL。
• 使用不同的.cscfg文件進行分段和生產 - 並且在做任何實時切換之前要小心地更新這個.cscfg。
• 嗅探傳入的URL - 你的建議

就個人而言，我使用這些技術的第一個 - 它很容易，它可以幫助防止討厭的事故

---

順便說一句，這些技術的一個我們用於將Guid從分段中「移除」到CNAME的Guid上，並在DNS上使用了非常短的TTL--這使我們能夠在部署時快速自動更新登臺服務器的CNAME記錄。