可扩展的Web架构与分布式系统(上)..docxVIP

可扩展的Web架构与分布式系统（译）Jan 16, 2013原文：Scalable Web Architecture and Distributed Systems译者：youngsterxyf开源软件已成为一些最大型网站的基础组件。并且随着那些网站的发展，围绕它们的架构出现了一些最佳实践与指导性原则。本章尝试阐述设计大型网站需要考虑的一些关键问题，以及一些实现这些目标的组件。本章主要侧重于Web系统，虽然其中一些内容也适用于其它分布式系统。Web分布式系统设计原则构建和运维一个可扩展Web站点或者应用到底意味着什么？说到底这种系统只不过是通过互联网将用户与远程资源相连接—使其可扩展的是分布于多个服务器的资源，或者对这些资源的访问。类似于生活中的大多数东西，从长远来说，构建一个web服务之前花些时间提前规划是很有帮助的。理解大型网站背后一些需要考虑的因素与权衡取舍，在创建小一些的web站点时能让你作出更明智的决策。以下是影响大规模web系统设计的一些核心原则：可用性：一个网站的正常运行时间对于许多公司的声誉与运作都是至关重要的。对于一些更大的在线零售站点，几分钟的不可用都会造成数千或数百万美元的营收损失，因此系统设计得能够持续服务，并且能迅速从故障中恢复是技术和业务的最基本要求。分布式系统中的高可用性需要仔细考虑关键部件的冗余，从部分系统故障中迅速恢复，以及问题发生时优雅降级。性能：对于多数站点而言，网站的性能已成为一个重要的考虑因素。网站的速度影响着使用和用户满意度，以及搜索引擎排名，与营收和是否能留住用户直接相关。因此，创建一个针对快速响应与低延迟进行优化的系统非常重要。可靠性：系统必须是可靠的，这样相同数据请求才会始终返回相同的数据。数据变换或更新之后，同样的请求则应该返回新的数据。用户应该知道一点：如果东西写入了系统，或者得到存储，那么它会持久化并且肯定保持不变以便将来进行检索。可扩展性：对于任何大型分布式系统而言，大小(size)只是需要考虑的规模(scale)问题的一个方面。同样重要的是努力去提高处理更大负载的能力，这通常被称为系统的可扩展性。可扩展性以系统的许多不同参数为参考：能够处理多少额外流量？增加存储容量有多容易？能够处理多少更多的事务？可管理性：系统设计得易于运维是另一个重要的考虑因素。系统的可管理性等价于运维（维护和更新）的可扩展性。对于可管理性需要考虑的是：问题发生时易于诊断与理解，便于更新或修改，系统运维起来如何简单（例如：常规运维是否不会引发失败或异常？）成本：成本是一个重要因素。很明显这包括硬件和软件成本，但也要考虑系统部署和维护这一方面。系统构建所花费的开发者时间，系统运行所需要的运维工作量，以及培训工作都应该考虑进去。成本是拥有系统的总成本。这些原则中的每一个都为设计分布式web架构提供了决策依据。然而，它们之间也会相互不一致，这样实现一个目标的代价是牺牲另一个目标。一个基本的例子：简单地通过增加更多的服务器（可扩展性）来解决容量问题是以可管理性（你需要运维额外的一台服务器）和成本（服务器的价钱）为代价的。设计任何一种web应用，考虑这些核心原则都是非常重要的，即使明知某个设计也许会牺牲其中的一个或多个原则。1.2. 基础概念说到系统架构，需要考虑几个事情：什么是合适的部件，这些部件如何组合在一起，以及什么是正确的权衡取舍。在需要之前扩大投资通常不是一种明智的商业主张;然而，在设计上的一些远见在将来能够节省大量的时间和资源。本节主要阐述对于几乎所有大型web应用来说都是非常重要的一些核心因素：服务，冗余，分区，以及故障处理。这些因素中的每一个都涉及选择与折中，特别是在上一节所描述的那些原则的上下文中。为了详细地解释这些东西，最好是从一个例子开始。例子：图片托管应用可能在以前的某个时候，你在网上张贴过图片。对于托管和提供大量图片的大网站来说，构建一个性价比高、高可用、以及低延迟（快速检索）的架构是存在诸多挑战的。想象存在这样一个系统，用户可以上传图片到中央服务器，也可以通过web链接或者API请求图片，就像Flickr或Picasa一样。为了简单起见，我们假设这个应用有两个关键部分：上传（写）图片到服务器和查询图片。当然我们希望图片上传很高效，同时我们非常关注当有人请求一张图片时（例如，网页或者其他应用请求图片），系统能够快速地交付。这非常类似于web服务器或内容分发网络（CDN）边缘服务器（CDN将这种服务器用于在多个地方存储内容，这样内容就在地理/物理距离上更接近用户，从而更加快速）提供的功能。系统的另一些重要方面有：* 对于将要存储的图片数量没有限制，因此需要考虑存储的可扩展性。* 图片下载/请求的延迟要低。* 如果用户上传了某张图片，那么这张图片就得一直存在（图片数据的可靠性）。* 系