背景
最开始,系统是单机部署,如下图:
这样的部署方式,如果主机 A 宕机,那么系统只能停止服务,等待处理。
为了让系统一直保持运行状态,就需要一种机制来解决上述问题,没错,负载均衡(LB)。都知道 NG 本身支持负载均衡,但有局限性(因为域名只能解析到一个 IP),部署方式变为:
这种部署,虽然做了负载均衡,但还是避免不了主机 A 宕机时,系统只能停止服务的问题。
要解决这个问题,可能需要一种类似一个 IP 绑定多台主机的解决方案(目前没能力实现),这样,域名解析到的 IP 可以多机切换,永不宕机,云服务商提供了这种服务,部署方式变为:
这样就解决了宕机问题。
正文
宕机问题解决了,多机部署后,程序的登录问题怎么解决呢?对,没错,Session 共享,套路就是将 session 持久化,目前的实现方式是生成一个 SessionId,将它分别保存到 Redis 和 Cookie 中,每次请求时查看 Cookie 中的 SessionId 是否在于 Redis 中,然后再决定是否保持新的 SessionId,这里就不细说了。
做了 Session 共享,本地测试通过,但是测试环境登录信息一直无法保存,费了老大的劲,终于将问题定位到 Cookie 的 domain 上,RFC 2109 中有这么一段:
4.3.2 Rejecting Cookies
The value for the request-host does not domain-match the Domain
attribute.
意思是请求的主机与域不匹配时会拒绝 Cookie。
测试环境是将不同的域名解析到同一个 IP 上,然后再用 NG 代理不同的端口,这样导致每一次请求主机和域都匹配不上,每次都创建新的 SessionId,所以登录信息无法保存。
领取专属 10元无门槛券
私享最新 技术干货