文档章节

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

Gibbons
 Gibbons
发布于 2017/06/01 16:45
字数 3248
阅读 3
收藏 0
点赞 0
评论 0

1、不同的负载场景

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

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

1.1、负载场景一

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

这里写图片描述

1.2、负载场景二

效果不错!在第一版系统架设后的6个月,货场丢货的情况大大减少,并且由于货车在途情况的监控,按时到达率也显著提升,货车司机也反映由于整个货场货车信息都是共享的,货车的待货时间也明显缩短。在这期间物流园中越来越多的货运代理商、货车司机都开始使用这套系统了,整个系统的访问量成线性增长。

物流园的总经理对整个系统的作用感到满意,决定扩大系统的使用范围,并增加新的功能。经过讨论甲方最终决定把整套系统开放给货主:或者可以在系统上查看货运代理商的线路报价、线上通知代理商上门取货、监控目前自己货品的运输状态、了解第三方签收情况。初步估计系统的日RUV将达到10万,日PV将突破50万。

这里写图片描述

1.3、负载场景三

一年后,赞不绝口的大宗货品运输服务质量终于传到了政府领导的耳朵里。省里分管运输的领导亲自领队到物流园区参观考察,最终决定由省政府牵头,各地方政府参与,将这套管理办法在整个省级范围进行推广使用。全省10家大型物流园和50家二级物流园中的上万货运代理商、散落省内的零散代理商、10万个人/企业货主、40万优等资质车源共同接入系统。

新的功能上,增加了费用结算和运费保障功能,从货主预付款开始到第三方确认收货的整个环节都进行费用管理。为了保证线上收货环节的顺利,新版本中还增加了代理商之间的合作收货功能。新系统的日RUV将超过50万,日PV将突破250万。

这里写图片描述

1.4、负载场景四

服务效应、经济效应、口碑效应不断发酵,经过近两年多的发展,目前这套系统已经是省内知名的物流配送平台,专门服务大宗货运物流。联合政府向全国推广服务的时机终于到来。预计全国1000多个物流园区,50万左右物流代理商,500万货运车辆、数不清的个人和企业货主都将使用该系统。预估的RUV和PV是多少呢?无法预估,如果按照全国32省来进行一个简单的乘法,是可以得到一个大概的值(50万 * 32 = 1500万+;500万 * 32 = 1.5亿+,已经超过了JD.com的平峰流量),但是各省的物流业规模是不一样的,从业者数量也不一样,所以这样的预估并不科学。而且再这样的系统规模下我们应该更过的考虑系统的峰值冗余。

业务功能的情况:为了保证注册货车的有效性,您所在的公司被政府允许访问政府的车辆信息库,在车辆注册的过程中进行车辆信息有效性的验证(第三方系统接口调用,我们并不知道第三方系统是否能够接收一个较高水平的并发量,所以这个问题留给我我们的架构师,我们将在业务层讲解时进行详细的描述)。

1.5、沉思片刻

看到这里,我们已经将几个递进的业务场景进行了详细的说明(甚至在后文中我们讨论业务层、业务通信层、数据存储层时所涉及的业务场景也不会有什么大的变化了)。看客们看到这里,可以稍作休息,先想想如果是您,您会如何搭建负载层,甚至整个系统的顶层架构。

由于整个系统的性能除了和硬件有关外,业务层的拆分规则,代码质量,缓存技术的使用方式,数据库的优化水平都可能对其产生影响。所以:

我们在讨论负载层的几篇文章中,我们要假设系统架构中各层的设计都没有对系统性能产生瓶颈

如果您已经思考好了,那么可以继续看以下的内容。

2、负载方案构想

2.1、解决方案一:独立的Nginx/Haproxy方案

很显然,第一个业务场景下,系统并没有多大的压力就是一套简单业务系统,日访问量也完全没有“有访问压力”这样的说法。但是客户有一个要求值得我们关注:要保证系统以后的功能和性能扩展性。为了保证功能和性能扩展性,在系统建立之初就要有一个很好的业务拆分规划,例如我们首先会把用户信息权限子系统和订单系统进行拆分,独立的车辆信息和定位系统可能也需要拆分出来。

