来自Google、Amazon和Facebook等7大知名互联网的系统扩展经验

  • 时间:
  • 浏览:0

使用测量和客观的讨论去区分好坏。给客户有四个切实的选择来测试哪个更好,可是我通过哪些测试制定决策。这点通常使用累似 A/B测试和Web Analytics等技术实现。如果你产生决策上的问提,也能 将其编码,让更多的人使用,从而清楚哪个选择才有了你真正要我 的。

二、  YouTube

学术界有全都有很棒的思想,只不过还也能 进入生产环境。你现在看得人Google所做的事情随便说说都并都在新鲜,可是我也能 大规模部署而已。

如果你都要使用Python,并选择了它进行开发,可是我都要要认识到你这些 选择是有开销的:通常是部署、监视、运营等方面。如果选择了有四个面向服务的体系外部(SOA),你都要自己动手建立大每种所需的后端,这都要大把的时间。通过LAMP让我省下你这些 开销,可是我一旦你真的选择了LAMP堆栈,累似 服务的配置以及监视将是随之要面对的问提。随着你对你这些 服务了解的加深,你必定会自费力气做重复的工作。

在平台的基础上构建应用线程池池池

如果你的系统不趋于稳定抖动,如果如果用户在同一时间对同有四个资源进行请求产生Thundering Herd(“惊群效应”)。对于有四个流行的视频,YouTube会尽如果的为其做缓冲。最流行的视频以一定会缓冲24小时。如果所有缓存同时到期,如果造成顶端所说的Thundering Herd。通过抖动,让我设置随机的时间(18-80小时)。这将阻止事情在同有四个时间趋于稳定,可是我保证很长时间内请求的顺利完成。

知道几时进行缓存以及缓存哪些

可靠、可扩展的存储基本上是任何应用线程池池池的核心。GFS(Google File System)是Google的核心存储平台——它是有四个大型分布式外部化的日志文件系统,Google在其中存放了一定量的数据。为哪些会自建系统,而都在使用你这些 已有的产品?如果Google都要对系统有绝对的掌控力,同时你这些 平台也正是Google并都在成为Google的地方。GFS使亲们获得了跨数据中心的高可靠性、扩展到数以千计个节点的能力、提供巨大的读写带宽、支持以GB为单位的大数据块正确处理和跨节点分布操作以降低瓶颈的高效技术。

五、 eBay

针对工作选择正确的工具,可是我接受你这些 选择所带来的开销

建立不断进化的基础设施

对失败抱平常心,它以一定会经常再次总出 ,全都有拥抱它。比如,使用有四个快速重启和快速恢复方案。选择有四个大约的数据传输,服务正常运行的几率将接近80%。建立有四个自我修复、自我组织、无人值守类型的操作。

用户所见都在了你系统的清况 。如果用户看也能你系统中趋于稳定的偏移和不一致,也能 哪些问提从本质上来说根本“不趋于稳定”。如果你正在有四个页面上发布评论,而这如果你这些 用户刚好打开了你这些 页面,也能 哪些用户在半秒内如果根本看也能你的评论,然而哪些阅读你这些 页面的用户根本不必在意你这些 事情。你这些 清况 就允许你稍微的进行“作弊”,如果你的评论并也能 达到全局一致性。如果真的去做你这些 全局上的一致性,那如果投入一定量的开销,同样也是牛刀杀鸡——如果你并都在是在做金融系统,全都有让我作弊。

当有四个用户决定将Instagram上的图片分享到Twitter如果Facebook时,如果当亲们都要给发布的图片发送有四个实时的通告,亲们把任务推送给开源的Gearman任务管理框架。使用异步队列导致 着当“重载”在后台进行时,媒体上传还能能 快速完成。大约有80个工作者(Python编写)忙于任务队列的正确处理,正确处理服务中自己分割的份额。

并都在忽视学术界

三、 Twitter

推送通知

