Github标星6.5K，架构成长之路：大型网站演变中的负载均衡场景

前言

我们小伙伴们是不是经常看到网上一些集群、高可用、高并发、负载均衡等关键词，有很多种方案、以及应用场景中都有相关的介绍。今天老顾就带着大家一起看一下，一整套大型网站会有哪些负载均衡方案场景。

创业阶段

创业初期很多资源的限制，一切以业务为核心，能够正常使用就可以了，因为流量不是很大，所以这个阶段的什么集群、高可用、负载均衡就没有了

这个阶段服务器的不可用，影响不是太大，因为在尝试阶段，都是种子用户进行尝试业务

小型阶段

业务得到市场认可，用户活跃基数慢慢变大，需要考虑****到系统的可用性和负载问题

到这个阶段一般会保证web应用服务的可用性和负载，做Web应用集群。这个利用nginx的负载均衡的功能。保证用户基本服务。这里就第一个负载均衡场景。

web服务的集群化，就会碰到用户session的问题，所以需要添加一台redis服务器做分布式会话。

有些系统的session会话方案，采用本地化方案，利用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基础上设计的）架设网关层。这个是网关层的负载均衡场景