Web 站点的水平扩展和垂直扩展 (译文)

当一个开发人员提升计算机系统负荷时,通常会考虑两种方式垂直扩展和水平扩展。选 用哪种策略主要依赖于要解决的问题以及系统资源的限制。在这篇文章中我们将讲述这两种策略并讨论每种策越的优缺点。如果你已经有一个软件系统需要不断成 长,那么你将有意或者无意中选择这两种策略中的一种。

垂直扩展

在垂直扩展模型中,想要增加系统负荷就意味着要在系统现有的部件上下工夫,即通过提高系统部件的能力来实现。例如,假设你现在负责一批木材采伐的操作。

在这个例子中,我们假设有3辆卡车,每辆车一次可以运25根木材,计算花费1小时的情况下可以运送到指定地点等待处理的木材数量。通过这些数字我们可以算出我们系统最大的负荷量:

3辆卡车 * 25根木材 * 1小时=75根木材/小时

如果我们选择垂直扩展模型,那么我们将怎么做来使我们每小时可以处理150根木材?我们需要至少做以下两件事中的一件:

使每辆卡车的运输量增加一倍(50棵树每小时),或者使每辆卡车的运输时间减半(每辆卡车30分钟)。

3辆卡车 * 50棵树 * 1小时 = 150棵树/每小时

或者

3辆卡车 * 25棵树 * 30分钟 = 150棵树/每小时

我们没有增加系统的成员数,但是我们通过增加系统成员的生产效率来获得期望的负荷量。

水平扩展

在水平扩展模型中,我们不是通过增加单个系统成员的负荷而是简单的通过增加更多的系统成员来实现。也就是说,在以上运送木材的例子中,通过增加卡车的数量来运送木材。因此,当我们需要将负荷从75棵树每小时增加到150棵树每小时,那么只需要增加3辆卡车。

6辆卡车 * 25棵树 * 1小时 = 150棵树/每小时

假如我们已经选择了垂直扩展方式,那么我们想要每小时处理150棵被砍伐的树时需要怎么做呢?我们需要做到以下两方面之一:要么使每辆卡车的运输量翻倍(50棵木材一次),要么使每辆开车的运输时间减半(30分钟)。

3辆卡车 * 50棵树 * 1小时 = 150棵树/每小时

或者

3辆卡车 * 50棵树 * 30分钟 = 150棵树/每小时

在这个例子中,系统每个成员的生产力依然没变,我们通过增加更多的卡车来提高系统的能力。

扩展你的web数据库

通过对水平扩展和垂直扩展的基本了解,下面让我们来关注web系统的扩展。一个网站通常有很多组件都需要去考虑它们的扩展性,但是我通常喜欢关注处在最边缘的一个:数据库。为什么数据库是最边缘的?因为数据库通常是共享资源,是几乎所有请求最终的连接点。

你的系统是什么类型的?

在扩展你的数据库时,你必须要问的一个重要问题是:“我所面对的系统是什么类型的?”你所面对的是一个读操作多还是写操作多的系统?读操作多的网站 一般包括:在线商城,在商城里用户大部时间是在浏览(读操作),只有少数时间在付款(写操作)、或者博客,在博客上人们大部分时间是在浏览博文(读操 作),只有少数时间是在评论或者发表博文(写操作)。相反的,关于写操作非常多的很好的例子包括:信用卡交易处理器,这个系统的主要负载时在处理记录交易 (写操作),偶尔会查找交易(读操作)、或者Google分析,主要工作实在记录业务数据(写操作),偶尔会展示分析图(读操作)。

了解你所创建的网站是什么类型的,可以在网站成长过程中帮助你选择正确的技术。

读操作扩展

如果你的系统读操作非常多,那么通过关系型数据库如mysql或者PostgreSql来垂直扩展数据存储是一个不错的选择。结合你的关系型数据库 通过使用memcached或者CDN来构建一个健壮的缓存系统,那么你的系统将非常容易扩展。在这种模式中,如果数据库超负荷运行,那么将更多的数据放 入缓存中来缓解系统的读压力。当没有更多的数据往缓存中放时,可以更换更快的数据存储硬件或者买更多核的处理器来获取更多的运行通道。摩尔定律使通过这种 方法来垂直扩展变得和购买更好的硬件一样简单。

写操作扩展

