HAproxy Redis RabbitMQ ActiveMQ beanstalkd ZooKeeper 英文原文：Scalable Web Architecture and Distributed Systems

开放源代码曾经成为一些大型网站的根本准绳。而在这些网站生长的过程当中，一些优良的理论经历和规矩也呈现在他们的构造中。本文旨在引见一些在大型网站构造设计的过程当中需求留意的要害问题和完成目的的根底任务。

本文着重于引见收集系统，虽然一些原则在其他散布式系统中也是实用的。

1.1. web散布式系统的设计准绳

搭建和运营一个可伸缩的web站点或许使用顺序意味着甚么？在原始层面上这仅仅是用户经过互联网衔接到远程资本-使细叱变得可伸缩的部分是将资本、或许拜访的资本，散布于多个Server上。

像生涯中大大多数工作一样，当构建一个web办事时花工夫提早做好方案从久远看来仍是很有协助的；了解一些留意事项和大网站面前的衡量准绳可以在创立小型网站时做出更明智的决议。以下是一些影响大范围web系统设计的要害准绳:

• 可用性:关于非常多公司来讲一个网站的正常运转工夫长短常要害的名誉和功用，像一些大型的在线零售系统，即便一分钟的宕机都有可能招致数千或许数百万美元的丧失，因而设计系统的不时可用性和弹性的过错处置机制既是一个根本营业也是一个技巧请求。 高可用散布式系统需求细心思索要害组件的冗余，分系统失败后能疾速修复，而且当问题呈现时优雅型升级。
• 功能:网站的功能正在酿成大大多数站点思索的一个主要的方面，网站的速度影响正常运用和用户的称心度，异样影响搜刮的排名，这也是影响网站收益和保存用户的一个要素。因而，创立一个疾速呼应和低延迟的系统长短常要害的。
• 牢靠性:一个系统需求具有牢靠性，比方统一个数据的恳求一直前往异样的数据呼应 。假如数据改动或许被更新，那末异样的数据将前往一个新的数据。用户需求晓得一些工具被写入系统或许被存储到系统后，系统会坚持稳定而且可以在当前恢复到适宜的地位。
• 可伸缩性:当谈就任何大型的散布式系统时，范围巨细只是思索的此中一个方面，异样主要的是加强处置较大范围的负载功能所做的尽力，这凡是称为系统的可伸缩性。可伸缩性可以代表系统非常多分歧的参数：额定流量的处置量，添加存储容量的便意性，乃至事务的处置量。
• 可治理性: 设计一个系统可以便利操纵是另外一个主要的思索方面，系统的可治理性同等于操纵的可伸缩性：保护和晋级。可治理性需求思索的工作是当问题发作时便利诊断和了解问题，易于晋级和修正，和系统能容易性的操纵（即，例行的操纵是否失败和异常？）
• 本钱: 本钱是一个主要的要素。很分明这包括硬件和软件本钱，但异样主要需求思索的其他方面是安排和保护系统的本钱。开辟者构建系统破费的大量工夫，运维安排工夫，乃至培训工夫都需求思索，本钱是整体本钱。

以上每一个准绳都为设计散布式web架构供给了根底决议计划。但是，他们也能相互互斥，例如要完成某个目的就要以别的的作为价格。一个根本的例子：选择经过纯真增加更多的Server（可扩大性）来增加地址容量，是以可治理性（你必需操纵增加的Server）和本钱（Server的价钱）为价格的。

当设计任何的web使用顺序时，思索这些要害准绳都是很主要的，即便得供认一个设计可能要就义它们当中的一个或许多个。

1.2. 根底

当设计一个系统架构时，有一些工具是要思索的：准确的部分是甚么，如何让这些部分很好地交融在一同，和好的折衷办法是甚么。凡是在系统架构需求之前就为它的可扩大性投资不是一个聪慧的贸易选择；但是，在设计上的深谋远虑能在将来节俭大量的工夫和资本。

这部分存眷点是简直一切大型web使用顺序中间的一些中心要素：办事、冗余、划分和过错处置。每个要素都包括了选择和让步，特殊是上部分提到的设计准绳。为了具体的剖析这些，最好是用一个例子来开端。

实例：图片托管使用

有时分你可能会在线上传一张图片。关于那些托管并担任分发大量图片的网站来讲，要搭建一个既节俭本钱又高效还能具有较低的延迟性（你能疾速的获图片）的网站架构的确是一种应战。

我们来假定一个系统，用户可以上传他们的图片到中间Server，这些图片又可以让一些web链接或许API获得这些图片，就好像如今的Flickr或许Picasa。为了简化的需求，我们假定使用顺序分为两个首要的部分：一个是上传图片到Server的才能（凡是说的写操纵），另外一个是查询一个图片的才能。但是，我们固然想上传功用很高效，可是我们更关怀的是可以疾速分发才能，也就是说当某个人恳求一个图片的时分（比方，一个web页面或许其它使用顺序恳求图片）可以疾速的知足。这类分发才能很像webServer或许CDN衔接Server（CDNServer普通用来在多个地位存储内容一边这些内容可以从天文地位或许物理上更接近拜访它的用户，已到达高效拜访的目标）气的感化。

