可扩展Web架构与分布式系统..doc

开放源代码已经成为一些大型网站的基本原则。而在这些网站成长的过程中，一些优秀的实践经验和规则也出现在他们的结构中。本文旨在介绍一些在大型网站结构设计的过程中需要注意的关键问题以及实现目标的基础工作。 本文侧重于介绍网络系统，尽管一些准则在其他分布式系统中也是适用的。 1.1. web分布式系统的设计原则 搭建和运营一个可伸缩的web站点或者应用程序意味着什么？在原始层面上这仅仅是用户通过互联网连接到远程资源-使系统变得可伸缩的部分是将资源、或者访问的资源，分布于多个服务器上。 像生活中大多数事情一样，当构建一个web服务时花时间提前做好计划从长远看来还是很有帮助的；了解一些注意事项和大网站背后的权衡原则可以在创建小型网站时做出更明智的决定。以下是一些影响大规模web系统设计的关键原则: 可用性:对于很多公司来说一个网站的正常运行时间是非常关键的声誉和功能，像一些大型的在线零售系 统，即使一分钟的宕机都有可能导致数千或者数百万美元的损失，因此设计系统的时时可用性和弹性的错误处理机制既是一个基本业务也是一个技术要求。 高可用分布式系统需要仔细考虑关键组件的冗余，分系统失败后能快速修复，并且当问题出现时优雅型降级。 性能:网站的性能正在变成大多数站点考虑的一个重要的方面，网站的速度影响正常使用和用户的满意度，同样影响搜索的排名，这也是影响网站收益和保留用户的一个因素。因此，创建一个快速响应和低延迟的系统是非常关键的。 可靠性:一个系统需要具备可靠性，比如同一个数据的请求始终返回同样的数据响应 。如果数据改变或者被更新，那么同样的数据将返回一个新的数据。用户需要知道一些东西被写入系统或者被存储到系统后，系统会保持不变并且可以在以后恢复到合适的位置。 可伸缩性:当谈到任何大型的分布式系统时，规模大小只是考虑的其中一个方面，同样重要的是增强处理较大规模的负载性能所做的努力，这通常称为系统的可伸缩性。可伸缩性可以代表系统很多不同的参数：额外流量的处理量，添加存储容量的便意性，甚至事务的处理量。 可管理性:?设计一个系统可以方便操作是另一个重要的考虑方面，系统的可管理性等同于操作的可伸缩性：维护和升级。可管理性需要考虑的事情是当问题发生时方便诊断和了解问题，易于升级和修改，以及系统能简单性的操作（即，例行的操作有没有失败和异常？） 成本:?成本是一个重要的因素。很明显这包含硬件和软件成本，但同样重要需要考虑的其他方面是部署和维护系统的成本。开发者构建系统花费的大量时间，运维部署时间，甚至培训时间都需要考虑，成本是总体成本。 以上每个原则都为设计分布式web架构提供了基础决策。然而，他们也能彼此互斥，例如要实现某个目标就要以另外的作为代价。一个基本的例子：选择通 过单纯增加更多的服务器（可扩展性）来增加地址容量，是以可管理性（你必须操作增加的服务器）和成本（服务器的价格）为代价的。 当设计任何的web应用程序时，考虑这些关键原则都是很重要的，即使得承认一个设计可能要牺牲它们之中的一个或者多个。 1.2. 基础 当设计一个系统架构时，有一些东西是要考虑的：正确的部分是什么，怎样让这些部分很好地融合在一起，以及好的折中方法是什么。通常在系统架构需要之前就为它的可扩展性投资不是一个聪明的商业抉择；然而，在设计上的深谋远虑能在未来节省大量的时间和资源。 这部分关注点是几乎所有大型web应用程序中心的一些核心因素：服务、冗余、划分和错误处理。每一个因素都包含了选择和妥协，特别是上部分提到的设计原则。为了详细的解析这些，最好是用一个例子来开始。 实例：图片托管应用 有时候你可能会在线上传一张图片。对于那些托管并负责分发大量图片的网站来说，要搭建一个既节省成本又高效还能具备较低的延迟性（你能快速的获图片）的网站架构确实是一种挑战。 我们来假设一个系统，用户可以上传他们的图片到中心服务器，这些图片又能够让一些web链接或者API获取这些图片，就如同现在的Flickr或者 Picasa。为了简化的需要，我们假设应用程序分为两个主要的部分：一个是上传图片到服务器的能力（通常说的写操作），另一个是查询一个图片的能力。然 而，我们当然想上传功能很高效，但是我们更关心的是能够快速分发能力，也就是说当某个人请求一个图片的时候（比如，一个web页面或者其它应用程序请求图 片）能够快速的满足。这种分发能力很像web服务器或者CDN连接服务器（CDN服务器一般用来在多个位置存储内容一边这些内容能够从地理位置或者物理上 更靠近访问它的用户，已达到高效访问的目的）气的作用。 系统其他重要方面： 对图片存储的数量没有限制，所以存储需要可扩展，在图像数量方面需要考虑。 图片的下载和请求不需要低延迟。 如果用户上传一个图片，图片应该都在那里（图片数据的可靠性）。 系统应该容易管理（可管理