这也是我们在系统建立时就要引入负载均衡层的一个重要原因。也是负载均衡层的重要作用之一。如下图所示:

这里写图片描述

可以看出,这时负载均衡层只有一个作用,就是按照设定的访问规则,将访问不同系统的请求转发给对应的系统,并且在出现错误访问的情况下转发到错误提示页面。

2.2、解决方案二:Nginx/Haproxy + Keepalived方案

此后,系统的访问压力进一步加大,系统的稳定性越来越受到我们的关注。所以在单节点处理还能满足业务要求的情况下,我们为负载层(还有各层)引入热备方案,以保证一个节点在崩溃的情况下,另一个节点能够自动接替其工作,为工程师解决问题赢得时间。如下图所示:

这里写图片描述

2.3、解决方案三:LVS(DR)+ Keepalived+ Nginx方案

在第三版本架构方案中,为了保证负载层足够稳定的状态下,适应更大的访问吞吐量还要应付可能的访问洪峰,我们加入了LVS技术。LVS负责第一层负载,然后再将访问请求转发到后端的若干台Nginx上。LVS的DR工作模式,只是将请求转到后端,后端的Nginx服务器必须有一个外网IP,在收到请求并处理完成后,Nginx将直接发送结果到请求方,不会再经LVS回发(具体的LVS工作原理介绍将在后文中详细介绍)。

这里写图片描述

这里要注意的是:

  • 有了上层的LVS的支撑Nginx就不再需要使用Keepalived作为热备方案。因为首先Nginx不再是单个节点进行负载处理,而是一个集群多台Nginx节点;另外LVS对于下后端的服务器自带基于端口的健康检查功能;

  • LVS是单节点处理的,虽然LVS是非常稳定的,但是为了保证LVS更稳定的工作,我们还是需要使用Keepalived为 LVS做一个热备节点,以防不时之需。

2.4、解决方案四:DNS轮询 + LVS(DR)+ Keepalived + Nginx方案

这里写图片描述

场景四中,为了满足平均上亿的日PV访问,在对业务进行外网暴露的基础上,我们在互联网的最前端做了一个DNS轮询。然后将(对用户信息系统)访问压力首先分摊到两个对称LVS组上,再由每个组向下继续分拆访问压力。

注意上图的负载层方案的不同:

  • 首先我们不在像前面的方案中,使用目录名分割业务系统了,而是直接将业务系统的访问使用不同的二级域名进行拆分。这样的变化有利于每个业务系统都拥有自己独立的负载均衡层。

  • 请注意上图中的细节,这个负载均衡层是专门为“用户信息子系统”提供负载均衡支撑的,而可能还存在的“订单子系统”、“车辆信息子系统”都会有他们独立的负载均衡层。

  • 在LVS下方的Nginx服务可以实现无限制的扩展,同样的就像场景三种所给出的解决方案一样,Nginx本身不在需要Keepalived保持热备,而是全部交由上层的LVS进行健康情况检查。而即使有一两台Nginx服务器出现故障,对整个负载集群来说问题也不大。

方案扩展到了这一步,LVS层就没有必要再进行扩展新的节点了。为什么呢?根据您的业务选择的合适的LVS工作模式,两个LVS节点的性能足以支撑地球上的所有核心WEB站点。如果您对LVS的性能有疑惑,请自行谷歌百度。这里我们提供了一份参考资料:《LVS性能,转发数据的理论极限》http://www.zhihu.com/question/21237968

3、为什么没有独立的LVS方案

在下一篇文章《架构设计:负载均衡层设计方案(2)——LVS、keepalived、Nginx安装和核心原理解析》中我们将提到这个问题。实际上通过本篇文章的架构演进分析,一些读者都可以看出端倪。如果用一句话说明其中的原因,那就是LVS为了保证其性能对配置性有所牺牲,单独使用的话往往无法满足业务层对负载层灵活分配请求的要求。