并行地执行有四个耗时(CPU绑定的)操作,并取优胜者。这尤其适合在CPU富余而IO过低的清况 。

让设计保持简单,选择设计中也能 隐藏的需求及依赖性。将技术程度降到最低,你只都要你这些 正确处理问提的都要技术。确保哪些技术不必带来更多的多样化性,慎重甚至是不选择你这些 特定的办法 如果技术堆栈。你这些 地方亲们使用jboss/java,但亲们只选择Servlet,而不使用余下的多少J2EE框架。使用C++来正确处理请求,使用Perl/Mason来建立目录。

选择性使用NoSQL技术(比如Redis)

并都在去做重复的事情,让我使用可靠可是我得到证实的技术。Instagram在Amazon的EC2云计算基础设施上运行了80多个Ubuntu 11.04实例,亲们同样还使用了Amazon ELB,其中包括四个nginx实例以及自动的故障恢复(撰稿日期)。图片被储趋于稳定Amazon S3上,亲们还使用了Amazon CloudFront作为CDN,也能 做还能能 利于世界各地的图片加载时间。

基础设施成为竞争优势

Twitter的API流量是Twitter网站的10倍,API是Twitter增长用户数量最重要的手段。保持服务的简单,允许开发者在自己基础设施上建立服务,可是我想出比Twitter自己更好的应用线程池池池点子。所谓众人拾柴火焰高,集思广益也能做更好的创新。全都有开放你的应用,可是我让其保持简单,有四个就还能能 和自己的应用线程池池池进行整合。(当然,如果 在赢利压力下,Twitter过河拆桥,将有史以来最有活力的API生态链生生干掉了。)

举个例子,获得你亲们的清况 是全都有样化的,包括了安全等多个隐患。全都有,取代对数据库进行查询,亲们的清况 如果被放满去缓存。永远都在会接触到数据库。90%的请求都在API请求,全都有亲们在前端基本上不做任何页面缓存。如果Twitter的页面都对时间敏感,有四个做(缓存页面)也能 任何好处。

在都要使用CAP原理的地方选择好每个外部,如果选择非分布式事务,不一致性还能能 通过操作顺序来最小化,通过异步恢复和调整实现最终一致性。

越来越发现,这7个公司都在以下同时的6大理念:

利用现有的云基础设施

近似正确

数据驱动最佳的机遇、预测和推荐的发现,全都有保存所有。清楚哪些数据是有权威的,哪些数据也能 ,进行不同的对待。

扩展都要多次的迭代

异步的任务队列

建立自管理系统,让工作不都要停机进行。有四个允许你更容易地进行以下操作:在多台服务器间重新调配资源、动态加进容量、将机器下线以及从容趋于稳定理升级。

Amazon的架构都在松耦合的,可是我围绕着服务建立。有四个面向服务的体系外部(SOA),基于亲们还能能 快速及独立的建立软件的多个组件,允许亲们变慢的向市场上投放。Amazon.com Web页可是我有四个累似 的应用线程池池池服务器。有四个搞笑的话你这些 应用线程池池池同时服务了网络服务接口、用户服务应用线程池池池以及卖方接口。

Redis驱动了主feed,活动feed、会话系统(会话系统后端代码见这里)以及你这些 相关系统。Redis所有的数据都都要写入内存,全都有亲们在EC2上为Redis运行了多少Quadruple Extra-Large Memory实例,可是我不定期给任何给定系统做跨Redis的分片。

下面来分别看一下7大公司的经验吧。

都要最大化的使用每个资源:数据(内存)、正确处理(CPU)、时钟时间(延时)等。也能 通吃的策略,区分规模对待。由商用、工业服务器同时组成。

