分布式WEB应用中会话管理的变迁之路

Session一词直译为“会话”，意指有始有终的一系列动作／消息。Session是Web应用蓬勃发展的产物之一，在Web应用中隐含有“面向连接”和“状态保持”两个含义，同时也指代了Web服务器与客户端之间进行状态保持的解决方案。

在Web应用诞生之初，应用服务器不浏览器之间仅仅只是基于HTTP协议进行通信。而HTTP协议是无状态的，也就是说每一个请求之间都是相于独立的，互不关联。但是随着应用业务复杂化，服务器需要按照用户的一系列业务操作向用户提供某些特定的、按需的内容。这时候就需要通过保存用户状态，将用户的请求关联起来。Session管理正是这一问题的解决方案。

早期的Web应用基本都采用的是单体架构，也就是把一个使用了分层架构的Web应用部署在单节点Web服务器上的架构类型。在这种架构中，虽然采用了分层架构，将整个应用分为了表现层、业务逻辑层和数据访问层，每一层各司其职，让Web应用的各个方面都有所改善。但这样的分层只是停留于逻辑上。由于将所有代码部署在单个服务器节点上，随着应用不断迭代开发，单体应用将会发展成巨石型应用，臃肿不堪，难以维护。

在这样的单体架构中，由于所有的用户请求都是由这个唯一的服务器进行响应处理，所以只要把保存了用户信息和状态的Session对象，存放在应用服务器内存里，就能轻松地达到保持用户状态的目的。

随着Web应用的发展，用户访问量和业务复杂度与日俱增，应用的性能和代码的维护难度成为应用的瓶颈，为了突破瓶颈，开发者开始尝试在应用架构中引入负载均衡器，继而演化出了集群和分布式两种架构类型。

集群，是指在多个服务器节点上部署相同的应用，例如上图中的服务器B和C，然后通过负载均衡器的分发功能，把用户请求分发到集群中的任意一个服务器节点上。如果有更大的访问量，只要向集群中增加服务器节点，就能改善压力。集群既能保证应用的高可用，又能提高应用的负载能力。

分布式，是把原来的单体架构应用，通过分而治之的手段，按照业务功能，切分成一些小的模块应用，部署在不同服务器节点上，例如上图中的服务器A和B。然后通过负载均衡器和门户应用整合起来，组成一个完整的应用。

集群和分布式架构中，后端包含了多个服务器节点。当用户进行登录时，登录请求是由其中一个服务器节点进行响应，而后续的用户请求将可能被负载均衡器分发到其他服务器节点，这时候就可能因为这个服务器节点上没有用户Session，导致服务器判定用户是未登录状态，让用户重新登录。

所以，在集群和分布式架构中，必须保证用户进行登陆后，架极中的所有服务器节点都能共享Session数据。常用的Session管理方案有如下3种：
1、将Session对象保存在Cookie，然后存放在浏览器端。每次浏览器向服务器发送请求的时候，都会把整个Session对象放在请求里一起发送到服务器，以此来实现Session共享。这样的方案实现起来特别方便，但是由于Cookie的存储容量比较小，所以这个方案只适用于Session数据量小的场景。

2、Session复制。部分应用服务器能够支持Session复制功能，例如Tomcat。用户可以通过修改配置文件，让应用服务器进行Session复制，保持每一个服务节点的Session数据达到一致。但是这个方案的实现依赖于应用服务器。当应用被大量用户访问时，每个服务器都需要有一部分内存用来存放Session，同时因为大量Session通过网路传输进行复制，将会卙用网络资源，迓可能因为网络延迟导致程序异常。

3、Session粘滞。利用负载均衡器的分发能力，将同一浏览器上同一用户的请求，都定向发送到固定服务器上，让这个服务器处理诠用户的所有请求，这样只要这个服务器上保存了用户Session，就能保讷用户的状态一致性。但是这个方案依赖于负载均衡器，而丏只适用于横向扩展的集群场景，不能满赼分布式场景。

4、Session集中管理。这边我简单介绍一下Spring Session。Spring Session是Spring提供的一套Session管理方案，通过一个SessionFilter将所有访问应用的请求都拦截下来，然后使用Request包装类接管Session管理。将session从web容器中拦截下来后，Session会被存储在独立的存储服务器中。目前支持多种形式的session存储器：Redis、Database、MogonDB等。当request进入web容器，根据request获取session时，由Spring Session负责存存储器中获取session，如果存在则返回，如果不存在则创建并持久化至存储器中。Spring Session不与应用服务器耦合，能适用于常规服务器。同时还提供了在浏览器下对同一应用存储多个 Session等功能。