英文源地址
开源软件已经成为构建一些超大型网站的基础组成部分了.随着这些网站的成长, 围绕着它们软件架构的最佳实践与指导思想开始涌现.本文尝试去阐述设计大型网站时的需要考虑一些关键问题, 以及用于实现这些目标的基础组件.
本文主要关注web系统,尽管其中一些内容也适用于其他的分布式系统.
1.1 Web分布式系统的设计原则
构建并管理一个可伸缩的web网站或应用, 究竟意味着什么?从最基本的角度上讲,它只是通过Internet连接了用户与远程服务器资源, 使其具有可伸缩性的是在多台服务器上分布访问着的资源.
和生活中大多数事物类似, 在构建web服务时, 花一些时间提前规划从长远来看是有帮助的; 理解大型网站设计背后的一些考虑因素和权衡利弊, 可以促使构建规模较小的网站时做出更明智的决策.下面列出了一些主导大型可伸缩web系统设计的核心原则:
- 可用性: 网站的正常运行时间对许多公司的声誉与功能至关重要.对于一些规模较大的在线零售网站, 即使是几分钟的无法访问服务也可能导致数千甚至数百万美元的收入损失, 因此,他们在设计系统时, 使其能够持续可用, 并能从宕机中恢复, 无论从商业上看还是从技术上看都是一个最基本的要求.分布式系统中的高可用性需要仔细考虑对于关键组件的冗余设计,部分系统故障时的快速恢复以及出现问题时的适当降级.
- 性能: 网站性能已成为大多数网站的重要考虑因素.网站的速度影响使用率和用户满意度, 以及搜索引擎排名, 这个因素直接关系到收入(revenue)与留存(retention).因此, 构建一个可以快速响应请求和低延迟的系统是关键.
- 可伸缩性: 当涉及到任何大型分布式系统时, 规模只是需要考虑的方面之一.同样重要的是当需要处理增加的大量负载时, 系统所需的额外容量(通常称为系统的可伸缩性).可伸缩性可以体现为系统的几个参数: 它能处理多少额外流量, 它增加存储容量有多便捷, 甚至于还能处理多少事务.
- 可管理性: 设计的系统易于操作管理是另一个重要的考虑因素.系统的可管理性等同于操作的可伸缩性: 维护和更新.客观理性需要考虑的事情包括:当问题发生时, 易于诊断和理解问题, 易于更新或修改, 以及系统的操作有多简单(例如,它是否经常保持运转而不会受故障或意外的影响?)
- 成本: 成本是一个重要因素.这显然包括硬件和软件成本, 但是考虑部署和维护系统所需的其他方面方面也很重要.系统构建所需的开发人员时间, 运行系统所需的操作工作量, 甚至所需的培训量都应该考虑在内.成本是拥有者的总成本.
这些原则中的每一条都为设计分布式web架构的决策提供了理论基础.然而, 它们也可能彼此冲突, 以至于实现一个目标是以牺牲另一个目标为代价的. 一个基本的例子: 选择通过简单地添加更多的服务器(可伸缩性)来解决容量问题, 可能会以可管理性(你必须操作一个额外的服务器)和成本(服务器的价格)为代价.
在设计任何类型的web应用时, 考虑这些原则都很重要, 即使在知道这样的设计可能会牺牲其中一个或多个原则的情况下.
1.2 基础
当涉及系统架构时, 需要考虑一些事情: 什么是正确的部分, 这些部分如何组合在一起, 以及什么是正确的权衡.
在需要扩展之前进行扩展通常不是一个明智的商业选择.然而, 对设计进行一些预先考虑可以在未来节省大量的时间和资源.
本节将重点讨论几乎所有大型web应用的核心因素: 服务, 冗余, 分区和故障处理.这些因素中的每一个都涉及选择和妥协, 特别是在上一节所述原则的背景下.为了详细解释这些, 最好从一个例子开始.
示例: 图像托管应用
某些时候, 可能在网上发布了一张图片.对于承载和提供大量照片的大型站点来说, 构建一个具有成本效益, 高可用和低延迟的体系结构是一个挑战.
想象一下,在一个系统中, 用户将他们的照片上传到中央服务器, 而这些照片可以通过网页链接或api进行访问, 就像Fickr或Picasa那样.为了简单起见, 我们假设这个应用有两个关键部分: 向服务器上传(写入)图像的能力, 以及查询图像的能力.有人需要下载存储内容时,需要足够快.
这与cdn网络很像
这样的制度的几个重要方面
- 存储的图像没有限制, 因此要考虑图像数量方面的存储可伸缩性
- 图像下载需要低延迟
- 如果用户上传图像, 图像应该始终在那里(数据可靠性)
- 系统应该易于维护(可管理性)
- 由于图像托管没有很高的利润率, 系统需要具有成本效益.
全局缓存的两种方式
分布式缓存
每个节点都拥有缓存数据的一部分.通常, 缓存使用一致性哈希进行划分, 如果一个请求节点正在查找某段数据, 就可以快速知道在分布式缓存的哪里去查找, 以确保该数据是否可用.
这这种情况下, 每个节点都有一小节缓存, 然后在转到原始数据之前将向另一个节点发送数据请求.
因此分布式缓存的优点之一时增加了缓存空间.
