Java小白如何理解服务负载均衡动静分离分布式和集群

–学技术不仅仅要学习他了形式还要学习他解决了什么问题，在接触的人和对自己学习的反思发现其实很多时候还是忽略了这个技术主要解决了什么问题。技术或是架构是为了解决问题或是替代现有的技术更好的解决问题的，沿着解决问题这条线就更有兴趣也更加有体会。

单体应用在web容器中可以处理的请求是有限的，太多了会造成服务器过载宕机，比如tomcat默认最大连接数是100个，连接太多会降低服务器的性能，影响程序运行速度请求的响应响应速度。假如在极端情况下，每秒有1万个请求，tomcat在服务器的linux环境下最多可以并发处理2000个请求（网络数据和服务器性能有关），假如4000个请求的时候服务器会很卡，6000个请求的时候服务器会宕机，这时候怎么办。又不能放弃剩下的8000个请求，有人说我们可以让他等待，在Tomcat中配置最大连接数，让他的请求等着，假如这两个请求的平均响应时间是2秒，简单粗暴的算一下最后一批请求已经到了10秒了，一个简单的查询几个字段操作，要等10秒这是让人受不了的，而且服务器一旦出错宕机，单体应用直接就死掉了，不能访问，所以负载均衡出现了：
一共有两种负载均衡方案：
1，软件负载均衡
市面上常见的是negix，可以和tomcat集成，在Tomcat中直接配置就行，他的原理就是部署多个web应用服务，请求先进入negix，通过negix对请求进行一下路由，再进入真正的web应用，其中一台应用宕掉，还有另一台进行应用支撑服务。但是每台应用的session是不共享的，所以原来请求宕机服务器的用户的数据会丢失，所以需要配置session共享。
2，硬件负载均衡
这种方式也是部署启用多个应用服务，通过网线连接应用服务器，进行请求的路由代理。市面上比较常见的是f5，效率和性能要比上面的negix要强，也不用配置session共享，缺点就是机器偏贵，成本偏高。
对于web项目静态文件比较多的或是进场更换静态文件的，比如渲染界面所需要的html，js，css或是图片json文件，这些文件多了，会导致服务器的io阻塞，所以就有了将这些文件统一规整到一个io性能比较高的服务器上，而需要处理动态请求的应用程序包部署到另外一个服务器上，这样web应用会减少很大的压力，从而更快速地响应用户的请求，这叫负载均衡的集群服务。
随着网络用户的越来越多，应用的越来越复杂化，单体应用的某些功能有的时候需要可插拔也需要不性能的服务器去做支撑（比如说有的模块需要运算能力强的有的需要io吞吐量大的），同时也需要更合理的管理服务器（比如说以太老的服务器和一台新的服务器怎么用，可以将调用次数多计算压力大的模块应用拆分到新的服务器上，而老的服务器），将单体应用的各个模块的拆分势在必行，如何完成各个模块在不同服务器之间的通信成了问题，首先基于sokect或是webservice的传统io通信方式效率太低，容易产生阻塞，在复杂和大数据量的情况下完全支撑不起来，zookeeper加dubbo这种注册中心加NIO（netty框架）的方式方便了模块服务的管理，加快的系统间的通信速度和数据量。同时也使系统容错性更高稳定性更强，比如说qq和QQ游戏还有QQ邮箱，比如说很不幸qq游戏应用功能有bug所有的服务器都挂掉了，如果是单体或是上面的负载均衡的方式，那qq和QQ邮箱也会是用不了，但是在分布式的情况下，qq和QQ游戏还有QQ邮箱不在一个服务器上，那么qq和QQ邮箱就还可以用。这样有一个坏处，不同服务器，不同的系统用户登陆怎么办（信息孤岛问题）。总不能登陆一遍qq输一遍用户名密码，QQ游戏还有QQ邮箱还得再来一遍。事实是你登陆一遍qq其他的两个只要点击就可以了，所以所有的分布式应用需要一个共同的用户中心用来登陆管理用户相关的信息，qq就是这个用户信息管理中心，只要登陆qq，qq下的邮箱和游戏服务就不用登陆了。有的时候还需要应用的可插拔，比如说秒杀活动功能服务，平常的时候不需要秒杀我就再zookeeper注册服务这里将注册去掉，服务和服务器也可以拿掉了。这就是一个分布式的项目了，这组服务叫高性能集群。
补充1：以上使web应用的容错和健壮性拓展，假如说我的数据库服务器或是缓存redis服务器宕掉怎么办，这时候应用服务器怎么健壮也没有用啊。这时候怎么办，我们可以配置主从，一个不行可以配置多个从数据库以及群的方式进行服务，大部分数据库都可以配置集群，Oracle，MySQL，redis，mongodb等，这是高可用集群。在一些大型的项目当中这几种集群模式往往是混合使用的。