本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
切換階段
在遷移儲存資料的元件時，您需要考慮資料一致性是否是關鍵要求。如果是，則您可能需要在開始切換程序之前鎖定來源環境 (例如資料庫鎖定)。鎖定資料庫可以確保不會對來源環境進行新交易。但是，鎖定可能需要更長的停機時段。
切換通常包括下列階段：
擷取凍結 – 凍結將內部部署應用程式和資料到資料庫的擷取。這可確保應用程式的內部部署版本在切換期間不會接收任何新交易或資料。
備份 – 對內部部署系統進行最終備份。如有必要，您可以在緊急情況下使用此備份進行復原。
資料同步 – 完成內部部署與目標 (雲端) 環境之間的最終資料同步。
路由變更 – 將使用者路由至雲端環境 (例如，更新 DNS 記錄或變更負載平衡器目標)。
測試 – 在將遷移標記為完成之前，測試並驗證一切正常。
切換方法
有兩種切換方法可供考慮：一次全部方法或分階段方法。選擇最佳切換方法的關鍵是了解您的業務需求和技術限制。本節將概要介紹這兩種方法。
一次全部方法
如果您採用一次全部方法，則只需按一下開關即可切換整個解決方案。例如，您可以透過更新 DNS 或變更負載平衡器來執行此操作。然後，所有使用者和即時流量都會立即使用新系統。在潛在主機名稱衝突、授權問題或域身分驗證限制而無法使新系統上線的情況下，此方法非常有用。由於時間至關重要，因此重點在於何時或誰將呼叫容錯恢復。我們建議您的一次全部方法計畫包括廣泛的效能測試以及迴歸測試 (如果適用)，以便您可以同時驗證應用程式的功能和非功能特性。
分階段方法 (金絲雀部署)
分階段方法涉及在定義的時段內逐步切換。此方法包括持續監控和檢查，以驗證目前系統是否可以承受負載以及每個系統元件是否如預期運作。分階段方法可以協助降低潛在切換問題的風險，因為您可以根據回饋調整系統效能。如果您識別關鍵問題，也可以更輕鬆地復原任何變更。
選擇正確的方法
若要選擇正確的方法，請識別下列內容：
屬於相同移動群組的相依應用程式和服務
可在內部部署與遷移的應用程式之間使用的通用資料來源
可以將部分負載重新導向至不同端點的應用程式和基礎設施
如果您的應用程式無法容忍資料來源與應用程式伺服器之間增加的延遲，則這清楚地表明需要採用一次全部方法。在這種情況下，您可以將所有應用程式資源 (伺服器和資料庫) 一起切換以避免影響效能。
在分階段切換中，您將構成應用程式的一部分伺服器和服務從整個分割到 ， AWS 而剩餘的伺服器和服務仍保留在內部部署。然後，您根據負載平衡或 DNS 政策將用戶端流量路由至這兩個環境。分階段切換可協助您最大程度地減少對使用者的影響，從而將受切換影響的使用者數量降到最少。如果您可以識別影響，則您可以相應地調整伺服器和服務的百分比。但是，分階段切換方法依賴基礎應用程式支援此方法的能力。我們建議您問自己下列問題：
-
應用程式是否具有由可分割的彈性伺服器對或群組組成的多個層 (前端、後端、資料庫)？
-
應用程式是否透過負載平衡器存取，且負載平衡器是否支援將流量路由至 AWS 網路和內部部署網路？
應用程式伺服器是否可以遷移以 AWS 容忍資料庫或其他後端相依性的延遲。如果資料庫切換到 AWS，剩餘的現場部署伺服器或服務是否可以繼續運作並視需要執行？
在 中，將一定百分比的使用者傳送至新遷移的伺服器， AWS 同時維護現有的現場部署容量，相較於all-at-once方法，在復原功能方面具有關鍵優勢。由於您混合使用了遷移的伺服器和現有的伺服器來為應用程式提供服務，並且負載分佈在它們之間，因此在出現問題時回復既快速又簡單。在大多數情況下，所需要做的只是變更負載平衡器、DNS 規則或政策。分階段切換方法也可讓您逐步增加負載 AWS，讓應用程式團隊評估應用程式的效能，並在傳輸完全負載之前進行必要的更新或變更。
選擇是否最好一次性切換一個應用程式或一組相依的應用程式，或者是否使用分階段切換伺服器和服務的增量方法，這不太可能是一刀切的決策。我們通常看到客戶採用下列方法：
-
可以容忍短暫停機時間的開發和測試環境將受益於一次全部方法切換的簡單性和較低的工作量。
-
相反，分階段方法更複雜且耗時，但通常提供較短的停機時間要求和更快的復原選項。因此，分階段方法最常用於關鍵業務生產工作負載。
我們建議在切換變更時段之前花時間了解您的來源系統。透過在早期規劃階段投入更多時間，您可以支援各種程序，例如切換準備和遷移後驗證。客戶可以在遷移至 時變更其伺服器的 IP 地址 AWS。在這種情況下，要避免的關鍵因素是在應用程式內使用硬式編碼的 IP 地址。我們建議您全面查看來源環境，它可能同時具有上游或下游相依性。例如，您更有可能對連接至您遷移的服務的其他系統造成問題。在開始切換之前，值得考慮將所有連線移至使用完整域名 (FQDN) 或 DNS 記錄是否有價值。
何時執行切換
一般來說，切換事件的最佳時間是使用者最少的時候，因為您受到的業務影響最小。但是，這需要與切換時段支援團隊的可用性進行平衡。您需要支援團隊來協助疑難排解並解決潛在問題。考慮切換的日期和時間以及利害關係人的準備情況也很重要。如果您的任何利害關係人沒有在排定日期和時間做好準備並提供服務，則您的切換可能會面臨延遲的風險。
切換前要測試的內容
如果您的遷移方法允許，最佳實務是在切換時段之前執行功能和非功能測試。例如，您可以利用負載測試工具來驗證新環境是否在切換時段之前進行了適當設定。一般而言，此階段的測試不會中斷，因為 AWS 環境不提供即時流量。
切換前無法測試的內容
由於與其他應用程式的相依性，可能無法測試生產中發生的所有案例。在這種情況下，記錄潛在風險、規劃如何識別風險，以及在測試失敗時您的團隊將採取哪些相應的緩解方法。
營運準備審核
在您將應用程式切換到 之前 AWS，我們建議您執行操作準備度檢閱。您可以在此處評估測試的完整性，驗證團隊監控和取得提醒的能力，並確認利害關係人了解如何支援和維護工作負載。這可能同時需要與業務和技術團隊合作。如需營運整備的詳細資訊，請參閱 AWS 文件中的 AWS Well-Architected
轉返
在特定情況下可能需要遷移復原。為了準備可能的復原，我們建議您制定復原計畫，其中包括下列內容：
定義的檢查點，如果符合特定預先定義的條件，則在切換期間啟動復原
用於管理復原和處理資料的復原策略
決定修正轉送還是復原遷移的聯絡點
切換期間或無新資料時復原
如果您和您的利害關係人決定在不變更任何資料的情況下執行復原，則復原方法可以非常簡單，只需恢復內部部署執行個體，然後透過修改負載平衡器或 DNS 組態來重新導向流量即可。
使用變更的資料復原
如果成功切換後啟動復原並且您的應用程式收到了新的交易和資料，則您可能必須將資料從雲端環境還原至內部部署環境。我們建議您在本案例中考慮下列方法：
向前失敗方法 – 由於遷移後資料庫成為主要資料庫，因此您的內部部署 AWS 資料庫可能會變得過時。您可以使用 AWS Database Migration Service (AWS DMS)
設定向前失敗資料庫，將資料複寫到新的現場部署資料庫。發生任何問題時， AWS DMS 會將您的應用程式轉返至指定的向前故障資料庫，而不是過時的內部部署資料庫。 雙重寫入策略 – 在這種情況下，您的應用程式邏輯必須允許寫入舊資料庫和新資料庫。
原生備份和還原 – 若要評估還原所需的時間，請在預切換階段使用較低環境 (即非生產環境) 執行備份和還原測試。