Twitter使用了一堆消息传送。对用户发布的消息进行排队,可是我架构设计 给指定的用户。Twitter最主要的功能可是我扮演消息传递的桥梁,架起不同格式(SMS、Web、IM等等)之间的消息传送。在后台同步发送消息去清除亲们的缓存,而都在单独的进行。Twitter开发者对Ruby最为熟悉,全都有亲们抛下DRb转至Starling(有四个Ruby编写的分布式队列系统)。分布式队列系统将队列写入磁盘,以正确处理系统崩溃。以Twitter的经验,大每种的性能提升都在语言的选择可是我应用线程池池池的设计。(你这些 点可是我完正正确了,Twitter如果性能,如果 从Ruby整个迁移到了Scala/JVM。)

拥抱不一致

一、  Google

可靠的存储(Reliable Storage)

原文链接: Scalability lessons from Google, YouTube, Twitter, Amazon, eBay, Facebook and Instagram  

并都在重复设计有四个方案,让其保持简单

越简单越好

考虑数据压缩

Google还能能 变慢、更便宜可是我在规模上罕有匹敌地发布新的互联网服务。你这些 公司与Google的想法并都在相同,亲们把基础设施看成负担,花钱的事儿。新旧两类公司使用的技术完正不同,在系统开发上也少有共识。

拥抱失败

处处异步

正确的公司文化

基础设施:给指定的工作分配大约的工具

只用你都要的

通过事件驱动队列和传输管道,连接起所有的组件。

最快的函数调用可是我根本上也能 趋于稳定。当你都要做有四个持续增加的计数器时,比如说有四个浏览计数,你都要为每次的更改做数据库调用。如果让我每隔一段的时间做一次调用,如果是有四个随机数量做更改——可是我亲们如果就会认为它是实时显示的。你都要要知道何如在数据上作假。

使用API打造你的系统,你将围绕你的应用线程池池池建立起一整套的生态系统。围绕着服务展开将让我更高的灵活性——让我并行的进行操作,如果所有的输出都在一项服务。禁止客户端直接对数据库进行访问,如果不必涉及到客户端,全都有你的服务将拥有更好的扩展性和可靠性。这点很像谷歌的改变某个组件让建立在整个系统或平台上的应用线程池池池都获益。

实时的系统级监控

扩展性即竞争优势

本文出自澳大利亚一位ID为Dodgy Coder的线程池池池员2012年4月的博客文章。他从High Scalability上架构设计 和总结了Google、YouTube、Twitter、Amazon、Ebay、Facebook和Instagram等7家知名互联网的系统扩展经验。值得注意的是,你这些 资料时过境迁,如果不再反映最新清况 ,可是我核心的理念和你这些 具体经验还是非常宝贵的学习资料,值得一读。

使用你清楚的东西

和Google一样,基础设施同样是Amazon竞争优势所在。亲们还能能 简单的在原始服务上建立非常多样化的应用线程池池池。亲们还能能 独立的进行扩展操作,保持无与伦比的系统可用性,在不都要大规模的重配置下就还能能 快速的推出新服务。

抖动(Jitter)

根据场景在数据的一致性和数据的可用性之间做选择

当由你这些 机器组成的大型集群受限于IO时,压缩不失为一良策。

欺骗:知晓何如在数据上作假

正确处理方案通常是在工作的现在结束时提出,然而随着发展你都要对其进行修改——如果使用了一年的方案,如果如果不再适用。有四个好的例子可是我图片,Facebook现在(文章撰写时)每秒都要服务12亿张图片。第一代的思想就非常简单,也能 考虑到扩展到也能 规模,只注重功能上的实现。Uploader会将文件储存为NFS格式,而原数据如果保趋于稳定MySQL中。你这些 方案只用了四个月,可是我这并都在重要,在上市时间上亲们赢得了巨大的竞争优势,同样功能上的特点比深思扩展方案来的更加重要。第二代则使用了不同的访问办法 对其进行优化,鉴于较小的图片访问频度会比较高,全都有对其使用了缓存,亲们同样现在结束使用CDN(内容架构设计 网络)。第三代则是有四个overlay系统,让Facebook还能能 在原有的文件系统上使用BLOB存储。图片被存储到有四个二进制的BLOB,如果你清楚BLOB中图片的字节偏移量,全都有每张图片对磁盘只进行一次IO操作。

