大型网站演变中的负载均衡场景

有些系统的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。

还有分布式事务中，为了保证最终一致性，也会用到消息中间件。

消息中间件是天生的集群化，保证消息中间件的高可用以及负载均衡，有这个是消息队列层的负载均衡场景。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gq9gZHRL-1651825998233)(https://upload-images.jianshu.io/upload_images/15590149-a5225c2fdc0e8c5d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

网关

在分布式架构下，为了进行统一的路由，鉴权，限流，监控等；这个时候就要上网关，现在网关框架为：Kong，Zuul，GateWay，Soul等，这些框架也是集群化的。部署到nginx层下面（kong可以直接替换nginx，因为就是在nginx基础上设计的）架设网关层。这个是网关层的负载均衡场景

跨机房

业务时全国市场，甚至全球市场的话，因为地区网络节点是按照地区架设的，所以要保证多地区能够快速访问我们的网站，这个时候就需要做多机房的设计。多机房的设计就是利用了DNS，这个就是DNS层的负载均衡

到达这一步的话，一般在同一机房下，会部署几套系统集群方案，这个时候一般在机房里面会加入硬件负载均衡器，如：F5，A10；硬件负载均衡器是蛮贵的，不过公司已经发展到这个地步了，应该有钱了。
器**，如：F5，A10；硬件负载均衡器是蛮贵的，不过公司已经发展到这个地步了，应该有钱了。