4、说明

4.1、术语说明

  • TPS: 衡量业务层处理性能的重要指标(每秒钟request/事务的处理数量)。业务服务处理一个完整的业务过程,并向上层返回处理结果的过程就是一个 request/事务。那么在一秒钟内整个业务系统能够完成多少个这样的过程,其衡量单位就是TPS。TPS不但和系统架构有很大的关系(特别是业务层和业务通信层的架构祥泰),和物理环境、代码质量的关系也非常密切。

  • PV: 网页浏览数是评价网站流量最常用的指标之一,简称为PV。Page Views中的Page一般是指普通的html网页,也包含PHP、jsp等动态产生的html内容。注意是完整的显示一个Page成为一个PV。但是一个PV,一般需要多次HTTP请求,以便获取多个静态资源,这是需要注意的。

  • UV: Unique Visitor 一个独立IP,在一个单位时间内(例如一日/一小时)对系统的一个PV请求,成为一个UV(重复的PV不在进行计数)。

  • RUV: Repeat User Visitor 一个独立用户,在一个单位时间内(例如一日/一小时)对系统的一个PV请求,并且重复的访问要进行计数。

© 著作权归作者所有

共有 人打赏支持
Gibbons
粉丝 5
博文 47
码字总数 99882
作品 0
成都
程序员
原腾讯云架构师分享可扩展系统的入门基础

肖立鹏原来在腾讯云做架构师,目前在Udesk担任CTO职位。下面是他分享的Udesk在可扩展高并发架构方面的一些实践经验: Udesk,是移动互联时代的企业级客服平台,采用SaaS的方式为企业提供基于...

mmlidong
2015/05/22
90
0
架构设计:系统存储(11)——MySQL主从方案业务连接透明化(上)

1、MySQL主从方案业务层的问题 在之前的文章中,我们提到MySQL一主多从集群模式下,对上层业务系统的访问带来了一些问题。本编文章中我们将深入分析这个问题,并介绍如何对这个问题进行改进。...

yinwenjie
2016/11/04
0
0
架构设计:系统存储(19)——图片服务器:需求和技术选型(1)

1、概述 图片服务系统是各种针对C端系统常见的子系统,它的特点是存储规模大请求频度高,且单张图片的读请求远远高于写请求。后续几篇文章我们将从图片服务系统的需求分析开始,一起来讨论如...

yinwenjie
2017/01/16
0
0
网站的伸缩性架构,负载均衡的实现方式,缓存集群与数据库集群处理

网站的伸缩性架构 指不需要改变网站的硬件设计,仅仅通过部署的服务器数量变更就可以扩大或者缩小网站服务处理能力。 架构的伸缩性 分层(纵向分离) 分割(横向分离) 单一功能通过集群实现...

桃子红了呐
2017/01/29
0
0
19个心得 明明白白说Linux下的负载均衡

19个心得 明明白白说Linux下的负载均衡 http://bbs.uchao.net/thread-32910-1-1.html 一、目前网站架构一般分成负载均衡层、web层和数据库层,我其实一般还会多加一层,即文件服务器层,因为...

浩源社区
2012/03/01
0
0
架构设计:系统间通信(32)——其他消息中间件及场景应用(下2)

(接上文《架构设计:系统间通信(31)——其他消息中间件及场景应用(下1)》) 5-3、解决方案二:改进半侵入式方案 5-3-1、解决方法一的问题所在 方案一并不是最好的半侵入式方案,却容易理...

yinwenjie
2016/05/24
0
0
实现全球同服,保障业务出海——腾讯云跨域加速解决方案

业务出海难在哪? 欢迎大家前往云+社区,获取更多腾讯海量技术实践干货哦~ 作者:方坤丁 传统的出海方案 以游戏业务为例,国内游戏厂商在海外发行游戏时,面临的首要问题即怎样在保障功能的情...

云加社区
01/24
0
0
大型分布式网站架构技术总结

