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

  • 时间:
  • 浏览:2

五、 eBay

异步的任务队列

越简单越好

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

在平台的基础上构建任务管理器运行运行

实时的系统级监控

针对工作选着正确的工具,因此 接受一些选着所带来的开销

Twitter使用了一堆消息传送。对用户发布的消息进行排队,因此 整理给指定的用户。Twitter最主要的功能就说 扮演消息传递的桥梁,架起不同格式(SMS、Web、IM等等)之间的消息传送。在后台同步发送消息去清除亲们的缓存,而都会单独的进行。Twitter开发者对Ruby最为熟悉,一些亲们失去DRb转至Starling(有一两个Ruby编写的分布式队列系统)。分布式队列系统将队列写入磁盘,以出理 系统崩溃。以Twitter的经验,大次责的性能提升都会语言的选着就说 任务管理器运行运行的设计。(一些点就说 删改正确了,Twitter因此 性能,以后从Ruby整个迁移到了Scala/JVM。)

因此 你的系统不处在抖动,因此 因此 用户在同一时间对同有一两个资源进行请求产生Thundering Herd(“惊群效应”)。对于有一两个流行的视频,YouTube会尽因此 的为其做缓冲。最流行的视频因此 会缓冲24小时。因此 所有缓存一并到期,因此 造成中间所说的Thundering Herd。通过抖动,不必设置随机的时间(18-30小时)。这将阻止事情在同有一两个时间处在,因此 保证很长时间内请求的顺利完成。

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

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

并不重复设计有一两个方案,让其保持简单

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

建立不断进化的基础设施

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

扩展都要多次的迭代

既然扩展你就都要做分片,一些你都要为特定的系统做高一致性因此 高可用性的选着。你都要发现有效性和一致性上的重叠次责,根据服务的需求选着有一两个大约的方案。举个结账系统的用例:你无缘无故希望将请求作为购物车的添加项,因此 它产生了收入。在一些用例中,你就选着了高可用性。错误就隐藏在了客户方面,因此 由其提出:当客户进行提交时,你都要对一致性进行重点对待,因此 不同的服务(信用卡出理 、运输、操作、报告)都将一并访问数据,因此 每个都会每个人所有数据一致性的需求。

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

拥抱失败

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

可靠的存储(Reliable Storage)

对失败抱平常心,它因此 会无缘无故冒出,一些拥抱它。比如,使用有一两个快速重启和快速恢复方案。选着有一两个大约的数据传输,服务正常运行的几率将接近30%。建立有一两个自我修复、自我组织、无人值守类型的操作。

拥抱不一致

本文出自澳大利亚一位ID为Dodgy Coder的任务管理器运行员2012年4月的博客文章。他从High Scalability上整理和总结了Google、YouTube、Twitter、Amazon、Ebay、Facebook和Instagram等7家知名互联网的系统扩展经验。值得注意的是,一些资料时过境迁,因此 不再反映最新状况,因此 核心的理念和一些具体经验还是非常宝贵的学习资料,值得一读。

并行地执行有一两个耗时(CPU绑定的)操作,并取优胜者。这尤其适合在CPU富余而IO匮乏的状况。

只用你都要的

欺骗:知晓咋样在数据上作假

对于拥有30多个EC2实例的Instagram来说,对系统进行实时的全方位监控无疑是重中之重。亲们使用Munin进行系统级监视,一些监视工具在系统任何操作超过正常范围时都会发出警报。亲们开发了Munin的定制插件,基于Python-Munin之上,监视非系统级事件。亲们使用Pingdom进行服务的结构监视,因此 使用PagerDuty出理 通知和事件。而Python的错误报告,亲们使用Sentry,有一两个开源的Django应用。在任何给定的时间,亲们不必 实时地登录并了解系统中冒出了什么错误。

当有一两个用户决定将Instagram上的图片分享到Twitter因此 Facebook时,因此 当亲们都要给发布的图片发送有一两个实时的通告,亲们把任务推送给开源的Gearman任务管理框架。使用异步队列因为当“重载”在后台进行时,媒体上传不必 快速完成。大约有30个工作者(Python编写)忙于任务队列的出理 ,出理 服务中当事人分割的份额。

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

七、 Instagram

实现API

最快的函数调用就说 根本上不必 处在。当你都要做有一两个持续增加的计数器时,比如说有一两个浏览计数,你都要为每次的更改做数据库调用。因此 不必每隔一段的时间做一次调用,因此 是有一两个随机数量做更改——因此 亲们因此 就会认为它是实时显示的。你都要要知道咋样在数据上作假。

Twitter的API流量是Twitter网站的10倍,API是Twitter增长用户数量最重要的手段。保持服务的简单,允许开发者在当事人基础设施上建立服务,因此 想出比Twitter当事人更好的任务管理器运行运行点子。所谓众人拾柴火焰高,集思广益不必 做更好的创新。一些开放你的应用,因此 让其保持简单,从前就不必 和当事人的任务管理器运行运行进行整合。(当然,以后在赢利压力下,Twitter过河拆桥,将有史以来最有活力的API生态链生生干掉了。)

切分一切

二、  YouTube

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

三、 Twitter

拥抱故障

自动化和恢复

处处异步

抖动(Jitter)

知道什么时间进行缓存以及缓存什么

六、 Facebook

推送通知

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

基础设施成为竞争优势

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

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

考虑数据压缩

举个例子,获得你亲们的状况是很复杂性的,包括了安全等多个隐患。一些,取代对数据库进行查询,亲们的状况因此 被上放缓存。永远都会会接触到数据库。90%的请求都会API请求,一些亲们在前端基本上不做任何页面缓存。因此 Twitter的页面都对时间敏感,从前做(缓存页面)不必 任何好处。

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

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

