文章目录

平常心博客

平常心的日常积累

标签: 框架分层 (2)

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

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

1、不同的负载场景

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

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

1.1、负载场景一

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

【转载】标准Web系统的架构分层

标准Web系统的架构分层

1、架构体系分层图

e5ed16bc85ac4e9e9f7a5bfc723a4790-20150613151236032.png

在上图中我们描述了Web系统架构中的组成部分。并且给出了每一层常用的技术组件/服务实现。需要注意以下几点:

  • 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用。例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存;一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层。

  • 业务系统间通信层并没有加入传统的HTTP请求方式。这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的通信(这在下面的内容中会详细讲到)。所以,传统的HTTP请求方式并不适合在两个高负载系统之间使用,其更多的应用场景是各种客户端(WEB、IOS、Android等)->服务器端的请求调用。

  • 我们把业务编码中常使用的缓存系统归入到数据存储层,是因为类似于Redis这样的K-V存储系统,从本质上讲是一种键值数据库。为什么Redis会很快以至于可以作为缓存使用,我将在随后的文章中进行详细的描述。

  • 还有一点需要注意的是,上面架构图中的每层之间实际上不存在绝对的联系(例如负载层一定会把请求转送的业务层,这样的必然性是不存在的),在通常情况下各层是可以跨越访问的。举例说明:如果HTTP访问的是一张图片资源,负载层不会把请求送到业务层,而是直接到部署的分布式文件系统上寻找图片资源并返回。再比如运用LVS做Mysql负载时,负载层是直接和数据存储层进行合作。