在讨论 session 跨域共享问题之前，我们首先要了解 session 做了什么，没做什么
1.HTTP是无状态的，也就是说服务器不知道谁访问过他，但是有时间，又需要我们去保留这个状态比如说用户的登录信息，如果每次访问都要登录，这个用户体验实在是太糟糕了，session 就解决了这个问题，他把用户登录信息维护在服务端，会生成一个JSessionID给客户端，客户端下次访问的时候就带着这个JSessionID,服务端根据这个IP去查找用户信息。
2.当然，session 的缺点也很明显，session 是存在服务器的内存中的，如果 session 过多会影响服务器的性能。因为 session 只在一台服务器里，当有多台服务器的时候，访问别的服务器肯定会失败。
明确了 session所做的事以及它的缺陷之后，解决 session 存在的问题就容易多了，下面我简要说一下5种解决方案
- Session Sticky
- Session复制
- Session集中存储
- Cookie
- Token
Session Sticky：是指让同一客户端的请求，落在同一台服务器上，因为不会落在别的服务器上，所以自然就不会出现跨域问题。但是这个方案的缺点也是非常明显的。就是不管比采用什么算法，用户的请求落在那一台服务器上都是由用户来决定的，可能会造成单点压力，并且如果一台服务器出问题，可能会造成一片区域的人无法访问
Session复制：是指服务器之间互相同步session信息，也就是说每台服务器上都保存着所有的session信息。这样做的缺点也是非常明显的。上文提到过，session 是存在内存中的，会严重影响服务器性能，当然，你也可以把他存在数据库中，但是这会大大影响响应速度。还有一个缺点就是，当访问量过大时，由于相互同步的问题，会造成大量的网络开销
Session 集中存储，是指把 session 集中存储在一个第三方的服务器中，可以是 Redis，可以是数据库或是其他什么东西。当需要访问的时候，都去这个服务器去查。这样做也有不小的缺点，首先是单点问题，如果这个服务器宕机，那么所有的服务器都是不可用的，所以这里必须做集群，会浪费服务器资源。还有一点是，每次验证都需要来这个服务器来查，会凭白增加一次网络开销，降低访问速度
Cookie：状态信息不再保存在服务端，而是保存在客户端，客户端每次访问服务器的时候，把这个信息带给服务器。但是 Cookie 也有不少问题，最被人关注的就是安全问题，因为信息是保存在客户端的，就比较容易盗取、篡改，当然这些安全问题都是有解决方案的，这不是限制 Cookie 的主要原因，真正限制 Cookie 的原因是很多设备不支持Cookie
Token 和 Cookie 类似，Token 也是由客户端来维持状态的，信息存储在客户端内，具有平台无关性。Token实质上是服务端给客户端的一个字符串，上面包含着一些验证信息，相当于一个身份令牌，你拿着这个令牌就能得到他的服务。相比较于 Cookie，Token 更加的灵活，可以在任何地方生成，基于 Token 的权限系统是非常容易实现的