Microsoft Azure 存储服务版本删除公告

Article
12/10/2014

原文地址：https://azure.microsoft.com/blog/2014/08/04/microsoft-azure-storage-service-version-removal/

WinAzure Storage美国高级项目经理

存储服务于 2008 年首次推出，自此以后我们推出了7 个更新版本，每一版都会对协议进行精炼并添加新功能。我们宣布，即将删除一些早期版本的REST API。本文将会介绍确保应用程序在删除这些版本之后继续良好运行需要了解的所有注意事项。

背景：存储服务版本控制

什么是版本控制

Azure存储通过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使用哪个版本均是如此）。

您可以在MSDN上查找用于确定请求版本的完整规则。

客户端库和工具

我们的很多用户使用微软提供的存储客户端库开发其应用程序。其中每个客户端库基本上都绑定到特定版本的REST API。这项规则也适用于PowerShell cmdlets和AzCopy。存储模拟器支持发布对应版本的存储模拟器时发布的各种版本的REST API。

发生了哪些变化？

我们的版本控制方法未做改变－－每当做出的调整可能会破坏现有应用程序时，都将继续推出新版REST API。但现在，我们即将删除存储服务诞生早期发布的一些初期服务版本。

删除版本详细信息

将会删除哪些版本？

我们将于 2015 年 8 月 1 日前删除版本2012-02-12之前的全部版本。其中包括以下版本：

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

以下版本不受影响并将继续提供全面支持：

何时删除这些版本？

我们将于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 查询字符串参数对请求进行明确的版本控制，这样即便无法指定自定义头的客户端，也可通过在查询字符串中包含此参数来指定版本。有关Azure存储版本控制讨论及需要遵循的最佳实践，请参阅MSDN。

最低支持版本/库/SDK

用户应尽可能升级到最新版本。提供下表以便用户快速确定是否使用了面向将要删除的版本的任何组件。

语言	最早支持的版本使用服务版本 2012-02-12 或更高版本
.NET	2.0。最先纳入Azure SDK 版本 2.1。
Java	0.3
C++	全部
Windows Phone	全部
WinRT	全部
Android	全部
PHP	发布的版本当前均不支持版本 2012-02-12 – 即将发布更新。
Node.js	当前发布的版本支持 2012-02-12
Ruby	当前发布的版本支持2012-02-12
Python	当前发布的版本支持2012-02-12
PowerShell	全部
CLI	当前发布的版本支持2012-02-12

我该怎样做？

为确保您的应用程序在删除之后继续正常工作，您应当执行以下操作。

检查您的应用程序确定使用哪些版本

首先，确定您的应用程序目前使用哪些REST版本。如果您的应用程序在控制范围内，并且确信自身了解调用Azure存储的所有组件，那么您可以对照上方的列表检查所使用的组件或者检查您的代码（如果自行编写代码调用存储）来进行验证。

为检查已经部署了哪些版本的组件，可以启用日志记录，将记录对存储帐户提出的请求。日志包括使用的请求版本，可用于确定将要提出的请求是否包含使用计划删除的版本。以下是一个示例日志条目，并且突出显示使用的版本–在这种情况下，该请求为匿名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 日删除早期服务版本时受到影响。

Share via