前言
我们小伙伴们是不是经常看到网上一些集群、高可用、高并发、负载均衡等关键词，有很多种方案、以及应用场景中都有相关的介绍。今天老顾就带着大家一起看一下，一整套大型网站会有哪些负载均衡方案场景。
创业阶段
创业初期很多资源的限制，一切以业务为核心，能够正常使用就可以了，因为流量不是很大，所以这个阶段的什么集群、高可用、负载均衡就没有了
这个阶段服务器的不可用，影响不是太大，因为在尝试阶段，都是种子用户进行尝试业务
小型阶段
业务得到市场认可，用户活跃基数慢慢变大，需要考虑到系统的可用性和负载问题
到这个阶段一般会保证web应用服务的可用性和负载，做Web应用集群。这个利用nginx的负载均衡的功能。保证用户基本服务。这里就第一个负载均衡场景。
web服务的集群化，就会碰到用户session的问题，所以需要添加一台redis服务器做分布式会话。
利用jwt+token的方式，他们会不需要redis服务器保存session会话。
也有用 jwt 和redis会话服务器相结合的方案，这样可以解决jwt的缺点问题。这里老顾就不多讲了。
中型阶段
这个阶段是业务发展最快的阶段，业务的多变性，以及用户流量已经到了一定的规模，要考虑系统的可用性了，数据量也有一定的规模。这时是系统进入促步改造的时期。
业务微服务化
为了保证业务的多变，我们需要把各自业务进行解耦，这边需要的技术Dubbo或Spring Cloud微服务框架。这两个框架都支持微服务集群部署，以及调用方的负载均衡。如下图的订单微服务会部署几个订单微服务，形成集群，web服务调用方会做负载均衡的调用。这边就涉及到了第二个负载均衡的场景，是利用微服务框架自身的功能。
分布式缓存
活跃用户的增大，会对DB数据库的访问压力过大，这个时候会考虑增加缓存层来帮助DB减压。在进行分布式缓存进行规划时，会用到redis集群作为缓存。redis集群方案中利用哈希槽的方式，达到了缓存数据量的拆分，以及负载均衡。这个就是第三个负载均衡场景
nginx集群
用户并发到了几千的时候，就要考虑到nginx的高可用，虽然nginx的性能比较高，但也经不起量大啊。利用LVS来实现nginx的高可用和负载均衡，这个又是一个负载均衡场景
大型阶段
此阶段的业务已经趋于稳定，数据量也越有越大，用户活跃也很大；业务复杂度很高，已经业务流程多变，市场规模发展到全国，有多机房多区域的部署的需求。公司规模大了以后，网络安全就显得尤为重要。系统一定要保证稳定
分库分表
数据库单表如果超过300多万条记录时，就要考虑到分表；数据库的IO操作已经一直处于高负荷状态，就可以考虑把业务进行拆分到不同的DB中，以及数据库的主从设计实现读写分离，设计来降低DB负载和高可用。
分库分表中可以采用两种方案，一种代理层方案，如：MyCat框架；一种是客户端实现，如sharding-jdbc。这个又是一种在数据库层的负载均衡场景
消息中间件
业务的复杂度高，需要很好的拆分业务，更进一步的业务解耦，以及高并发下限流会用到消息中间件，如：RocketMQ，RabbitMQ。
还有分布式事务中，为了保证最终一致性，也会用到消息中间件。
消息中间件是天生的集群化，保证消息中间件的高可用以及负载均衡，有这个是消息队列层的负载均衡场景。
网关
在分布式架构下，为了进行统一的路由，鉴权，限流，监控等；这个时候就要上网关，现在网关框架为：Kong，Zuul，GateWay，Soul等，这些框架也是集群化的。部署到nginx层下面（kong可以直接替换nginx，因为就是在nginx基础上设计的）架设网关层。这个是网关层的负载均衡场景
跨机房
业务时全国市场，甚至全球市场的话，因为地区网络节点是按照地区架设的，所以要保证多地区能够快速访问我们的网站，这个时候就需要做多机房的设计。多机房的设计就是利用了DNS，这个就是DNS层的负载均衡
到达这一步的话，一般在同一机房下，会部署几套系统集群方案，这个时候一般在机房里面会加入硬件负载均衡器，如：F5，A10；硬件负载均衡器是蛮贵的，不过公司已经发展到这个地步了，应该有钱了。
涉及到跨机房，系统设计的时候就会非常复杂，尤其要考虑到机房间数据如何共享，同步？这些点老顾在以后的文章中会介绍，跨机房要解决什么问题？
总结
有个共同点就是大型系统不允许有单点故障，就需要集群化，一旦有集群化的地方，肯定会有负载均衡的场景应用。
大型系统的发展，是根据业务发展而来的，在业务没有达到一定的程度时，要选择合适的系统设计，不能超前选择很复杂的方案，会导致开发周期会很长，系统也会变的复杂，没有必要，这一点是技术老大需要重视的。