中文版参考了这里的翻译：http://www.oschina.net/translate/scalable-web-architecture-and-distributed-systems
开源软件已成为一些超大型 站的基础组件。并且随着那些 站的发展，围绕它们的架构出现了一些最佳实践与指导性原则。本章尝试阐述设计大型 站需要考虑的一些关键问题，以及一些实现这些目标的组件。
本章主要侧重于Web系统，虽然其中一些内容也适用于其它分布式系统。
1.1 Web分布式系统设计原则
构建和运维一个可扩展Web站点或者应用到底意味着什么底这种系统只不过是通过互联 将用户与远程资源相连接—使其可扩展的是分布于多个服务器的资源，或者对这些资源的访问。
类似于生活中的大多数东西，从长远来说，构建一个web服务之前花些时间提前规划是很有帮助的。理解大型 站背后一些需要考虑的因素与权衡取舍，在创建小一些的web站点时能让你作出更明智的决策。以下是影响大规模web系统设计的一些核心原则：
* 可用性： 一个 站的正常运行时间对于许多公司的声誉与运作都是至关重要的。对于一些更大的在线零售站点，几分钟的不可用都会造成数千或数百万美元的营收损失，因此系统设计得能够持续服务，并且能迅速从故障中恢复是技术和业务的最基本要求。分布式系统中的高可用性需要仔细考虑关键部件的冗余，从部分系统故障中迅速恢复，以及问题发生时优雅降级。
* 性能： 对于多数站点而言， 站的性能已成为一个重要的考虑因素。 站的速度影响着使用和用户满意度，以及搜索引擎排名，与营收和是否能留住用户直接相关。因此，创建一个针对快速响应与低延迟进行优化的系统非常重要。
* 可靠性： 系统必须是可靠的，这样相同数据请求才会始终返回相同的数据。数据变换或更新之后，同样的请求则应该返回新的数据。用户应该知道一点：如果东西写入了系统，或者得到存储，那么它会持久化并且肯定保持不变以便将来进行检索。
* 可扩展性： 对于任何大型分布式系统而言，大小(size)只是需要考虑的规模(scale)问题的一个方面。同样重要的是努力去提高处理更大负载的能力，这通常被称为系统的可扩展性。可扩展性以系统的许多不同参数为参考：能够处理多少额外流量存储容量有多容易处理多少更多的事务r> * 可管理性：系统设计得易于运维是另一个重要的考虑因素。系统的可管理性等价于运维（维护和更新）的可扩展性。对于可管理性需要考虑的是：问题发生时易于诊断与理解，便于更新或修改，系统运维起来如何简单（例如：常规运维是否不会引发失败或异常br> * 成本： 成本是一个重要因素。很明显这包括硬件和软件成本，但也要考虑系统部署和维护这一方面。系统构建所花费的开发者时间，系统运行所需要的运维工作量，以及培训工作都应该考虑进去。成本是拥有系统的总成本。
这些原则中的每一个都为设计分布式web架构提供了决策依据。然而，它们之间也会相互不一致，这样实现一个目标的代价是牺牲另一个目标。一个基本的例子：简单地通过增加更多的服务器（可扩展性）来解决容量问题是以可管理性（你需要运维额外的一台服务器）和成本（服务器的价钱）为代价的。
设计任何一种web应用，考虑这些核心原则都是非常重要的，即使明知某个设计也许会牺牲其中的一个或多个原则。
1.2 基础概念
说到系统架构，需要考虑几个事情：什么是合适的部件，这些部件如何组合在一起，以及什么是正确的权衡取舍。在需要之前扩大投资通常不是一种明智的商业主张。然而，在设计上的一些远见在将来能够节省大量的时间和资源。
本节主要阐述对于几乎所有大型web应用来说都是非常重要的一些核心因素：服务，冗余，分区，以及故障处理。这些因素中的每一个都涉及选择与折中，特别是在上一节所描述的那些原则的上下文中。为了详细地解释这些东西，最好是从一个例子开始。
例子：图片托管应用
可能在以前的某个时候，你在 上张贴过图片。对于托管和提供大量图片的大 站来说，构建一个性价比高、高可用、以及低延迟（快速检索）的架构是存在诸多挑战的。
想象存在这样一个系统，用户可以上传图片到中央服务器，也可以通过web链接或者API请求图片，就像Flickr或Picasa一样。为了简单起见，我们假设这个应用有两个关键部分：上传（写）图片到服务器和查询图片。当然我们希望图片上传很高效，同时我们非常关注当有人请求一张图片时（例如， 页或者其他应用请求图片），系统能够快速地交付。这非常类似于web服务器或内容分发 络（CDN）边缘服务器（CDN将这种服务器用于在多个地方存储内容，这样内容就在地理/物理距离上更接近用户，从而更加快速）提供的功能。
系统的另一些重要方面有：
* 对于将要存储的图片数量没有限制，因此需要考虑存储的可扩展性。
* 图片下载/请求的延迟要低。
* 如果用户上传了某张图片，那么这张图片就得一直存在（图片数据的可靠性）。
* 系统应该易于维护（可管理性）。
* 由于图片托管的利润空间不大，所以系统应有较高的性价比。
图1.1是系统的一张功能简化图。
图1.2：切分读写操作
为这类瓶颈做规划是将图片的读写操作切分成独立服务的一个很好的案例。如图1.2所示。这就允许我们单独地对两者中任意一个做扩展（因为通常读操作总是比写操作多），也有助于理清每个点上正在发生的事情。最后，这也分离了未来的忧患，从而更易于排解故障和对读操作较慢这类问题进行扩展。
这种方法的优势在于我们能够将问题独立于其他问题地进行解决—我们无需担心相同上下文中新图片的写操作和检索。这两个服务仍然基于全局图片语料，但可以通过与服务相适应的方法（例如：排队请求，或缓存常用图片—更多相关内容见下文）随意地优化它们的性能。从维护与成本的角度来看，每个服务都可以按需独立地扩展，这一点非常重要，因为如果服务是掺杂混合的，在上述场景中，一个服务会无意地影响另一个服务的性能。
当然，若你有两个不同的端点，那么上述例子能够工作得很好（事实上这非常类似于多个云存储提供商的实现和内容分发 络）。虽然有很多方法可以解决这类瓶颈，但每个都有不同的权衡折中。
例如，Flickr通过将用户分散到不同的数据库分片上来解决这个读/写问题，这样每个数据库分片仅能够处理一定数量的用户，并且随着用户的增加，可以添加更多的数据库分片到服务器集群中（见关于Flickr扩展工作的演示文稿：http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html（注意在墙外））。在第一个例子中，基于实际使用请求，扩展硬件更容易，Flickr则是随着用户群的变化进行扩展（但要求假设在用户之间的使用情况均衡，从而可以添加额外的容量）。对于前者，如果一个服务存在故障或问题，就会削弱整个系统的功能（例如，没人可以写文件），但若Flickr的一个数据库分片存在故障则仅影响使用该分片的用户。第一个例子中，对整个数据集执行操作更方便。例如，更新写操作服务以包含新的元数据或在所有图片元数据上搜索。对于Flickr的架构，需要更新或搜索每个数据库分片（或者需要创建一个搜索服务来整理元数据—事实上它们也这么做了）。
对于这些系统的讨论并没有正确的答案，但回归到本章开头叙述的原则，确定系统的需求（频繁读或写或两者皆如此，并发级别，查询整个数据集，范围，排序，等等），基准测试不同的方案选择，理解系统如何会失效，以及准备一个可靠的计划以应对故障的发生是很有用的。
冗余（Redundancy）
为了优雅地处理故障，web架构必须具备冗余的服务和数据。例如，若某文件仅有一个拷贝存储在单个服务器上，那么失去该服务器即意味着失去了该文件。丢失数据很少是件好事，处理该问题的常见方法是创建多个或者说冗余的数据拷贝。
同样的原则也可应用于服务。如果应用程序的功能有个核心组件，那么确保同时运行多个拷贝或版本能够使系统免于单点故障。
在系统中创建冗余能够消除可能发生故障的单点，为了灾难恢复提供备份或备用的功能。例如，如果生产中运行着两个相同服务的实例，当其中一个发生故障或功能退化时，系统能够失效转移到健全副本。失效备援可以自动发生或者手动介入。
服务冗余的另一关键部分是创建一个无共享(shared-nothing)的架构。使用这种架构，每个节点的运维工作都能独立于其它节点，也没有中心“大脑”来管理状态或协调节点的行为。这有助于提高可扩展性，因为不需要特殊的条件或了解就能添加新的节点。然而，最重要的是这种系统不会有单点故障，因此对于故障更有弹性。
例如，在我们的图片服务器应用中，所有的图片都在另一处（理想情况是在不同的地理位置，从而能够应对地震或数据中心发生火灾一类的灾难）的硬件上存放着冗余的拷贝，提供图片访问的服务也是冗余的，均潜在地服务于请求（见图1.3）（负载均衡器是使其成为可能的一种绝佳方法，将在下文详述）。
图1.4：使用冗余和分区实现的图片存储服务
当然，为多个服务器分配数据或功能是充满挑战的。一个关键的问题就是数据局部性；对于分布式系统，计算或操作的数据越相近，系统的性能越佳。因此，一个潜在的问题就是数据的存放遍布多个服务器，当需要一个数据时，它们并不在一起，迫使服务器不得不为从 络中获取数据而付出昂贵的性能代价。
另一个潜在的问题是不一致性。当多个不同的服务读取和写入同一共享资源时，有可能会遭遇竞争状态——某些数据应当被更新，但读取操作恰好发生在更新之前——这种情形下，数据就是不一致的。例如图像托管方案中可能出现的竞争状态，一个客户端发送请求，将其某标题为“狗”的图像改名为”小家伙“。而同时另一个客户端发送读取此图像的请求。第二个客户端中显示的标题是“狗”还是“小家伙”是不能明确的。
当然，对于分区还有一些障碍存在，但分区允许将问题——数据、负载、使用模式等——切割成可以管理的数据块。这将极大的提高可扩展性和可管理性，当然并非没有风险。有很多可以降低风险和处理故障的方法；不过篇幅有限，不再赘述。若有兴趣，可见于此文，获取更多容错和检测的信息。
1.3 构建高效和可伸缩的数据访问模块
在设计分布式系统时一些核心问题已经考虑到，现在让我们来讨论下比较困难的一部分：可伸缩的数据访问。
对于大多数简单的web应用程序，比如LAMP系统，类似于图1.5。
图1.6：最简单的web应用程序
多数系统简化为如图 Figure 1.6所示，这是一个良好的开始。如果你有大量的数据，你想快捷的访问，就像一堆糖果摆放在你办公室抽屉的最上方。虽然过于简化，前面的声明暗示了两个困难的问题：存储的可伸缩性和数据的快速访问。
为了这一节内容，我们假设你有很大的数据存储空间（TB），并且你想让用户随机访问一小部分数据（查看Figure 1.7）。这类似于在图像应用的例子里在文件服务器定位一个图片文件。
图1.8：在请求层节点插入一个缓存
直接在一个请求层节点配置一个缓存可以在本地存储相应数据。每次发送一个请求到服务，如果数据存在节点会快速的返回本地缓存的数据。如果数据不在缓存中，请求节点将在磁盘查找数据。请求层节点缓存可以存放在内存和节点本地磁盘中（比 络存储快些）。
图1.10：全局缓存（缓存自己负责查找数据）
图1.12：分布式缓存
缓存的伟大之处在于它们使我们的访问速度更快了（当然前提是正确使用），你选择的方法要在更多请求下更快才行。然而，所有这些缓存的代价是必须有额外的存储空间，通常在放在昂贵的内存中；从来没有嗟来之食。缓存让事情处理起来更快，而且在高负载情况下提供系统功能，否则将会使服务器出现降级。
有一个很流行的开源缓存项目Memcached (http://memcached.org/)（它可以当做一个本地缓存，也可以用作分布式缓存）；当然，还有一些其他操作的支持（包括语言包和框架的一些特有设置）。
Memcached被用作很多大型的web站点，尽管他很强大，但也只是简单的内存key-value存储方式，它优化了任意数据存储和快速检索（o(1)）。
Facebook使用了多种不同的缓存来提高他们站点的性能（查看”Facebook caching and performance”）。在语言层面上（使用PHP内置函数调用）他们使用$GLOBALSand APC缓存，这有助于使中间函数调用和结果返回更快（大多数语言都有这样的类库用来提高web页面的性能）。Facebook使用的全局缓存分布在多个服务器上（查看 “Scaling memcached at Facebook”），这样一个访问缓存的函数调用可以使用很多并行的请求在不同的Memcached 服务器上获取存储的数据。这使得他们在为用户分配数据空间时有了更高的性能和吞吐量，同时有一个中央服务器做更新（这非常重要，因为当你运行上千服务器时，缓存失效和一致性将是一个大挑战）。
现在让我们讨论下当数据不在缓存中时该如何处理···
代理
简单来说，代理服务器是一种处于客户端和服务器中间的硬件或软件，它从客户端接收请求，并将它们转交给服务器。代理一般用于过滤请求、记录日志或对请求进行转换(增加/删除头部、加密/解密、压缩，等等)。
图1.14: 使用代理来合并请求
图1.16：索引
索引可以作为内容的一个表格-表格的每一项指明你的数据存储的位置。例如，如果你正在查找B的第二部分数据-你如何知道去哪里找你有个根据数据类型(数据A，B，C)排序的索引，索引会告诉你数据B的起点位置。然后你就可以跳转(seek)到那个位置，读取你想要的数据B的第二部分。 (参看Figure 1.16)
这些索引常常存储在内存中，或者存储在对于客户端请求来说非常快速的本地位置(somewhere very local)。Berkeley DBs (BDBs)和树状数据结构常常按顺序存储数据，非常理想用来存储索引。
常常索引有很多层，当作数据地图，把你从一个地方指向另外一个地方，一直到你的得到你想要的那块数据。(See Figure 1.17.)
图1.18：负载均衡器
用于处理这些请求的算法有很多种，包括随机选取节点、循环式选取，甚至可以按照内存或CPU的利用率等等这样特定的条件进行节点选取。负载均衡器可以用软件或硬件设备来实现。近来得到广泛应用的一个开源的软件负载均衡器叫做HAProxy。
在分布式系统中，负载均衡器往往处于系统的最前端，这样所有发来的请求才能进行相应的分发。在一些比较复杂的分布式系统中，将一个请求分发给多个负载均衡器也是常事，如图1.19所示。
图1.20：同步请求
设想一个系统，每个客户端都在发起一个远程服务的任务请求。每一个客户端都向服务器发送它们的请求，服务器尽可能快的完成这些任务，并分别返回结果给各个客户端。在一个小型系统，一个服务器（或逻辑服务）可以给传入的客户端请求提供迅速服务，就像它们来的一样快，这种情形应该工作的很好。然而，当服务器收到了超过它所能处理数量的请求时，每个客户端在产生一个响应前，将被迫等待其他客户端的请求结束。这是一个同步请求的例子，示意在图1.20。
这种同步的行为会严重的降低客户端性能；客户端被迫等待，有效的执行零工作，直到它的请求被应答。添加额外的服务器承担系统负载也不会解决这个问题；即使是有效的负载均衡，为了最大化客户端性能，保证平等的公平的分发工作也是极其困难的。而且，如果服务器处理请求不可及，或者失败了，客户端上行也会失败。有效解决这个问题在于，需要在客户端请求与实际的提供服务的被执行工作之间建立抽象。
图1.21：用队列管理请求
进入队列。一个队列就像它听起来那么简单：一个任务进入，被加入队列然后工人们只要有能力去处理就会拿起下一个任务。（看图1.21）这些任务可能是代表了简单的写数据库，或者一些复杂的事情，像为一个文档生成一个缩略预览图一类的。当一个客户端提交一个任务请求到一个队列，它们再也不会被迫等待结果；它们只需要确认请求被正确的接收了。这个确认之后可能在客户端请求的时候，作为一个工作结果的参考。
队列使客户端能以异步的方式工作，提供了一个客户端请求与其响应的战略抽象。换句话说，在一个同步系统，没有请求与响应的区别，因此它们不能被单独的管理。在一个异步的系统，客户端请求一个任务，服务端响应一个任务已收到的确认，然后客户端可以周期性的检查任务的状态，一旦它结束就请求结果。当客户端等待一个异步的请求完成，它可以自由执行其它工作，甚至异步请求其它的服务。后者是队列与消息在分布式系统如何成为杠杆的例子（译注：用一个或多个、一层或多层的消息队列来撬动海量的并发连接）。
队列也对服务中断和失败提供了防护。例如，创建一个高度强健的队列，这个队列能够重新尝试由于瞬间服务器故障而失败的服务请求，是非常容易的事。相比直接暴露客户端于间歇性服务中断下－－这需要复杂的而且经常不一致的客户端错误处理，用一个队列去加强服务质量的担保更为可取。
队列在管理任何大规模分布式系统不同部分之间的分布式通信方面是一个基础，而且实现它们有许多的方法。有不少开源的队列如RabbitMQ,ActiveMQ, BeanstalkD，但是有些也用像Zookeeper的服务，或者甚至像Redis的数据存储。
1.4 结论
设计有效的系统来进行快速的大数据访问是有趣的，同时有大量的好工具来帮助各种各样的应用程序进行设计。 这文章只覆盖了一些例子，仅仅是一些表面的东西，但将会越来越多–同时在这个领域里一定会继续有更多创新东西。
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8826 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！