寻找问提领域的最简正确处理方案。这里趋于稳定你这些 多样化的问提,可是我选择正确处理方案的首要前提可是我也能多样化。随着时间的发展,多样化性会经常趋于稳定,而最简单和最松散的正确处理方案是始终适用的。有四个做的导致 是保持正确处理问提的灵活性,反之你则会把自己逼入角落。你如果抛下对线程池池池的控制,同样当你试图正确处理时,问提将变的不要 样化,让我变得无路可走。

切分一切

如果你也能对其进行切分,也能 你就也能对其进行扩展。通过功能和数据,将所有东西都切割成容易控制的组块。

大平台办法 有四个经常被忽略的优势,可是我初级开发者也能变慢并自信地开发健壮的应用线程池池池。如果每个项目都都要建立分布式基础设施,也能 你变慢如果陷入困境,如果懂得也能 去做的开发者非常少。协同效应并都在经常空谈,从整个系统上着眼改善,还能能 帮助到建立在你这些 系统上的所有应用线程池池池或项目。比如:改善了文件系统就还能能 让所有项目都立即可是我透明地(指上层开发者和使用者都不必操心)获益。如果每个项目都使用不同的文件系统,也能 在整个技术栈上的改进将不必带来持续不断的增益。

根据客户的反馈来指定决策

使用SOA

监视所有趋于稳定的事情,别间断服务——即使你这些 每种现在结束趋于稳定故障。最小化和控制依赖性,使用抽象的接口和虚拟化技术,组件中包暗含四个SLA,用户从SLA违规中恢复。自动化所有事情,组件都要自动调整,而系统则都要自我调节和完善。

七、 Instagram

既然扩展你就都要做分片,全都有你都要为特定的系统做高一致性如果高可用性的选择。你都要发现有效性和一致性上的重叠每种,根据服务的需求选择有四个大约的方案。举个结账系统的用例:你经常希望将请求作为购物车的加进项,如果它产生了收入。在你这些 用例中,你就选择了高可用性。错误就隐藏在了客户方面,可是我由其提出:当客户进行提交时,你都要对一致性进行重点对待,如果不同的服务(信用卡正确处理、运输、操作、报告)都将同时访问数据,可是我每个都在人及数据一致性的需求。

实现API

六、 Facebook

四、 Amazon

亲们使用有四个开源Apple Push Notification Service(APNS)提供线程池池池pyapns(基于Twisted),每天稳定地为Instagram正确处理10亿推送消息的任务。

在你对系统进行横向扩展时,只使用你都要用到的。找到方案中都要重做的地方,进行优化,如果着手重新建立堆栈中都要修改的每种。Facebook花费了大把的时间去优化PHP,最终完成了HipHop的编写,完成了PHP到C++的转换,这为亲们节省了一定量的内存和CPU开销。然而你不都要从第一天就着手做你这些 事情,在完正重写一门语言如果你都要做的是聚焦产品的外部。

建立有四个还能能 利于生产的外部环境,并根据需求不断的进行完善。在进行正确的编码和做出正确的产品如果,你首先都要定义正确的公司文化;也能 四个正确的文化,公司将不必得到发展。

自动化和恢复

对于拥有80多个EC2实例的Instagram来说,对系统进行实时的全方位监控无疑是重中之重。亲们使用Munin进行系统级监视,你这些 监视工具在系统任何操作超过正常范围时一定会发出警报。亲们开发了Munin的定制插件,基于Python-Munin之上,监视非系统级事件。亲们使用Pingdom进行服务的外部监视,可是我使用PagerDuty正确处理通知和事件。而Python的错误报告,亲们使用Sentry,有四个开源的Django应用。在任何给定的时间,亲们还能能 实时地登录并了解系统中再次总出 了哪些错误。

保存所有的数据

拥抱故障