使用Microsoft Azure 让云迁移变得简便的5种方法-51CTO.COM

开发者们接受Microsoft Windows Azure的速度异乎寻常的快。因为它是基于Windows 和 .NET的，所以它和开发者们现有的应用程序是高度兼容的，使用Microsoft Windows Azure作为云平台的话，应用程序可以很轻松地迁移到云中。

通常，一个应用程序要迁移到云中，需要经过两个关键性的阶段。第一个阶段是尽可能地少做改动，让它可以“原封不动”地在Microsoft Azure中发挥作用，在这个阶段，只改变那些不得不改变的地方就可以了。第二个阶段是对这个应用程序的一些组件进行升级，让你的应用程序可以利用上那些Microsoft Azure提供的独一无二的能力。

在本文中，我们将会讨论一些在完成第一个阶段（只要可以在Microsoft Azure中正常工作就可以了）的过程中遇到的问题。大多数的迁移项目都是从“云适应性”分析开始的，这可以帮助你识别出要完成迁移，哪些部分需要做一些额外的工作。当你正在进行第一个阶段的时候，搞清楚你的系统架构是至关重要的，同时，你要让必须要做的代码变更最小化。如果你使用一个完整的单元测试套件来构建你的系统，那么现在你可以开始欢呼雀跃了。

1，数据迁移

从应用程序的底层开始，我们就不得不面对我们应该把数据存储到哪里，以及如何存储的问题。最常见的ASP.NET应用程序使用SQL Server把数据存储在关系数据模型中。无论你的代码如何使用这些数据（Entity Framework, nHibernate, ADO.NET等），你都应该关注一下如何把SQL数据库迁移到SQL Azure中。这样做的话，可以让你的应用程序处于“near data”的场景之中，在这种场景中，应用程序可以保持高度的响应性。

一个Microsoft Azure中的应用程序完全可以通过一个内置的SQL Server来连接和使用数据，但是这样做的话，会创建一个“far data”的场景。在这种场景中，数据访问的延迟会很大，而且性能也会有所降低。

SQL Azure和SQL Server是高度兼容的，所以迁移起来并不是很困难，对于那些小型数据库来说，情况更是如此。你必须要留意一下你自己可以使用的SQL Azure数据库的最大尺寸，目前，这个最大尺寸是50GB。如果你的数据库比这个尺寸还要大，那么你必须对你的数据进行分割。

有一个叫作SQL Azure Migration Wizard的开源工具可以帮助你完成这个任务，你可以使用它来分析和迁移你的数据。它可以分析你当前的模式，指出和SQL Azure不兼容的地方，然后帮助你修改这些地方。再然后，它可以在后台使用BCP，把你的数据迁移到云中。你可以在这个页面中找到这个工具。

长期来看，你可以对你的数据进行分析，判断出哪些数据从本质上来说是非关系型的，然后把它们迁移到Windows Azure Table storage中。

#p#

2，ASP.NET的Session状态

许多ASP.NET的Web应用程序使用Session状态来跟踪一个用户使用这个应用程序的行为。这可能是他们的配置信息，一个购物框，或者他们在一个业务流程中的具体位置。Session状态是一个强大的工具（如果不过度使用的话），它可以让无状态的环境具有状态。

由于许多Web程序都依赖Session状态，所以它们的负载均衡器都是针对“粘性的session”来配置的。这意味着一旦用户开始使用你的站点，那么他们总是要回到服务器集群中的同一个服务器中（至少在这个Session期间是这样的）。这使得把状态保存在那个特定的Web服务器的某个进程的内存中成为可能。我不是很喜欢这种方法，因为，随着时间的推移，这种方法会导致负载出现不均衡，而且，当一个服务器出现问题的时候，这会导致可靠性方面的盲点。如果一个服务器挂掉了，那么用户会和那个服务器一起挂掉。

因为Microsoft Azure中的负载均衡器是非粘性的，所以你可以找到一种方法，让Session状态对Azure环境中的每个服务器都可用。谢天谢地，ASP.NET中的Session状态机制使用的是提供者模式。在这种模式中，你可以更换新的提供程序来改变Session状态在Web服务器集群中的存储方式和托管方式。你可以通过部署一个程序集，然后改变web.config中的某些设置的方式来改变你正在使用的提供程序。

