文章目录

平常心博客

平常心的日常积累

标签: Haproxy (2)

【转载】架构设计:负载均衡层设计方案(9)——负载均衡层总结下篇

(接上一篇《架构设计:负载均衡层设计方案(8)——负载均衡层总结上篇》)

3、负载均衡层技术汇总

3-4、Keepalived技术

Keepalived在我的博客文章《架构设计:负载均衡层设计方案(7)》(http://blog.v5cn.cn/articles/2017/12/09/1512805702084.html)、《架构设计:负载均衡层设计方案(6)》(http://blog.v5cn.cn/articles/2017/12/07/1512652439344.html)中都有介绍。大家可能注意到,在这些文章中从来没有单独介绍Keepalived。这是因为Keepalived是为了监控集群节点的工作状态,在因为某种原因不能正常提供服务的前提下,完成备机的切换。这里面有两个关键点:监控节点上提供的服务完成网络切换。keepalived本身是不提供业务服务的,只是监控提供的服务是否正常工作,那么既然都没有可以监控的服务,那么Keepalived有什么独立使用的必要呢?

下图是曾经在博文中展现过的Nginx + Keepalived的工作结构和LVS + Keepalived 的工作结构:

【转载】架构设计:负载均衡层设计方案(1)——负载场景和解决方式

在上一篇《标准Web系统的架构分层》文章中,我们概述了WEB系统架构中的分层架设体系,介绍了包括负载均衡层、业务层、业务通信层、数据存储层的作用和存在意义。从本片文章开始,我们将首先详细讲解负载均衡层的架构原理和选型场景。

1、不同的负载场景

我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”,那么不同的业务场景需要的负载均衡方式又是不一样的,架构师还要考虑架构方案的成本、可扩展性、运维难易度等问题。下面我们先介绍几种典型的不同业务场景,大家也可以先想一下如果是您,会怎么架设这些场景的负载均衡层。

需要注意的是,这个系统的文章,我们都将使用这几个典型的业务场景来讲解系统架构的设计递归设计。在后续几篇介绍负载层架构的文章中,我们也将通过这几个典型的业务场景讲解负载层的架构方案。

1.1、负载场景一

这是一个国家级物流园区的货运订单和物流管理系统。在物流园区内的货运代理商、合作司机(货运车辆)、园区管理员和客服人员都要使用这套系统。每日RUV在1万人次,日PV在10万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品是否能起到提高效率的作用”。可以看出整个系统基本上没有访问压力,甲方对您设计的系统只有一个要求:能够保证系统以后的功能和性能扩展性。