不停止更新生產IIS網站和SQL Server數據庫

Question

有一個使用測試數據庫的測試服務器。我們在測試服務器上測試網站。如果沒問題，我們將網站和數據庫架構從測試服務器更新到生產服務器。但是這種方法非常痛苦和風險。

首先，我們必須將用戶重定向到維護頁面，以便網站暫停一段時間。

二，如果更新時出現問題，我們必須回到舊網站，因爲我們無法長時間將網站置於維護模式。

所以我正在尋求一個可靠的解決方案來更新IIS網站和Sql Server數據庫而不會丟失數據並使用維護模式。有沒有辦法做到這一點？大型網站如何做到這一點，而不會造成數據丟失和暫停。

我們以爲使用發佈候選網站。我們計劃暫時使用這個RC網站。首先，我們更新RC站點，然後交換RC和生產網站之間的綁定。但是這次數據庫是問題。因爲我們可以更改數據庫模式，而舊數據庫不能使用新數據庫。所以，如果我們使用臨時數據庫的臨時站點，將會有數據丟失。另外，如果臨時站點使用舊生產數據庫，則更新後的網站將無法與舊數據庫一起使用。所以我需要一個可靠的解決方案來解決這個問題。

Answer 1

這比你想象的更復雜的訂單。這個具體是關於HA的而不是，也不關於連續整合。這些都不會提供你需要的東西，它們只是更復雜的難題的一部分。

簡而言之，就是不可能以透明的方式編寫代碼更改/忘記模式更改，因爲它們發生在。充其量，您可以用支持v。N和v。N + 1架構的方式編寫代碼，這本身就是一個很大的挑戰。但是不可能以支持模式的方式編寫代碼，因爲它將從v.N轉換到v.N + 1。由部署引發的模式更改對於在模式上運行的代碼必須是原子的。由於模式更改本身不可能是原子級的，因此升級有兩種可能的途徑：

• 在模式更改期間使代碼脫機。這就是你現在正在做的，並且是最安全的方法。當然，這意味着服務可用性停機時間和運行風險，您已經體驗過（升級失敗，長時間升級等）。這種方法的一個變種是將服務重定向到只讀的數據副本，並提供降級的服務體驗（停機期間不可能進行更改），這可能會或可能不會被接受，具體取決於業務細節。

• 待機升級。這意味着您可以拍攝服務數據的快照（各種HA解決方案可以提供即裝即用的備用快照，例如日誌傳送）。升級快照，然後將發生在實際服務數據上的所有事務應用到升級後的快照。這總是很棘手，因爲它需要一種技術來檢測，捕獲和應用更改（例如更改跟蹤，複製，自定義解決方案等）。和需要將每個更改轉換爲新的升級架構。一旦升級後的模式與來自主服務的更改保持同步，服務就可以重定向到升級後的模式。這種重定向也比聽起來複雜得多。對於選擇切斷舊架構並停止接受新更改的時刻，同時確保將全部更改應用於新升級的架構數據庫本身就是一項挑戰。另一個挑戰是解決代碼理解升級前和升級後模式版本的衝突。正如我所說，開發處理兩者的代碼是有問題的和容易出錯的，所以一種解決方案是再次使服務在短時間內脫機並替換代碼。另一種解決方案是備用服務，運行代碼處理升級後數據庫模式並連接到升級後數據庫，並將活動請求重定向到您的備用升級服務。

而且我甚至沒有觸及服務交互的棘手問題，當一個更大的部署的解決方案的一個特定的服務必須進行升級。這是當service API protocol back compatibility扮演主角時允許升級後服務與其對等服務一起玩。

最終沒有任何銀彈。我見證了單機大型數據庫部署需要花費周才能推出N + 1版本，並通過轉錄複製將升級後的數據庫架構與升級前數據庫中的更改連續提供。我目睹了成千上萬臺部署N + 1版本的機器的分階段部署，這是一段複雜的舞蹈，它可以在幾天內改變代碼和數據的變化，以實現升級後的全部功能。這個問題只是簡單的硬。

Answer 2

描述高可用性解決方案（HA）。 HA解決方案非常昂貴，並且很快就會過度消耗。您需要爲您的應用程序和數據庫服務器提供冗餘，這意味着要設置一個數據庫集羣。所有這些都會增加您花費部署更改的時間，但是權衡是您的應用始終可用。

部署的主要內容是具有可重複的過程。所以我最好的建議是儘可能地編寫腳本或自動化。

Answer 3

這就是Azure所擅長的。 Azure雲平臺允許登臺服務器和生產服務器。您可以對其進行設置，以便在您將更改提交到Git或TFS時自動將其推送到分段或生產服務器。您也可以設置爲手動推送更改。像Entity Framework這樣的大多數ORM庫都有遷移支持。

有大量的詳細信息那裏關於這一主題，如： Azure seamless upgrade when database schema changes Staging or Production Instance?