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

原文: 可扩展Web架构与分布式系统

开放源代码已经成为一些大型网站的基本原则。而在这些网站成长的过程当中，一些优秀的实践经验和规则也出如今他们的结构中。本文旨在介绍一些在大型网站结构设计的过程当中须要注意的关键问题以及实现目标的基础工做。 本文侧重于介绍网络系统，尽管一些准则在其余分布式系统中也是适用的。

1.1. web分布式系统的设计原则 搭建和运营一个可伸缩的web站点或者应用程序意味着什么？在原始层面上这仅仅是用户经过互联网链接到远程资源-使系统变得可伸缩的部分是将资源、或者访问的资源，分布于多个服务器上。 像生活中大多数事情同样，当构建一个web服务时花时间提早作好计划从长远看来仍是颇有帮助的；了解一些注意事项和大网站背后的权衡原则能够在建立小型网站时作出更明智的决定。如下是一些影响大规模web系统设计的关键原则: 可用性:对于不少公司来讲一个网站的正常运行时间是很是关键的声誉和功能，像一些大型的在线零售系统，即 使一分钟的宕机都有可能致使数千或者数百万美圆的损失，所以设计系统的时时可用性和弹性的错误处理机制既是一个基本业务也是一个技术要求。 高可用分布式系统须要仔细考虑关键组件的冗余，分系统失败后能快速修复，而且当问题出现时优雅型降级。 性能:网站的性能正在变成大多数站点考虑的一个重要的方面，网站的速度影响正常使用和用户的满意度，一样影响搜索的排名，这也是影响网站收益和保留用户的一个因素。所以，建立一个快速响应和低延迟的系统是很是关键的。 可靠性:一个系统须要具有可靠性，好比同一个数据的请求始终返回一样的数据响应 。若是数据改变或者被更新，那么一样的数据将返回一个新的数据。用户须要知道一些东西被写入系统或者被存储到系统后，系统会保持不变而且能够在之后恢复到合适的位置。 可伸缩性:当谈到任何大型的分布式系统时，规模大小只是考虑的其中一个方面，一样重要的是加强处理较大规模的负载性能所作的努力，这一般称为系统的可伸缩性。可伸缩性能够表明系统不少不一样的参数：额外流量的处理量，添加存储容量的便意性，甚至事务的处理量。 可管理性: 设计一个系统能够方便操做是另外一个重要的考虑方面，系统的可管理性等同于操做的可伸缩性：维护和升级。可管理性须要考虑的事情是当问题发生时方便诊断和了解问题，易于升级和修改，以及系统能简单性的操做（即，例行的操做有没有失败和异常？） 成本: 成本是一个重要的因素。很明显这包含硬件和软件成本，但一样重要须要考虑的其余方面是部署和维护系统的成本。开发者构建系统花费的大量时间，运维部署时间，甚至培训时间都须要考虑，成本是整体成本。

以上每一个原则都为设计分布式web架构提供了基础决策。然而，他们也能彼此互斥，例如要实现某个目标就要以另外的做为代价。一个基本的例子：选择经过单纯 增长更多的服务器（可扩展性）来增长地址容量，是以可管理性（你必须操做增长的服务器）和成本（服务器的价格）为代价的。 当设计任何的web应用程序时，考虑这些关键原则都是很重要的，即便得认可一个设计可能要牺牲它们之中的一个或者多个。

1.2. 基础 当设计一个系统架构时，有一些东西是要考虑的：正确的部分是什么，怎样让这些部分很好地融合在一块儿，以及好的折中方法是什么。一般在系统架构须要以前就为它的可扩展性投资不是一个聪明的商业抉择；然而，在设计上的深谋远虑能在将来节省大量的时间和资源。 这部分关注点是几乎全部大型web应用程序中心的一些核心因素：服务、冗余、划分和错误处理。每个因素都包含了选择和妥协，特别是上部分提到的设计原则。为了详细的解析这些，最好是用一个例子来开始。

实例：图片托管应用 有时候你可能会在线上传一张图片。对于那些托管并负责分发大量图片的网站来讲，要搭建一个既节省成本又高效还能具有较低的延迟性（你能快速的获图片）的网站架构确实是一种挑战。 咱们来假设一个系统，用户能够上传他们的图片到中心服务器，这些图片又可以让一些web连接或者API获取这些图片，就如同如今的Flickr或者 Picasa。为了简化的须要，咱们假设应用程序分为两个主要的部分：一个是上传图片到服务器的能力（一般说的写操做），另外一个是查询一个图片的能力。然 而，咱们固然想上传功能很高效，可是咱们更关心的是可以快速分发能力，也就是说当某我的请求一个图片的时候（好比，一个web页面或者其它应用程序请求图 片）可以快速的知足。这种分发能力很像web服务器或者CDN链接服务器（CDN服务器通常用来在多个位置存储内容一边这些内容可以从地理位置或者物理上 更靠近访问它的用户，已达到高效访问的目的）气的做用。