大型分布式网站架构 大型分布式网站架构技术总结 本文是学习大型分布式网站架构的技术总结。对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进行了概要性描述,并给出一个架构参考。一...

陶邦仁
2016/03/15
632
0
大型分布式网站架构技术总结

原文出处: ITFLY8 本文是学习大型分布式网站架构的技术总结。对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进行了概要性描述,并给出一个架构参考。一部分为读书笔记,一部分是个人...

umgsai
2017/09/26
0
0
干货:一种基于SDN的服务器负载均衡方案

网络已经成为许多商业的支撑脊柱,世界网络中每天都有新的设备加入,致使网络规模巨大化。众多的网络设备不仅意味着需要投入更多的资源,且使网络结构越加复杂化,管理难度增大且易错。为了避...

技术小能手
06/08
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

about git flow

  昨天元芳做了git分支管理规范的分享,为了拓展大家关于git分支的认知,这里我特意再分享这两个关于git flow的链接,大家可以看一下。 Git 工作流程 Git分支管理策略   git flow本质上是...

qwfys
今天
2
0
Linux系统日志文件

/var/log/messages linux系统总日志 /etc/logrotate.conf 日志切割配置文件 参考https://my.oschina.net/u/2000675/blog/908189 dmesg命令 dmesg’命令显示linux内核的环形缓冲区信息,我们可...

chencheng-linux
今天
1
0
MacOS下给树莓派安装Raspbian系统

下载镜像 前往 树莓派官网 下载镜像。 点击 最新版Raspbian 下载最新版镜像。 下载后请,通过 访达 双击解压,或通过 unzip 命令解压。 检查下载的文件 ls -lh -rw-r--r-- 1 dingdayu s...

dingdayu
今天
1
0
spring boot使用通用mapper(tk.mapper) ,id自增和回显等问题

最近项目使用到tk.mapper设置id自增,数据库是mysql。在使用通用mapper主键生成过程中有一些问题,在总结一下。 1、UUID生成方式-字符串主键 在主键上增加注解 @Id @GeneratedValue...

北岩
今天
2
0
告警系统邮件引擎、运行告警系统

告警系统邮件引擎 cd mail vim mail.py #!/usr/bin/env python#-*- coding: UTF-8 -*-import os,sysreload(sys)sys.setdefaultencoding('utf8')import getoptimport smtplibfr......

Zhouliang6
今天
1
0
Java工具类—随机数

Java中常用的生成随机数有Math.random()方法及java.util.Random类.但他们生成的随机数都是伪随机的. Math.radom()方法 在jdk1.8的Math类中可以看到,Math.random()方法实际上就是调用Random类...

PrivateO2
今天
3
0
关于java内存模型、并发编程的好文

Java并发编程:volatile关键字解析    volatile这个关键字可能很多朋友都听说过,或许也都用过。在Java 5之前,它是一个备受争议的关键字,因为在程序中使用它往往会导致出人意料的结果。在...

DannyCoder
昨天
1
0
dubbo @Reference retries 重试次数 一个坑

在代码一中设置 成retries=0,也就是调用超时不用重试,结果DEBUG的时候总是重试,不是0吗,0就不用重试啊。为什么还是调用了多次呢? 结果在网上看到 这篇文章才明白 https://www.cnblogs....

奋斗的小牛
昨天
2
0
数据结构与算法3

要抓紧喽~~~~~~~放羊的孩纸回来喽 LowArray类和LowArrayApp类 程序将一个普通的Java数组封装在LowArray类中。类中的数组隐藏了起来,它是私有的,所以只有类自己的方法才能访问他。 LowArray...

沉迷于编程的小菜菜
昨天
1
0
spring boot应用测试框架介绍

一、spring boot应用测试存在的问题 官方提供的测试框架spring-boot-test-starter,虽然提供了很多功能(junit、spring test、assertj、hamcrest、mockito、jsonassert、jsonpath),但是在数...

yangjianzhou
昨天
8
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部