Microsoft Azure Storage Service 版本刪除公告

Storage Service 於 2008 年首次推出，自此以後我們推出了 7 個更新版本，每一版都會對協定進行精煉並添加新功能。我們宣佈，即將刪除一些早期版本的 REST API 。本文將會介紹確保應用程式在刪除這些版本之後繼續良好運行需要瞭解的所有注意事項。

背景： Storage Service 版本控制

什麼是版本控制

Azure Storage 通過 REST API 進行訪問 。這些 API 於 2008 年首次問世。在不斷增添和調整內容改進服務的同時，我們還通過版本控制來避免破壞現有的應用程式。每當做出的調整可能會破壞現有應用程式時，我們都會推出新版本，並要求應用程式更新。現有的應用程式不會受到新版本的影響。存取儲存體通常通過以下方式之一指定要使用的版本：

1)     api-version 查詢參數：只要未指定 sv 和 x-ms-version ，或者即便指定但使用 2014 版或更高版本，即可為各項存取儲存體指定此參數。此 api-version 參數將指示使用的服務版本。

2)     x-ms-version request header ：需要對通過共用的金鑰身份驗證進行的調用使用。 x-ms-version header 用於指定版本，以便通知該服務如何對請求做出解釋，以及如何使用該版本的 REST API 對用戶端做出回應。

3)     SAS version header ：在 2012 版本和 2013 版本中，共享存取簽章簽名 ( SAS ) 權杖的 “ sv ” 參數中指定的版本將用於指定協定版本。在 2014 版本中，若未指定 api-version 查詢參數，“ sv ”  參數將僅指定協定版本。

4)     DefaultServiceVersion ：使用者可使用 Blob 服務的 SetServiceProperties 進行設定，以便設定未指定版本的情況下將要對請求使用的 API 版本（也就是公共 Blob 請求）。

5)     默認設定 ：如果提出公共 Blob 請求，但尚未設定 DefaultServiceVersion ，將會使用服務預設設定。這是我們的初始 2008 版本，除非已經設定 SetContainerACL ，否則在這種情況下使用 2009 版本（無論對 SetContainerACL 使用哪個版本均是如此）。 

用戶端函式庫 和工具

我們的很多使用者使用微軟提供的 Storage 用戶端庫開發其應用程式。其中每個用戶端庫基本上都綁定到特定版本的 REST API 。這項規則也適用於 PowerShell cmdlets 和 AzCopy 。儲存體模擬器支援發佈對應版本的儲存體模擬器時發佈的各種版本的 REST API 。

發生了哪些變化？

我們的版本控制方法未做改變－－每當做出的調整可能會破壞現有應用程式時，都將繼續推出新版 REST API 。但現在，我們即將刪除 Storage Service 誕生早期發佈的一些初期服務版本。

刪除版本詳細資訊

將會刪除哪些版本？

我們將於 2015 年 8 月 1 日前刪除版本2012-02-12之前的全部版本。其中包括以下版本：

• 2008（在 GA 之前發佈）
• 版本 2009-04-14（在 GA 之前發佈）
• 版本 2009-07-17（在 GA 之前發佈）
• 版本2009-09-19（在 GA 之前發佈）
• 版本2011-08-18

以下版本不受影響並將繼續提供全面支持：

• 版本 2012-02-12
• 版本 2013-08-15
• 版本 2014-02-14

何時刪除這些版本？

我們將於 2015 年 8 月 1 日前刪除這 5 個受影響的版本。

刪除這些版本後將會產生怎樣的後果？

刪除生效後將會發生以下變化。

明確版本控制請求

使用 x-ms-version request header（設定為其中一個已刪除版本）進行明確版本控制的請求將發生失敗，並會收到 HTTP 400（ Bad Request ）狀態碼，與通過 invalid version header 提出的所有請求類似。

不含 “ sv ” 參數的 SAS 請求

在 2012-02-12 版本之前，SAS 請求不會在 SAS 標記的 “ sv ” 參數中指定版本。這些請求的 SAS 權杖參數均使用 2009-07-17 REST 版本的規則進行解讀。刪除 2012-02-12 之前的版本後，這些請求將發生失敗，並會收到 HTTP 400（ Bad Request ）狀態碼（與是否指定 x-ms-version 作為受支持版本無關）。為使 SAS 請求持續正常運轉，必須指定 “ sv ” 參數。建議至少使用 2014-02-14 版本。

預設服務版本與不帶明確版本的匿名請求