亲们使用有一两个开源Apple Push Notification Service(APNS)提供任务管理器运行pyapns(基于Twisted),每天稳定地为Instagram出理 10亿推送消息的任务。

使用SOA

四、 Amazon

一、  Google

近似正确

大平台土办法 有有一两个无缘无故被忽略的优势,就说 初级开发者不必 变慢并自信地开发健壮的任务管理器运行运行。因此 每个项目都都要建立分布式基础设施,不必 你变慢因此 陷入困境,因此 懂得不必 去做的开发者非常少。协同效应并不无缘无故空谈,从整个系统上着眼改善,不必 帮助到建立在一些系统上的所有任务管理器运行运行或项目。比如:改善了文件系统就不必 让所有项目都立即因此 透明地(指上层开发者和使用者都不必操心)获益。因此 每个项目都使用不同的文件系统,不必 在整个技术栈上的改进将不必带来持续不断的增益。

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

数据驱动最佳的机遇、预测和推荐的发现,一些保存所有。清楚什么数据是有权威的,什么数据不必 ,进行不同的对待。

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

正确的公司文化

因此 你都要使用Python,并选着了它进行开发,因此 都要要认识到一些选着是有开销的:通常是部署、监视、运营等方面。因此 选着了有一两个面向服务的体系形态(SOA),你都要当事人动手建立大次责所需的后端,这都要大把的时间。通过LAMP不必省下一些开销,因此 一旦你真的选着了LAMP堆栈,例如服务的配置以及监视将是随之要面对的大大问题 。随着你对一些服务了解的加深,你必定会自费力气做重复的工作。

使用你清楚的东西

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

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

利用现有的云基础设施

用户所见都是你在身边系统的状况。因此 用户看不必 你系统中处在的偏移和不一致,不必 什么大大问题 从本质上来说根本“不处在”。因此 你正在有一两个页面上发布评论,而这以后一些用户刚好打开了一些页面,不必 什么用户在半秒内因此 根本看不必 你的评论,然而什么阅读一些页面的用户根本不必在意一些事情。一些状况就允许你稍微的进行“作弊”,因此 你的评论并不必 达到全局一致性。因此 真的去做一些全局上的一致性,那因此 投入几滴 的开销,同样也是牛刀杀鸡——因此 你并都会在做金融系统,一些不必作弊。

在都要使用CAP原理的地方选着好每个形态,因此 选着非分布式事务,不一致性不必 通过操作顺序来最小化,通过异步恢复和调整实现最终一致性。

可靠、可扩展的存储基本上是任何任务管理器运行运行的核心。GFS(Google File System)是Google的核心存储平台——它是有一两个大型分布式形态化的日志文件系统,Google在其中存放了几滴 的数据。咋样自建系统,而都会使用一些已有的产品?因此 Google都要对系统有绝对的掌控力,一并一些平台也正是Google难能可贵成为Google的地方。GFS使亲们获得了跨数据中心的高可靠性、扩展到数以千计个节点的能力、提供巨大的读写传输效率、支持以GB为单位的大数据块出理 和跨节点分布操作以降低瓶颈的高效技术。

好难发现,这7个公司都会以下一并的6大理念:

让设计保持简单,选着设计中不必 隐藏的需求及依赖性。将技术程度降到最低,你只都要一些出理 大大问题 的都要技术。确保什么技术不必带来更多的复杂性性,慎重甚至是不选着一些特定的土办法 因此 技术堆栈。一些地方亲们使用jboss/java,但亲们只选着Servlet,而不使用余下的好多个J2EE框架。使用C++来出理 请求,使用Perl/Mason来建立目录。

Amazon的架构都会松耦合的,因此 围绕着服务建立。有一两个面向服务的体系形态(SOA),基于亲们不必 快速及独立的建立软件的多个组件,允许亲们变慢的向市场上投放。Amazon.com Web页就说 有一两个例如的任务管理器运行运行服务器。从前得话一些任务管理器运行运行一并服务了网络服务接口、用户服务任务管理器运行运行以及卖方接口。

并不忽视学术界

监视所有处在的事情,别间断服务——即使一些次责开始英文了了处在故障。最小化和控制依赖性,使用抽象的接口和虚拟化技术,组件蕴藏 晒 晒 一两个SLA,用户从SLA违规中恢复。自动化所有事情,组件都要自动调整,而系统则都要自我调节和完善。

保存所有的数据

建立有一两个不必 利于生产的结构环境,并根据需求不断的进行完善。在进行正确的编码和做出正确的产品以后,你首先都要定义正确的公司文化;不必 有一两个正确的文化,公司将不必得到发展。

学术界有一些很棒的思想,只不过还不必 进入生产环境。你现在看多Google所做的事情实在都并不新鲜,就说 不必 大规模部署而已。

扩展性即竞争优势

使用测量和客观的讨论去区分好坏。给客户有一两个切实的选着来测试哪个更好,因此 通过什么测试制定决策。这点通常使用例如A/B测试和Web Analytics等技术实现。因此 你产生决策上的大大问题 ,不必 将其编码,让更多的人使用,从而清楚哪个选着才有你在身边真正不必的。

寻找大大问题 领域的最简出理 方案。这里处在一些复杂性的大大问题 ,因此 选着出理 方案的首要前提就说 不必 复杂性。随着时间的发展,复杂性性会无缘无故处在,而最简单和最松散的出理 方案是始终适用的。从前做的因为是保持出理 大大问题 的灵活性,反之你则会把当事人逼入角落。你因此 失去对任务管理器运行的控制,同样当你试图出理 时,大大问题 将变的不必 复杂性,不必变得无路可走。