系统其他主要方面：

• 对图片存储的数目没有限制，所以存储需求可扩大，在图象数目方面需求思索。
• 图片的下载和恳求不需求低延迟。
• 假如用户上传一个图片，图片应当都在那边（图片数据的牢靠性）。
• 系统应当轻易治理（可治理性）。
• 因为图片主机不会有高利润的空间，所以系统需求具有本钱效益。
  

Figure 1.1是一个简化的功用图。

Figure 1.1: 图片主机使用的简化架构图

在这个图片主机的例子里，可碰见细叱必需疾速，它的数据存储要牢靠和这些一切的属性都应当高度的可扩大。树立这个使用顺序的一个小版本不是很主要并且很轻易安排在单一的Server上；但是，这不是这节里的感兴味部分。假定下我们想建一个会增加到和Flickr痛让范围的工具。

办事

当要思索设计一个可扩大的系统时，为功用解耦和思索下系统每部分的办事都界说一个明晰的接口都是很有协助的。在实践中，在这类方法下的系统设计被成为面向办事架构（SOA）。关于这类型的系统，每一个办事有本人自力的办法高低文，和运用笼统接口与高低文的内部任何工具实行交互，典范的是此外办事的公共API。

把一个系统解构为一些列互补的办事，可以为这些部分从此外部分的操纵解耦。如许的笼统协助在这些办事服、它的根底情况和办事的花费者之间树立明晰的关系。树立这类明晰的轮廓能协助隔离问题，但也答应各模块绝对其它部分自力扩大。这类面向办事设计系统长短常相似面向工具设计编程的。

在我们的例子中，上传和检索图象的恳求都是由统一个Server处置的；但是，由于系统需求具有伸缩性，有来由要将这两个功用分化为各由本人的办事实行处置。

疾速转发（Fast-forward）假定办事处于大量运用中；在这类状况下就很轻易看到，读取图象所花的工夫中有几多是因为遭到了写入操纵的影响（由于这两个功用将竞争运用它们同享的资本）。取决于所采取的系统构造，这类影响多是宏大的。即便上传和下载的速度完整类似（在绝大大多数IP收集中都不是如许的状况，大部分下载速度和上传速度之比都最少设计为3:1），文件读取操纵普通都是从高速缓存中实行的，而写操纵却不能不实行终极的磁盘操纵（并且可能要写几回才干告竣最初的一致形态）。即便一切内容都已在内存中，或许从磁盘（比方SSD磁盘）中实行读取，数据库写入操纵简直常常都要慢于读取操纵。（Pole Position是一个开源的DB基准测试Tools，http://polepos.org/，测试后果拜见 http://polepos.sourceforge.net/results/PolePositionClientServer.pdf）

这类设计另外一个潜伏的问题出在webServer上，像Apache或许lighttpd凡是都有一个可以保持的并发衔接数上限（默许状况下在500摆布，不外可以更高）和最高流量数，它们会很快被写操纵耗费掉。由于读操纵可以异步实行，或许采取其它一些像gizp紧缩的功能优化或许块传输Coding方式，webServer可以经过在多个恳求办事之间切换来知足比最大衔接数更多的恳求（一台Apache的最大衔接数设置为500，它每秒钟供给近千次读恳求办事也是正常的）。写操纵则分歧，它需求在上传过程当中坚持衔接，所以大大多数家庭收集情况下，上传一个1MB的文件可能需求超越1秒的工夫，所以webServer只能处置500个如许并发写操纵恳求。

关于这类瓶颈，一个好的计划案例是将读取和写入图片别离为两个自力的办事，如图Figure 1.2.所示。这让我们可以独自的扩大此中恣意一个（由于有可能我们读操纵比写操纵要频仍非常多），同时也有助于我们理清每一个节点在做甚么。最初，这也防止了将来的忧愁，这使得毛病诊断和查找问题更容易，像慢读问题。

这类办法的长处是我们可以独自的处理各个模块的问题-我们不必担忧写入和检索新图片在统一个高低文情况中。这两种办事依然运用全球材料库的图片，可是它们可经过恰当的办事接口自在优化它们本人的功能（比方，恳求行列，或许缓存热门图片-在这之上的优化）。从保护和本钱角度来看，每一个办事按需实行自力范围的计划，这点十分有效，试想假如它们都组合混淆在一同，此中一个无意间影响到了功能，别的的也会受影响。

本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。 2KB翻译任务按照 CC 协定，假如我们的任务有进犯到您的权益，请实时联络我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务