我们最早期开发的网站都是单应用 也就是 一台 web应用 和 一个 数据库 部署在一个服务器上。入下图所示
单应用的好处我们可以快速开发出我们的web项目并进行项目的上线。
当我们的项目的负载越来越高 我们可能考虑要将web应用和数据库部署在不同的服务器上 来提升我们项目的负载。框架结构图如下
由于web 应用是单台服务器，如果我们的项目宕机。我们恢复网站需要花费很长时间。那怎么解决累 我们可以多搞几个相同的web应用服务器 如果一台宕掉 我们可以切换到下一个web应用服务。也就是我们说的集群。这样参生了新的问题：一个域名只能对应一个服务器ip 我们无法做到一个服务器宕机后平滑的切换到另一台服务器上。 就是我们切换的另一个服务器上 那还需要进行域名和ip的重新绑定 另外域名和ip的绑定也不是实时的。这时候我们就需要一个服务器来处理不同服务器间的切换 。这时候 可以通过nginx 搭建反向代理服务 ，通过nginx 进行服务器间的切换 而我们的域名和nginx 进行绑定。这样我们就可以保证当一台服务器宕机后，可以快速切换到下一个个可用的服务器上。保证我们的网站可以一个提供服务。框架图如下
当我们访问网站的时候可以通过nginx 切换到不同的web应用， 但是我们不同web应用 服务间session是不同步的。也就是说如果用户访问网站进行登录 通过nginx访问 A 服务上登录成功后将用户信息保存到session中 在次访问是是跳转到了B 服务，但是此时B服务是不持有A 服务上的session的。这是后会让用户在次登录。关于session同步我们有以下几种解决方案：
1 同步服务器间的session 也就是如果用户在A服务器登录后保存用户信息到Session中然后再将该Session同步到B服务器中
2 nginx采用ip_hash的轮询方法 将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起 稳固 的session。
3 将session信息保存到redis或者memched。
4 将用户信息保存到cokie中 这样做安全用户信息容易泄露。
我这里建议采用 nginx 采用ip_hash 或者使用 redis或者memched进行处理。通过nginx 搭建集群环境 也可以理解为垂直应用部署。我们发现我们的系统比以前稳定了 但是随着我们的项目业务越来越多 每次我们修改一个模块的代码会格外小心，我们只是修改商品模块的业务，商品业务代码中一行代码有问题。结果导致 导致整个项目就瘫痪掉了，还有就是比如一个购物网站 进行秒杀活动 我们不能针对单个功能去针对性的提升服务器性能。
上述问题在往下延伸 就考虑将我们的项目 进行服务化拆分，我们可以将商品模块 和订单模块 拆分为单独的服务。这样如果修改商品的业务并不会影响到我们的订单业务。同时
这是我们可能考虑将我们的模块进行服务化拆分 我们可以将我么的商品模块 和订单模块拆分为单独的服务 这样的化我们修改商品服务 并不会影响到订单服务。
随着子系统的继续庞大我们会有越来越多的子服务 每个服务配置一个nginx 节点 其维护程度比较费劲，另外一旦某个nginx 节点瘫痪 会造成我们单个服务的瘫痪。我们可以通过ZooKeeper来解决这个问题
ZooKeeper负载均衡的实现思路
把ZooKeeper作为一个服务的注册中心，在其中登记每个服务，每台服务器知道自己是属于哪个服务，在服务器启动时，自己向所属服务进行登记，这样，一个树形的服务结构就呈现出来了。服务的调用者到注册中心里面查找：能提供所需服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接。调用者取到服务器列表后，就可以缓存到自己内部，省得下次再取，当服务器列表发生变化，例如某台服务器宕机下线，或者新加了服务器，ZooKeeper会自动通知调用者重新获取服务器列表,把ZooKeeper作为服务的注册和变更通知中心，解决了Nginx负载均衡方案带来的问题。
有了Zookeeper 我们不得不提到阿里开源的框架dubbo。Dubbo的将注册中心进行抽象 是得它可以外接不同的存储媒介给注册中心提供服务。其实Dubbo就是一个框架 使我们更好的使用ZooKeeper 或者其他注册中心服务。
参考文档：https://blog.csdn.net/yongche_shi/article/details/51514131
https://www.cnblogs.com/xiaofei1208/p/7077733.html