架构思想之-从单点登录来聊聊服务无状态化

什么是服务无状态化？

服务无状态化总的来讲就是一句话，各个进程之间保证时刻对等。
说了等于没说。下面看一张图把。

上图中的网关层面就得保证服务无状态化，加入我们在网关层校验用户是否登录（session是否存在）。那么用户的session绝对不能存在网关服务上的。因为如果存在网关服务上，那么当用户在一个网关上登录，然后被路由到另外一个网关上还得重新登录。所以我们网关上不保存任何用户数据。即 即使任何一台网关挂掉、或者扩容新的网关都不会影响用户登录这个请求。

为什么要保证服务的无状态化呢？

其实这个很简单，现在的微服务场景，服务冗余是保证高可用的重要手段。你的服务得能快速扩容、缩容。那么你快速部署上去的一台服务。如果跟其他服务不对等。岂不是会很爆炸。

单点登录的实现怎么保证服务无状态化？

常见的两种思路：
1、当用户登录之后服务端将session加密后返回给客户端，客户端每次请求都带上这个session
2、当用户登录成功后服务端将session全部保存在redis集群里。

这两种思路都能保证网关无状态化，可以思考一下，网关挂一台、或者新增一台。是不是不会影响用户登录的请求。

方案一问题：（一般不推荐）
1、每次请求都要带上session，无故带来带宽开销
2、session保存客户端不太靠谱。有被篡改的风险，且客户端不可靠，容易丢失。

方案二问题：
保存在redis集群中怎么保证session的存取问题？大家知道redis cluster 存在key节点飘逸问题

上面就会有节点飘逸的问题。那如果A节点立马又连上了。那岂不是A上的老数据存在版本问题？
所以redis cluster 来解决单点登录问题，你得考虑的问题很多，且很没必要。

带来的问题怎么解决？

不使用redis cluster集群试试？

看似很美好吧。那么如果三台机器不够用了怎么办？需要扩容成6台机器咋办？

解决方案：
1、客户端做好静默登录的功能
2、在流量低峰期进行扩容机器。

思考：那岂不是扩容的时候用户全部变成未登录状态？是的，所以要求客户端支持静默登录。且要在流量低峰期操作。这样慢慢随着用户的使用。就会将新的session保存到 6台服务器上去。等到你的流量高峰时。用户基本都已经登录完成了。

首先 你的redis扩容不是天天干，所以这样的实现方式，比较推荐。

静默登录：就是客户端保存好用户输入的账户密码。当服务端返回为登录时。自动帮用户登录一下。