如果你的系统写操作非常多,那么你可能更希望考虑使用可水平扩展的数据存储方式,比如Riak,Cassandra或者HBase。和大多数关系型 数据管理系统不同,这种数据存储随着增长增加更多的节点。由于你的系统大部分时间是在写入,所以缓存曾并不能像在读操作比较频繁的系统中起到那么大作用。 很多写频繁的系统一开始使用垂直扩展的方式,但是很快发现并不能根本解决问题。为什么?因为硬盘数和处理器数在某一点达到平衡,在这个边界上再增加一个处 理器或者一个硬盘都会是每秒钟的I/O操作数成指数性增长。相反,如果对写频繁的系统采取水平扩展策略,那么你将达到一个拐点,在这个拐点之后如果在增加 一个节点都远比使用更多的硬盘来的实惠。

其他注意事项

另一件事需要记住的是每种扩展策略下预想不到的开销。采用垂直扩展的系统将开销凡在单独的组件上。当我们去提升系统负荷时,这些单独的组件需要在管 理上花费更多。拿我们运送木材的例子来说,如果需要使每辆卡车的货运量翻倍,那么我们需要更宽、更长、或者更高的车厢。也许有的路因为桥的高度对车辆高度 有要求,或者基于巷子宽度车宽不能太大,又或者由于机动车安全驾驶要求车厢不能太长。这里的限制就是对单个卡车做垂直扩展做的什么程度。同样的概念延伸到 服务器垂直扩展:更多的处理器要求更多的空间,进而要求更多的服务器存储架。

相反的,采用水平扩展的系统将额外的开销放在系统中连接起来的共享组件上。当我们去提升系统负荷时,共享的开销和新增加的成员之间的协调性有关。在 我们运送木材的例子中,当我们在路上增加更多卡车时,那么路就是共享资源也就成了约束条件。这条路上适合同时跑多少量卡车?我们是否有足够的安全缓冲区使 得所有的车可以同时装运木材?如果再来看我们水平扩展的数据库系统,那么经常被忽略的开销就是服务器同时连接时的网络开销(译者注:网络为各个系统的共享 资源)。当你为系统增加更多的节点时,共享资源的负荷也就越来越重,通常呈非线性改变。

综合说明

和计算机的大多数东西一样,好的解决办法通常并不像我这里列出来的这么简单。而我在这里尝试简化这种思想用来来说明这中概念而不是讲具体的解决办 法。扩展是个困难的问题,这是个需要在实际处理的每个步骤中都要思考的问题。扩展策略没有魔法,也没有魔法般的软件帮你建立一个完整可靠的可扩展系统。就 像扩展中的其他问题一样,一个大的解决方案通常是由很多个一起协调工作的小的解决办法组成的。这需对每一个中解决方案进行精心正确的设计和开发。

1. 本文由程序员学架构翻译,mathew校审

2. 本文译自http://blakesmith.me/2012/12/08/understanding-horizontal-and-vertical-scaling.html

时间: 2024-11-05 21:33:41

Web 站点的水平扩展和垂直扩展 (译文)的相关文章

数据库的水平扩展与垂直扩展

数据库水平扩展与垂直扩展 在互联网应用中,数据库经常是我们存储和访问数据的常用介质.随着负载的增大,对数据库读写性能的要求往往成为很大的挑战.在这种情况下我们可以考虑数据库相关的replication机制提高读写的性能.由于一般采用一写多读的replication机制(写master同步到多个slaves),导致这样的机制往往会有缺陷.首先它依赖于读写的比例,如果写的操作过多,导致master往往成为性能的瓶颈所在,从而使得slaves的数据同步延迟也变大,进而大大消耗CPU的资源,并且导致数据

【读书笔记】2016.12.10 《构建高性能Web站点》

本文地址 分享提纲: 1. 概述 2. 知识点 3. 待整理点 4. 参考文档 1. 概述 1.1)[该书信息] <构建高性能Web站点>: -- 百度百科 -- 本书目录: 第1章 绪论 1.1 等待的真相 1.2 瓶颈在哪里 1.3 增加带宽 1.4 减少网页中的HTTP请求 1.5 加快服务器脚本计算速度 1.6 使用动态内容缓存 1.7 使用数据缓存 1.8 将动态内容静态化 1.9 更换Web服务器软件 1.10 页面组件分离 1.11 合理部署服务器 1.12 使用负载均衡 1.1