ASP.NET带有三个默认的提供程序。最常见的是进程内内存提供程序，它的行为如上所述。第二个提供程序是一个状态服务器，这是一个专用的服务器，它可以把状态保存在它自己的内存中。另外一个提供程序是SQL Server提供程序，它可以把Session状态存储到一个SQL Server数据库中。对于用户来说，由于每个Web服务器都可以从这个数据库载入合适的Session，所以，现在用户可以在整个集群中任意跳转了。

虽然在Microsoft Azure中，你可以使用SQL Server提供程序，然后把它指向一个SQL Azure数据库，但是使用基于Windows Azure Storage的提供程序会更好一些。使用这个提供程序，Session中的条目可以放在一个和每个用户相对应的Azure Table中，或者应用程序中。由于状态的确切尺寸和形态不可以提前预知，所以真正的状态会被作为一个文件存储在一个Azure Blob容器中。

你可以通过查找Windows Azure Platform Training kit来下载这个提供程序。在这个工具包中，有一个叫作AspProviders样例项目。你可以直接把这个项目添加到你的解决方案中，也可以使用程序集引用的方式，把那个DLL添加到你的项目中。

如果你引用了这个程序集，那么你必须修改你的web.config文件。打开你的配置文件，然后找到<system.web>元素。删除现有的<sessionState>配置，然后把下面的代码粘贴上去。当你这么做的时候，记得把你真正的应用程序名写上去。

<add name="TableStorageSessionStateProvider"

type= "Microsoft.Samples.ServiceHosting.AspProviders.

TableStorageSessionStateProvider"

applicationName="yourWebAppName"/>

</providers>

</sessionState>

#p#

3，配置

许多Web应用程序都使用web.config来存储运行时配置。这很方便，而且也很安全（尽管如此，你还是应该养成对敏感的信息进行加密的良好习惯）。我们这样做的一个优势是当应用程序正在运行的时候也可以修改配置（尽管这会导致重启）。

当你把你的Web应用程序部署到Windows Azure中的时候，你的软件包会作为一个只读的软件包部署到你的Web角色实例中。这意味着，你的项目中的所有文件在运行时都不可以被修改，包括web.config文件。这就意味着，如果你想修改web.config文件，你必须重新部署整个应用程序，这可不是一件轻松的事情。

解决这个问题的最好方法是去除这个限制，或者对你的配置进行重构，把它存储在Microsoft Azure项目的ServiceConfiguration.cscfg文件中。在这个配置文件中的数据在运行时可以被编辑（这也会导致重启）。

把你的配置迁移到cscfg文件中需要三个步骤。首先，你必须在ServiceDefinition.csdef文件中定义配置元素。如果我们正在迁移一个以“maximum money laundering limit”作为业务规则的配置元素，那么可以这样来定义：

</ConfigurationSettings>

完成这个任务以后，你可以把这个设置添加到你的ServiceConfiguration.cscfg文件中，如下所示。我们把我们当前的限制设置为100000美金。

</ConfigurationSettings>

你必须要从头到尾地查看你的代码，然后修改你用来读取配置的那些代码。但愿你已经把你的应用程序读取配置的代码抽象成一个类了，这样的话，所有读取配置的代码都在同一个地方，会更容易修改一些。在这种情况下，你可以这样修改读取配置的代码：

string s = RoleEnvironment.GetConfigurationSettingValue("MaxMoneyLaunderingLimit");

你可以通过门户站点，手工修改cscfg文件的内容，或者，你也可以使用Service Management API来上传一个新的配置文件。当你这么做的时候，为了应用新的配置，你的应用程序会被重启，然后RoleEnvironmentChanging事件会被触发，提醒你你的配置已经被改变了。

#p#

4，文件系统的使用

许多Web应用程序都会对文件系统进行读取和写入。它们对文件系统的使用通常都很简单，也很直接。这可能是最麻烦的修改了，因为你必须要对代码进行修改。

为什么在云中这是一个问题？因为运行你的代码的那个Web服务器是无状态的，在任何时候，它都可以被销毁和重新创建。因为是无状态的，所以在正常情况下，你是无法使用本地磁盘的。

如果你只把文件系统当成一个临时的存储空间来使用，例如存储一个上传文件，然后读取它，把它载入到数据库中，那么使用“本地存储器”会更合适一些。“本地存储器”是Microsoft Azure的一个功能，它可以在服务器上给你分配一块本地磁盘，让你随意地使用。你必须在csdef文件中对“本地存储器”进行配置，然后通过RoleEnvironment对象载入路径。“本地存储器”是不稳定的，这意味着无法保证这个存储器在指定的时间段里一直是可用的。