如果已經使用設定 Blob 服務屬性 ( REST API )將預設要求版本設定為版本 2012-02-12 或更高版本，將使用版本集。如果未設定預設要求版本，則其假設請求版本不可知，未來我們將開始回復版本 2014-02-14 。請注意，我們不保證未經版本控制的請求開始獲取新服務版本時是否會造成重大變化，因此提供版本始終是最好的選擇。

如果設定的預設服務版本現已刪除，該請求將被視為明確版本控制，請求將發生失敗並返回 “ 400（Bad Request）” 狀態碼。如果設定的預設服務版本仍受支援，則將繼續使用該版本。

SharedKey/SharedKeyLite 請求（不帶明確版本）

對於使用帳戶共用金鑰簽署的請求，如果未使用 x-ms-version request header 或 api-version 查詢參數（ 2014-02-14 及以上版本支持前述參數）指定任何明確版本，請求將發生失敗並返回 “ 400（ Bad Request ）” 狀態碼。

注意： 最好確保向儲存要求發送的所有請求均經過明確的版本控制。自 2014-02-14 版本開始，使用 api-version 查詢字串參數對請求進行明確的版本控制，這樣即便無法指定客製化的用戶端，也可通過在查詢字串中包含此參數來指定版本。

最低支援版本 / 函式庫 / SDK

用戶應盡可能升級到最新版本。提供下表以便用戶快速確定是否使用了面向將要刪除的版本的任何元件。

該怎樣做？

為確保您的應用程式在刪除之後繼續正常工作，您應當執行以下操作。

檢查您的應用程式確定使用哪些版本

首先，確定您的應用程式目前使用哪些 REST 版本。如果您的應用程式在控制範圍內，並且確信自身瞭解調用 Azure Storage 的所有元件，那麼您可以對照上方的清單檢查所使用的元件或者檢查您的代碼（如果自行編寫代碼調用儲存）來進行驗證。

為檢查已經部署了哪些版本的元件，可以啟用日誌記錄，將記錄對儲存帳戶提出的請求。日誌包括使用的請求版本，可用於確定將要提出的請求是否包含使用計畫刪除的版本。以下是一個示例日誌條目，並且突出顯示使用的版本–在這種情況下，該請求為匿名 GetBlob 請求（隱式使用 2009-09-19 版本）：

1.0;2011-08-09T18:52:40.9241789Z;GetBlob;AnonymousSuccess;200;18;10;anonymous;;myaccount;blob;”https:// myaccount.blob.core.windows.net/thumbnails/lake.jpg?timeout=30000″;”/myaccount/thumbnails/lake.jpg”;a84aa705-8a85-48c5-b064-b43bd22979c3;0;123.100.2.10;2009-09-19;252;0;265;100;0;;;”0x8CE1B6EA95033D5″;Friday, 09-Aug-11 18:52:40 GMT;;;;”8/9/2011 6:52:40 PM ba98eb12-700b-4d53-9230-33a3330571fc”

需要做出的調整

如果發現任何日誌條目顯示將要刪除的版本，將需要確定是哪個元件，驗證其是否繼續正常運行（由於隱式版本只會不斷增加，未經版本控制的請求可能繼續正常運行－－參見前文），或者採取適當的步驟更改將要使用的版本。通常情況下，將會使用以下兩個步驟之一：

1)      更改請求中指定的版本，通常通過遷移到更高版本的函式庫 /工具來實現。如果可能，請遷移到最新版本以便獲取最新改進和修復。

2)      將預設服務版本設定為目前支援的版本之一，以便先驗證行為再刪除。這種做法僅適用於不含明確版本的匿名請求。

在將應用程式遷移到更新版本時，應查看上方連結的各服務版本的更改清單並進行全面測試，從而確保您的應用程式在更新後仍能正常運行。請注意，包含的服務版本更新包括語法中斷點（請求將收到回應，表明操作失敗或構成方式截然不同）和語義中斷點（請求將收到類似的回應，表明存在一定的差別）。

移轉後驗證的後續操作

完成移轉後驗證後，應驗證確認日誌中沒有任何早期版本。這是確信您的應用程式未使用任何將要刪除的版本的最可靠方式。請務必檢查足夠長時間的日誌，確保沒有任何運行中的任務 / 工作負載使用舊版本（例如，每日運行一次的計畫任務）。

小結

建議使用者立即開始進行應用程式升級，從而避免在 2015 年 8 月 1 日刪除早期服務版本時受到影響。

原文翻譯自 Microsoft Azure Storage Service Version Removal