如何构建日均千万PV Web站点 (三) Sharding

     其实国内许多大型网站为了应对日益复杂的业务场景,通过使用分而治之的手段将整个网站业务分成不同的产品线,比如说国内那些大型购物交易网站它们都将自己的网站首页.商铺.订单.买家.卖家等拆分不同的产品线,分归不同的业务团队负责: 集体到技术,也会根据产品线划分,将一个网站拆分成许多不同的应用,每个应用用独立部署维护.应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发,当然最多的还是通过访问同一个数据库存储系统来构成一个关联的完整系

构建高性能Web站点(修订版)笔记

构建高性能Web站点(修订版)2012.6 p14 '反馈机制':逐包确认 --> 小batch连续发送 一定需要全局编址吗?(可以使用邻居路由+端到端IBE) 电磁波速度:铜线中电信号2.3*10^8,光纤约2*10^8(全反射增加了传输距离) 系统负载:/proc/loadavg 上下文切换:Nmon IOWait(注意一点:磁盘IO是串行的!) 减少系统调用... ZeroCopy?AIO? strace:每次请求都要检测.htaccess?(哦,设置了AllowOverride all)

[转]图文并茂,一步步带你了解Web站点架构

1.1 http反向代理服务器 在web站点前端,我们需要搭建一个反向代理服务器,用于负责接受用户的请求,请求包括动态和静态的内容请求.一般反向代理服务器的部署方案有HAProxy和Nginx,这里将使用HAProxy来描述. 1.2 http代理服务器高可用 为了提高系统安全及高可用性,我们需要在前端的http反向代理服务器配置高可用,解决方案有HAProxy+Keepalived. 1.3 http代理服务器负载均衡 虽 然我们有两个节点的HAProxy,但是一般只有有一台HAProxy可为

如何构建日均千万PV Web站点(二) 之~缓存为王~

随着网站业务的不断发展,用户的规模越来越大:介于中国无比蹩脚复杂的网路环境:南电信:北联通:中间竟然只用一条链路进行互联通信!有研究表明,网站访问延迟和用户流失率正相关,网站访问速度越慢,用户越容易失去耐心而离开.为了提高更好的用户体验,留住用户,网站需要加速网站访问速度.如今主要的手段只有使用CDN和反向代理了:此时网站的架构应该是这样的: 1.使用CDN和缓存服务器:CDN和反向代理的基本原理都是缓存数据,区别就在于CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网

《构建高性能 Web站点》笔记

书名:构建高性能Web站点 出版社: 电子工业出版社 ISBN:9787121170935 一  绪论 等待的时间: (1) 数据在网络上的传输时间 (2) 站点服务器处理请求并生成回应数据的时间 (3) 浏览器本地计算和渲染的时间 二  数据的网络传输 数据如何发送 (1) 应用程序通过系统函数库接口(如send)向内核发出系统调用 (2) 系统内核将数据从用户态内存区复制到由内核维护的内核缓冲区(这块地址空间的大小有限,需要发送的数据以队列的形式进入) (3) 内核通知网卡来取数据,网卡将数

使用公网IP的非80端口访问内网中SharePoint2013的Web站点

大家都知道sharepoint2013默认安装使用的80端口,http可以正常访问,但是如果你想做NAT到公网让其他城市的人通过公网IP访问你的网站,你该怎么做?不巧的是你用的是中国电信的宽带,默认的80端口给封杀了,你还能解决这个问题吗? 答案是:Yes 1.sharepoint扩展,具体是Externed web: 2.在防火墙中做NAT:例如公网IP是180.60.10.10,使用82端口,映射到内网192.168.11.201的80端口,如何做NAT可参考:http://daixuan.

提高 Web 站点性能的最佳实践

本文内容 提高 Web 站点性能的最佳实践 最大限度减少 HTTP 请求 使用内容分发网络(CDN) 添加 Expires 或 Cache – Control 头 Gzip 组件 CSS 放在页面顶部 JavaScript 放在页面底部 避免 CSS 表达式 使用外部 JavaScript 和 CSS 减少 DNS 查询 精简 JavaScript 和 CSS 避免重定向 删除重复的脚本 配置 ETags 使得 Ajax 可缓存 尽早强制地发送缓冲给客户端 用 GET 发送 Ajax 请求 延迟