要配置你需要的本地存储空间，可以把下面这段代码添加到你的csdef文件的角色配置中，然后给你请求的空间提供一个名字。你可以请求多个本地存储器。如果在你的代码中，你通常要使用好几个文件夹，那么这会十分方便的。

</LocalResources>

在你使用这块磁盘空间以前，你必须首先读入分配给你的文件夹的物理路径。如果你使用这两行代码获取到了这个路径，那么你用于处理常规文件的代码就可以正常发挥作用了。

LocalResource localCache = RoleEnvironment.GetLocalResource("TempUploads");

string localCacheRootDirectory = localCache.RootPath;

在迁移直接对文件系统进行读取和写入的代码的过程中，你的第二个选择是把你的代码转换为使用Azure Blob存储器的代码。虽然这需要对代码进行一些修改，但是这种迁移方式可以让你使用上更加快速的云。

如果在迁移过程中，你可以把代码修改到这种程度，那么你可以考虑第三个选择了，那就是使用Microsoft Azure Drive。这是一个被格式化为NTFS驱动器的blob（可以把它看成一个虚拟PC的VHD文件）。这个文件被格式化为一个驱动器，在你的角色实例上，它可以作为一个本地驱动器被载入。一个Azure驱动器可以被挂载到多个服务器实例中，只要它是只读的就可以了。如果你想对这个驱动器进行写入操作，那么你只能把它挂载到一个实例中。

这个模型和本地存储模型十分类似。你可以对挂载的驱动器进行配置，也可以使用一些代码在运行时判断物理驱动器名和被挂载的驱动器的路径。一旦你得到了这个路径，你的代码就可以像平常那样发挥作用了。

对于Windows Azure Drive来说，一个重要的性能提升是确保你可以把一些本地存储器配置成这个驱动器的缓存。这是通过内置的驱动器API来实现的，在性能上有很大的提升。

#p#

5，在云中的身份标识

许多Web应用程序都通过集成的身份验证来给内部用户提供无缝的身份验证体验的。当用户浏览你的站点的时候，他们已经登录到他们的桌面了，他们的Windows身份标识会被传输到Web应用程序中。他们是在毫不知情的情况下登录的。

当服务器不在用户的域中，也不在同一个网络中的时候，这个流程就无法发挥作用了。当你把一个应用程序迁移到云中的时候，用户必须要登录到这个应用程序才可以使用这个应用程序，这样的话，他们会十分困惑的。

要把你的内部用户标识和云联系起来，最简单的方法就是使用一种叫作“联合身份标识”的概念。“联合身份标识”（Federated Identity）是基于开放标准的，既支持OAuth又支持SAML。使用这些协议你可以把你的应用程序配置成信任来自于你的域中的用户的身份标识。

要做到这一点，你必须要使用Windows Azure AppFabric ACS服务才可以，这是一个在云中的身份验证服务。在你的公司中，你还必须要有一个安全标记服务器。大多数公司使用Windows Server Active Directory Federation Services v2。如果配置好了这个服务，那么，当用户访问你的站点的时候，他们的身份标识就会通过ACS，从ADFSv2服务器传输到你的应用程序中。这可以给用户提供无缝的登录体验，而且，对你的代码的修改也最少。

如果你已经开始使用ACS和“联合身份标识”了，那么你可以和一些商业合作伙伴，提供商，以及客户结成同盟。这可以让他们更容易地登录到你的系统中。值得注意的是，只有你希望共享的身份标识才应该被共享（他们是谁，他们属于哪些组）。真正的凭证不应该被共享（例如密码或智能卡）。

#p#

总结

Microsoft Azure是基于Windows Server的，SQL Azure是基于SQL Server。这让Microsoft Azure平台成为了一个高度兼容的环境。这可以让应用程序从内部环境迁移到云中的过程变得更加容易。

注意，我说的是更加容易，而不是容易。迁移你的应用程序所花费的时间长短是由架构和你的应用程序的代码来决定的。在几个星期中，我已经帮助许多客户把他们重要的Web应用程序迁移到云中了。当然，迁移结束以后，应该在这个全新的，基于云的系统上进行大量的测试，来确保这个系统可以正常工作。

原文名：5 Ways to Use Microsoft Azure to Ease Cloud Migration 作者：Brian Prince

【本文乃51CTO精选译文，转载请标明出处！】

【编辑推荐】