从单实例部署到负载均衡的演变

还记得刚开始学java ee的时候跑个tomcat然后可以访问就已经很开心和满足了。但是真实的项目部署都是业务服务器多实例部署，通过nginx反向代理，然后代理服务器nginx还需要做主备容灾预防。今天我们就来看一看这其中的演变过程。

一、单实例部署

单实例的时候我们对用户登录管理一般采用的都是session，毕竟所有用户的登录及其后续操作全部都是在一个实例上，所以他们的session也就在这个实例内，不需要做任何处理就可以了。

二、nginx反向代理单实例

有时候我们并不想将我们的业务服务器（tomcat）对外网进行暴露，这样可能存在一些安全隐患。所以这里就需要nginx登场了，nginx作为一个反向代理服务器，可以对外代理我们的业务服务器接收所有的请求。这样我们的业务服务器只对内网的nginx服务器暴露，外网访问不到。然后我们将nginx对外网可访问，通过nginx这个唯一的访问入口来访问内网的业务实例。

以上虽然解决了业务服务器不直接对外暴露的问题，但我们的用户登录校验就不能采用session了，因为我们访问的是nginx，nginx请求过来的session和用户直接访问业务服务器获取的session并不是同一个。不过不用session也没关系，毕竟这个问题早就被考虑过了。这个时候我们可以用cookie做用户登录鉴权，毕竟cookie是放在客户端管理的，你登录了后我就给你回写一个cookie，下次你再来访问的时候将这个cookie带上，我也就知道你是已经登录了。打个比方吧：以前的登录凭证在业务服务器那管理着，你是直接访问业务服务器的，所以业务服务器知道你是否已经登录了，但是现在你并不是直接访问业务服务器，而是访问nginx，nginx访问的业务服务器，这时业务服务器就不知道这个请求是你发起的，它只会认为发起请求的是nginx，所以也就没办法判断你是否已经登录过了。而使用cookie的话，你登录成功后业务服务器给你回写一个cookie登录成功的标识，然后你下次访问nginx的时候将cookie带上，nginx也会带上你的cookie去访问业务服务器，这时候业务服务器就可以根据cookie判断你是否已经登录了。

三、nginx反向代理多实例

当我们的业务量增长到单个业务服务器不能够承受的时候，这时就需要部署多个业务服务器了。nginx反向代理自带负载均衡，你可以根据不同的业务需求配置相对应的负载均衡规则。有同一个请求IP命中同一个业务服务器、多个业务服务器轮流处理每一个请求、将该次请求转发到当前处理请求数最少的业务服务器等等，具体配置可以看我上一篇文章“Nginx负载均衡配置”。这里也就不多说明了。

多实例配置好后我们的登录鉴权是不是也需要做相对应的修改呢，毕竟现在业务服务器不是一个了，你具体在哪一台服务器上登录的其它服务器可能并不知道。所以这里就引入了session集中管理，我们可以将多个业务服务器登录后的session统一保存到数据库，鉴权操作均去数据库内查询该用户是否登录的session。不过查询数据库并不是最好的解决方案，如果我们将登录凭证放在redis或其他一些缓存服务器的话，这样查询效率会高很多，而且对我们的数据库也不会产生压力。将多个业务服务器登录凭证保存到redis等缓存服务器，这时的session我们就叫它token了。所有业务服务器登录成功后都在redis内保存一个token，所有鉴权操作都去唯一的缓存服务器redis查询该用户是否登录，这样我们就解决了多服务器session共享问题。

四、nginx主备部署

虽然解决了请求量增长，多实例部署和session共享问题，但是有没有发现现在存在一个单点问题，如果我们的反向代理服务器nginx宕机了怎么办？这时再多的业务服务器都没用啊，因为它们都是部署在内网，外网访问不到。所以我们就需要对这个对外暴露的单点nginx做主备部署，这样主nginx宕机了还有备用的nginx可以使用。

但是我们怎么部署主备呢，又怎么解决它们两之间的通信问题？这时就是keepalive登场的时候了，keepalive可以在两台服务器间实时报告当前心跳是否正常，如果主nginx宕机了，从nginx可以及时的知道，然后立即将主nginx的任务接收过来，所有请求访问的都是从nginx，这时就不怕单点问题了。而且keepalive还可以配置切换时发送邮件，也就是主nginx切换到从nginx时可以发送邮件到指定的邮箱。我们接收到邮件后就知道主nginx宕机了，这时可以及时的排查问题，恢复主nginx，主服务器keepalive恢复后会给从服务器发送心跳，这是从服务器接收到后就会将所有任务转交给主服务器，从服务器继续监听主服务器心跳是否正常以做好随时切换的准备。

以上就是主从nginx反向代理多个业务服务器的全部了，到这时我们访问的是一个虚拟ip，这个ip 背后是主nginx的ip(主nginx宕机了该虚拟ip背后就是从nginx的ip)，然后nginx会根据你配置的相应代理规则访问到多个业务服务器中的一个，业务服务器会去缓存服务器redis查询登录结果，然后处理业务逻辑，最后将结果返回给终端调用者。

以上部署后就不需要担心用户量上涨单个业务服务器处理不过来的问题，解决多个服务器session共享问题。还可以将业务服务器隐藏在内网不对外暴露。