Windows Azure Platform (二十一)多个VM Instance场景下如何处理ASP.NET Session

核心提示：传统的ASP.NET应用程序是无状态的，但是我们可以使用Session来保存用户状态，Windows Azure Platform (二十一)多个VM Instance场景下如何处理ASP.NET Session，比如保存用户名和密码等等，并且在一般情况下，访问速度非常快-微软官方支持缺点：-价格相对上面2个方法来说比

传统的ASP.NET应用程序是无状态的，但是我们可以使用Session来保存用户状态，比如保存用户名和密码等等。并且在一般情况下，一些已经部署好的应用程序的逻辑业务很多情况下都是基于Session状态的，而这个Session状态是保存在我们局域网的Web服务器上的。

如果我们部署单个计算节点(1 instance)的Windows Azure 托管服务，Session就会保存在该托管服务器上。但是这样会遇到一个问题：之前几章我已经提到了，Fabric Controller会自动监控计算节点的的执行状态。如果我们部署的单实例的计算节点遇到了一些问题(比如硬件故障、宕机等)，Fabric Controller会自动找寻不同的服务器并且重新启动该计算节点。那就会让我们的托管服务在短时间内无法正常运行和提供服务，可靠性降低了。

为了提高Windows Azure的可靠性，微软建议一个托管服务至少需要2个instance。这样可以保证某一个计算节点在遇到问题无法提供正常服务的情况下，另外一个计算节点会持续运行并且提供服务。

假设我们已经把Windows Azure的instance count设置成了2个计算节点(比如A和B)，那我们还知道：因为Windows Azure会自动提供负载均衡(Load Balance,LB)的。这样会遇到这样的问题：我们在某一段时间内所有的业务都是由计算节点A来处理的，过了一段时间后A因为去处理比较复杂的计算服务，LB会把我们请求的处理直接交给计算节点B来处理。但是我们保存在A计算节点上的Session状态丢失了！计算节点B不知道之前的Session.

所以说，我们如果要把现有的Web应用程序迁移到Windows Azure平台上，对于Session的处理是需要非常注意的。

一.　　对于一个计算节点(1 instance)的Windows Azure托管服务，使用现有的"Session[SESSION_NAME_KEY]"可以正常处理业务逻辑。但是因为可能因为计算节点遇到硬件故障等等问题，可靠性降低了。

二.　　对于两个计算节点以上(2 instance or more)的Windows Azure托管服务，为了保证Session能够持久化，我们需要在现有的Web应用程序上进行修改：

1)使用Azure Table Storage来保存Session，您可以在这里下载示例代码

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

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

 

 <!--SessionState Provider Configuration-->
    <sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">
      <providers>
        <clear/>
        <add name="TableStorageSessionStateProvider"
             type ="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider"/>
      </providers>
    </sessionState>

 

 

 

-　　原理是就是把我们的Session作为对象保存到Windows Azure的Table里，需要的时候再取出继续使用。

优点:　　

-　　价格相比使用SQL Azure要便宜，Windows Azure Storage每1GB每月只需要0.15美金。

缺点：

-　　不能得到微软的官方支持。

-　　性能可能不是非常好。

-　　需要清理之前已经使用过的Session。

 

2)使用SQL Azure Session Provider来保存Session，具体可以参考MSDN博客。

-　　原理是就是把我们的Session作为对象保存到SQL Azure的Table里，需要的时候再取出继续使用。

优点：

-　　虽然价格比不上使用Table Storage便宜，但是还是可以承受的。

缺点：

-　　不能得到微软的官方支持。

-　　需要清理之前已经使用过的Session。

每次Session 我们会新建一张表来保存Session。对于后续的Session请求，会先查询这张表是否已经存在。所以一旦Session超时，我们就需要删除超时的 Session表。为了自动删除过期的Session，我们大部分使用Windows Azure Worker Role来执行删除表的动作。

3)AppFabric Caching

AppFabric Caching实际上是微软推荐的选项并且得到微软官方支持。 AppFabric Caching分布式内存中的缓存服务。它是自动配置的基础上的Windows Server AppFabric Caching。

优点：

-　　在内存中缓存，访问速度非常快 -　　微软官方支持

缺点：

-　　价格相对上面2个方法来说比较高。起始价格是128M 45美金 ，最高是4GB 325美金。