微服务下的分布式session管理

享学课堂特邀做者：老顾

转载请声明出处！

前言

今天老顾带着你们了解一下session会话在微服务架构中采用的技术方案，以及 企业应用中须要注意的问题。

session做用

咱们知道在web应用中，web服务器和浏览器之间是用http协议进行通讯的，而http协议是无状态的，也就是每一个请求都是独立的。如：用户看一条A新闻，不论是谁看到的都是如出一辙的新闻。也就是跟用户是谁没有任何关系。

但业务自身的发展，须要把不一样的内容展现给不一样的用户，即信息和用户状态关联起来。如：历史阅读列表---列出用户以前看的新闻。这个需求就是跟用户相关，每一个用户看到的历史阅读列表都是不同的。

Session的产生就是为了解决这个问题，把服务器和客户端之间进行状态保持的解决方案。

session原理

浏览器在第一次访问web服务器，服务器端会响应一个sessionId，而且把这个sessionId传输给浏览器，并以cookie保存sessionId到浏览器本地。

之后的访问会把这个cookie的sessionId以请求头的方式传给服务器，这样服务器就能够拿着这个sessionId进行查找，服务器中有没有此sessionId对应的用户，这样就能标识出哪一个用户，若是有用户相关的业务，就是利用这个sessionId返回用户相关的业务。

本质就是浏览器客户端本地保存了sessionId，服务器端保存了sessionId和用户信息映射，这样就实现了web应用有状态化。

单体架构

在早期的单体架构中，也就是只有一台web服务器，虽然在web应用中也进行的分层设计，但其实本质是在代码逻辑级别，自己仍是一个应用而已（或者说就是一个war/jar包）。

这个时期的session都是保存在本地的web服务器内存中，很是简单就能保持用户状态。

集群/分布式架构

随着业务的复杂度升高，和对应用性能、高可用的需求，系统演变成了集群和分布式架构。

集群架构能够看服务器A和服务器B，部署同一个应用A，就是为了提高性能和高可用目的；服务器C是部署了另外一个应用B，表明系统不是单一业务，而是多个应用集合的，即分布式架构。

这个架构中，咱们以前的session方案就会有问题，由于服务器端的session是存放在本地内存中的。请看下面的流程

一、用户A第一次访问系统，由负载均衡器映射到服务器A中

二、会在服务器A的本地内存中，存放着session

三、用户A第二次访问系统，又被随机分配到了服务器B中

四、但服务器B中是没有存放用户A的session的，因此此sessionId在服务器B中找不到对应的session，就会觉得用户没有登陆，就会引导用户去登陆

五、这样就致使session不一致的问题。

session复制

session复制方案是一个服务器端的方案，对客户端是透明的，客户端不须要改变什么。看架构图

这个方案本质是利用了应用服务器自身的特性，如：tomcat。修改一下tomcat的配置文件，就是让应用服务器之间进行session复制，这样就能够达到每一个服务器都有同样的session。

这个方案2-3个服务器还行，但服务器一旦多起来，就会有问题。

一、session之间的复制就会占用很大的网络带宽

二、session复制是有时间延迟的

三、服务器的内存是有限的，表明着session存放是有限的

session粘性

这个方案就利用负载均衡器的特性，把同一个浏览器的同一个用户都定向发送到同一个服务器上。看架构图

上图的核心思路，用户甲访问系统被负载均衡器一直分配到服务器A上，这样也就保证了用户一直在同一个服务器中进行查找session，保证了用户session一致性。

不过此方案也存在一些问题：

一、服务器的内存是有限的，表明着session存放是有限的

二、这个方案适用集群架构，但不适用分布式架构

三、一旦服务器拓展数量，session就会出现混乱

cookie方案

以前的方案都是在服务器端进行改造的，cookie方案是客户端的方案，就是把session信息保存到cookie中，即用户信息保存到cookie中，这样就不须要服务器保存session（用户信息）了。每次请求时，把此cookie传给服务器端，这样服务器端就知道是哪一个用户了。

此方案比较实现比较简单，并且还不占用服务器端的内存资源。可是此方案的问题很大哦。

一、cookie在客户端是有限的，存储容量也是很小的

二、安全是颇有问题的，由于保存在本地，很容易被人拿到

session外部存储

以前的服务器端改造的方案，session都是存储到本地内存中的，致使一些问题。 此外部存储就是把思路进行改变，让session的存储与应用服务器隔离出来，看架构图

这个方案的核心就是把session的存储的地方改造到一个独立的媒介中，这样就不须要和应用服务器耦合了，客户端传入sessionId时，用户信息的映射关系直接到这个独立媒介中去查找。

数据库存储

存储媒介的选择之一就是数据库，就是把session信息存储到数据库中。

好处就是session持久化到数据库中，不会丢失。但性能比较差，由于session的访问是很是频繁的，会对数据库形成很大压力，

Memcache存储

此方案就是把session存储到memcache中，Memcache-Tomcat-Session就是利用tomcat实现session的集中化管理的开源方案，修改tomcat配置就好了，使用扩展的sessionManager替换tomcat默认的Session管理器。

memcache性能比较高，但此方案和tomcat强耦合了，不适合其余的应用服务器，如：jetty。并且memcache无持久化，一旦重启，session就丢失了。

Redis存储

redis存储方案通常结合spring session方式，把session存储到redis中。

这个方案是spring提供的一套Session管理方案，经过一个SessionFilter将全部请求拦截下来，对session进行管理，此方案的好处就是不与应用服务器耦合，能够部署到任何web应用服务器中。redis也是高性能的缓存服务器，且可持久化。这个方案也是官方推荐的。

总结

到这里老顾已经介绍了经常使用的session管理方案，最终推荐的是spring session方式进行session管理，存储在redis中。小伙伴们看到这里是否是感受蛮好了，能够在企业中进行应用了？

若是企业小，项目不复杂，是能够应用了。

但若是系统很复杂，有不少业务系统都是有session的，那么如何对session从业务角度进行管理呢？上面咱们介绍cookie方案，小伙伴们有没有考虑到JWT Token方案，jwt方案又会怎么样？留下二个问题，请小伙伴们仔细思考下。请持续关注老顾的文章，谢谢！！！