系统其余重要方面： 对图片存储的数量没有限制，因此存储须要可扩展，在图像数量方面须要考虑。 图片的下载和请求不须要低延迟。 若是用户上传一个图片，图片应该都在那里（图片数据的可靠性）。 系统应该容易管理（可管理性）。 因为图片主机不会有高利润的空间，因此系统须要具备成本效益。 Figure 1.1是一个简化的功能图。   Figure 1.1: 图片主机应用的简化架构图 在这个图片主机的例子里，可碰见系统必需快速，它的数据存储要可靠以及这些全部的属性都应该高度的可扩展。创建这个应用程序的一个小版本不是很重要并且很 容易部署在单一的服务器上；然而，这不是这节里的感兴趣部分。假设下咱们想建一个会增加到和Flickr痛让规模的东西。

当要考虑设计一个可扩展的系统时，为功能解耦和考虑下系统每部分的服务都定义一个清晰的接口都是颇有帮助的。在实际中，在这种方式下的系统设计被成为面向 服务架构（SOA）。对于这类型的系统，每一个服务有本身独立的方法上下文，以及使用抽象接口与上下文的外部任何东西进行交互，典型的是别的服务的公共 API。 把一个系统解构为一些列互补的服务，可以为这些部分从别的部分的操做解耦。这样的抽象帮助在这些服务服、它的基础环境和服务的消费者之间创建清晰的关系。 创建这种清晰的轮廓能帮助隔离问题，但也容许各模块相对其它部分独立扩展。这类面向服务设计系统是很是相似面向对象设计编程的。

在咱们的例子中，上传和检索图像的请求都是由同一个服务器处理的；然而，由于系统须要具备伸缩性，有理由要将这两个功能分解为各由本身的服务进行处理。 快速转发（Fast-forward）假定服务处于大量使用中；在这种状况下就很容易看到，读取图像所花的时间中有多少是因为受到了写入操做的影响（由于 这两个功能将竞争使用它们共享的资源）。取决于所采用的体系结构，这种影响多是巨大的。即便上传和下载的速度彻底相同（在绝大多数IP网络中都不是这样 的状况，大部分下载速度和上传速度之比都至少设计为3:1），文件读取操做通常都是从高速缓存中进行的，而写操做却不得不进行最终的磁盘操做（并且可能要 写几回才能达成最后的一致状态）。即便全部内容都已在内存中，或者从磁盘（好比SSD磁盘）中进行读取，数据库写入操做几乎每每都要慢于读取操做。 （Pole Position是一个开源的DB基准测试工具，http://polepos.org/，测试结果参见 http://polepos.sourceforge.net/results/PolePositionClientServer.pdf）

这种设计另外一个潜在的问题出在web服务器上，像Apache或者lighttpd一般都有一个可以维持的并发链接数上限（默认状况下在500左右，不过 能够更高）和最高流量数，它们会很快被写操做消耗掉。由于读操做能够异步进行，或者采用其它一些像gizp压缩的性能优化或者块传输编码方式，web服务 器能够经过在多个请求服务之间切换来知足比最大链接数更多的请求（一台Apache的最大链接数设置为500，它每秒钟提供近千次读请求服务也是正常 的）。写操做则不一样，它须要在上传过程当中保持链接，因此大多数家庭网络环境下，上传一个1MB的文件可能须要超过1秒的时间，因此web服务器只能处理 500个这样并发写操做请求。

对于这种瓶颈，一个好的规划案例是将读取和写入图片分离为两个独立的服务，如图Figure 1.2.所示。这让咱们能够单独的扩展其中任意一个（由于有可能咱们读操做比写操做要频繁不少），同时也有助于咱们理清每一个节点在作什么。最后，这也避免了将来的忧虑，这使得故障诊断和查找问题更简单，像慢读问题。

这种方法的优势是咱们可以单独的解决各个模块的问题-咱们不用担忧写入和检索新图片在同一个上下文环境中。这两种服务仍然使用全球资料库的图片，可是它们 可经过适当的服务接口自由优化它们本身的性能（好比，请求队列，或者缓存热点图片-在这之上的优化）。从维护和成本角度来看，每一个服务按需进行独立规模的 规划，这点很是有用，试想若是它们都组合混杂在一块儿，其中一个无心间影响到了性能，另外的也会受影响。