大型Web 2.0企业技术架构集

Google架构

文/Todd Hoff 译/黄翀

Google是可伸缩性控制方面的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。

平台

l  Linux

l  开发语言：Python，Java，C++

状态

l  在2006年大约有450,000台廉价服务器

l  在2005年Google索引了80亿Web页面，现在没有人知道数目

l  目前在Google有超过200个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节

l  目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序

l  BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择

架构

Google将它们的基础架构形象化为三层架构：

l  产品：搜索，广告，email，地图，视频，聊天，博客

l  分布式系统基础组织：GFS，MapReduce和BigTable

l  计算平台：一群不同的数据中心里的机器

l  确保公司里的人们的部署开销很小

l  在避免丢失日志数据的硬件上花费较多的钱，其他类型的数据则花费较少

可信赖的存储机制GFS(Google File System)

l  可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台。

l  Google File System ——大型分布式结构化日志文件系统，Google在里面存储了大量的数据。

l  为什么构建GFS而不是利用已有的东西？因为可以自己控制一切，况且这个平台与别的不一样，Google需要：

n  跨数据中心的高可靠性

n  成千上万的网络节点的伸缩性

n  大读写带宽的需求

n  支持大块的数据，可能为上千兆字节

n  高效的跨节点操作分发以减少瓶颈

l  Master和Chunk服务器：

-      Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器的交流则可以在文件上进行元数据操作并找到包含用户需要数据的那些Chunk服务器。

-      Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦经Master服务器指明，客户端程序就会直接从Chunk服务器读取文件。

l  一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群。

l  关键点在于有足够的基础组织可以让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求。

使用MapReduce来处理数据

l  你现在已经有了一个很好的存储系统，那么该怎样处理如此多的数据呢？比如大量TB级的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因。

l  MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值来生成一个中间的键/值，还有一个 reduce方法以合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动的在一个拥有大量机器 的集群里并行运行。运行时系统处理输入数据的划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这就允许程序员没有多少并行和 分布式系统的经验就可以很容易使用一个大型分布式系统资源。

l  为什么使用MapReduce？

n  跨越大量机器分割任务的好方式。

n  处理机器失败。

n  可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。可以预先计算有用的数据、查询字数统计、对TB的数据排序等等。

l  MapReduce系统有三种不同类型的服务器：

n  Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态。

n  Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件。

n  Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作。

l  例如，你想统计在所有Web页面里的字数。你应该将存储在GFS里的所有页面抛入MapReduce。所有的调整、工作调度、失败处理和数据传输将在成千上万台机器上同时进行并且自动完成。

n  步骤类似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS。

n  在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数。

n  Shuffling操作聚集键类型。

n  Reduction操作计算所有键值对的综合并产生最终的结果。

l  Google索引操作管道有大约20个不同的map和reduction。

l  程序可以非常小，如20到50行代码。

l  一个问题可能是掉队者，就是是一个比其他程序慢的计算，阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的。

l  数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。

在BigTable里存储结构化数据

l  BigTable是一个大伸缩性、容错的、自管理系统，包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万数量级的读写操作。

l  BigTable是一个构建于GFS之上的分布式Hash机制，但不是关系型数据库，不支持join或者SQL类型查询。

l  提供查询机制通过键访问结构化数据。GFS存储存储不透明的数据，而许多程序需求有结构化数据。

l  商业数据库不能达到这种级别的伸缩性，并且不能在成千上万台机器上工作。

l  通过控制自己的低级存储系统，Google得到更多的控制权来改进它们的系统。例如，如果想让跨数据中心的操作更简单这个特性，就可以内建它。

l  可以自由的增删系统运行时机器，而整个系统可以保持正常工作。

l  每个数据条目存储在一个格子里，可以通过一个行key和列key或者时间戳来访问。

l  每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable。

l  BigTable有三种类型的服务器：

n  Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务

n  Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。

n  Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥。

l  一个locality组可以将物理上将相关的数据存储在一起以便得到更好的locality选择。

l  tablet尽可能的缓存在RAM里。

硬件

l  当你有很多机器时，你怎样组织它们来达到成本的有效利用，并发挥最大效力？

l  使用非常廉价的硬件。

l  使用不可靠的（failure-prone）架构方式，而不是在高度可靠的组件上搭建基础架构，你可以获得1000倍计算能力的提升，而成本却降低了33倍。你必须在不可靠性之上来构建可靠性，以使得这个策略可以起作用。

l  Linux系统，采取内部机架放置的设计方式，使用PC主板，低端存储。

l  基于性能来评估能源消耗不是好的方式，会遇到严重的电力和制冷方面的问题。

l  混合使用服务器，并使用他们自己的数据中心。

其他

l  迅速更改而不是等待QA。

l  库是构建程序的卓越方式。

l  一些程序作为服务提供。

l  通过一个基础组织处理程序的版本，这样可以自由发布而不用害怕会破坏什么东西。

Google将来的方向

l  支持地理位置分布的集群。

l  为所有数据创建一个单独的全局名字空间，将当前的数据从集群分离。

l  更多和更好的自动化数据迁移和计算。

l  解决使用网络划分做广阔区域的备份时的一致性问题(例如保持服务，即使有一个集群离线维护或存在一些损耗问题)。

经验教训

l  基础组织具有竞争性的优势，特别是对Google而言。Google可以很快很廉价的推出新服务，并且具有其他人很难达到伸缩性。许多公司采取完全不同的方式。他们认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式。

l  跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的。

l  如果你自己没有时间从零开始重新构建所有这些基础组织，你可以看看Hadoop。Hadoop是这里很多主意的一个开源实现。

l  平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境。因为知道怎样完成这项工作的人相对较少。

l  协同工作不一直是掷骰子。通过让系统中的所有部分一起工作，则一个部分的改进将帮助所有的部分。改进文件系统，则每个人从中受益并且是透明的。如果每个项目使用不同的文件系统，则在整个堆栈中享受不到持续增加的改进。

l  构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源，动态添加更大的容量，让机器离线和优雅的处理升级。

l  创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案。

l  不要忽略大学等研究教学机构。那里有许多没有转变为产品的好主意。绝大部分Google所实现的领先技术，其实并不是多么宏大且超前的设计。

l  考虑压缩——当你有许多CPU而IO有限时，压缩是一个好的选择。

 

Amazon的体系结构

Amazon从一个很小的网上书店发展成为现今世界上最大的网上书店中。他们开辟了让顾客来评估，审查和推荐商品的新方式。

平台

l  Linux

l  Oracle

l  C++

l  Perl

l  Mason

l  Java

l  Jboss

l  Servlets

状态

l  超过5500万活动顾客帐号

l  世界范围内超过100万活动零售合作商

l  构建一个页面所需访问的服务介于100至150个之间

体系结构

l  我们说的可伸缩性到底意味着什么？对于一个服务来说，当我们增加为其分配的系统资源之后，它的性能增长能够与投入的资源按比例提升，我们就说这个服务具有 可伸缩性。通常意义上的性能提升，意味着能够提供更多的服务单元，也可以为更大的工作单元提供服务，比如增长的数据集等。

l  Amazon的架构经历了巨大的变化，从一开始时的两层架构，转向了分布式的、去中心化的服务平台，提供许多种不同的应用。

l  最开始只有一个应用来和后端交互，是用C++来完成的。

l  架构会随着时间而演进。多年来，Amazon将增容的主要精力放在后端的数据库上，试图让其容纳更多的商品数据，更多的客户数据，更多的订单数据，并让其 支持多个国际站点。到2001年，前端应用很明显不能再做任何增容方面的努力了。数据库被分为很多个小部分，围绕每个部分会创建一个服务接口，并且该接口 是访问数据的唯一途径。

l  数据库逐渐演变成共享资源，这样就很难再在全部业务的基础之上进行增容操作了。前端与后端处理的演进受到很大限制，因为他们被太多不同的团队和流程所共享了。

l  他们的架构是松散耦合的的，并且围绕着服务进行构建。面向服务的架构提供给他们的隔离特性，让他们能够快速、独立地完成许多软件组件的开发。

l  逐渐地，Amazon拥有了数百个服务，并有若干应用服务器，从服务中聚合信息。生成Amazon.com站点页面的应用就位于这样的一台应用服务器之上。提供web服务接口、顾客服务应用以及卖家接口的应用也都是类似的情况。

l  许多第三方的技术难以适用Amazon这种网站的规模，特别是通讯基础架构技术。它们在一定范围内工作的很好，但是如果范围再扩大的话，它们就不适用了。因此，Amazon只好自己开发相应的基础技术。

l  不在一种技术上"吊死"。Amazon在有的地方使用jboss/java,不过只是使用servlets，并没有完全使用j2ee中所涉及到的技术。

l  C++开发的程序被用来处理请求。Perl/Mason开发的程序用来生成页面中的内容。

l  Amazon不喜欢采用中间件技术，因为它看起来更像一种框架而不是一个工具。如果采用了某种中间件，那么就会被那种中间件所采用的软件模式所困扰。你也 就只能选用他们的软件。如果你想采用不同的软件几乎是不可能的。你被困住了！经常发生的情况就是消息中间件，数据持久层中间件，Ajax等等。它们都太复 杂了。如果中间件能够以更小的组件的方式提供，更像一个工具而不是框架，或许对我们的吸引力会更大一些。

l  SOAP 相关的web解决方案看起来想再次解决所有分布式系统的问题。

l  Amazon提供SOAP和REST这两种Web 服务。大概有30%的用户采用SOAP这种Web Services。他们看起来似乎是Java和.NET的用户，而且使用WSDL来生成远程对象接口。大概有70%的用户使用REST。他们看起来似乎是 PHP和PERL的用户。

l  无论采用SOAP还是REST，开发人员都可以得到访问Amazon的对象接口。开发人员想要的是把工作完成，而不需要关心网线上传输的是什么东西。

l  Amazon想要围绕他们的服务构建一个开放的社区。他们之所以选择Web Services是因为它的简单。事实上它是一个面向服务的体系架构。简单来说，你只有通过接口才能访问到需要的数据，这些接口是用WSDL描述的，不过它们采用自己的封装和传输机制。

l  架构开发团队都是小规模团队，而且都是围绕不同的服务进行组织。

n  在Amazon服务是独立的功能交付单元。这也是Amazon如何组织他的内部团队的。

n  如果你有一个新的业务建议，或者想解决一个问题，你就可以组织一个团队。由于沟通上的成本，每个团队都限制到8~10个人。他们被称为two pizza teams。因为用两个比萨饼，就可以让团队成员每个人都吃饱了。

n  团队都是小规模的。他们被授权可以采取他们所中意的任何方式来解决一个问题或者增强一个服务。

n  例如，他们创建了这样一个团队，其功能是在一本书中查找特有的文字和短语。这个团队为那个功能创建了一个独立的服务接口，而且有权做任何他们认为需要做的事情。

l  部署

n  他们创建了一个特殊的基础设施，来完成对依赖性的管理和对完成服务的部署。

n  目标是让所有正确的服务可以在一个主机中部署。所有的应用代码、监控机制、许可证机制等都应该在一个“主机”中。

n  每个人都有一个自己的系统来解决这些问题。

n  部署进程的输出是一个虚拟机，你可以用EC2来运行他们。

l  为了验证新服务的效果，从客户的角度去看待服务，这样做是值得的。

n  从客户的角度去看待服务，聚焦于你想交付给用户的价值。

n  强迫开发人员将关注点放在交付给客户的价值上，而不是先考虑如何构建技术再考虑如何使用技术。

n  从用户将要看到的简要特性开始，再从客户考虑的角度检查你构建的服务是否有价值。

n  以最小化的设计来结束设计过程。如果想要构建一个很大的分布式系统，简单性是关键。

l  对于大型可伸缩系统来说状态管理是核心问题

n  内部而言，他们可以提供无限存储空间。

n  并不是所有的操作是有状态的。结账的步骤是有状态的。

n  通过分析最近点击过的页面的SessionID，这种服务可以为用户提供推荐商品建议。

n  他们追踪、保存着所有的数据，所以保持状态不是一个问题。有一些分离的状态需要为一个session来保持。提供的服务们会一直保留信息，所以你只要使用这些服务就可以了。

l  Eric Brewers' CAP理论——或称为系统的三个属性

n  系统的三个属性：一致性，可用性，网络分区容忍度。

n  对于任何一个共享数据的系统都至少具备这三个属性中的两个。

n  网络分区容忍度：把节点分割成一些小的分组，它们可以看到其他的分组但是无法看到其他全部节点。

n  一致性：写入一个值然后再读出来，你得到的返回值应该和写入的是同一个值。在一个分区系统中有些情况并非如此。

n  可用性：并非总是可读或者可写。系统可能会告诉你无法写入数据因为需要保持数据的一致性。

n  为了可伸缩性，你必须对系统进行分区，因此针对特定的系统，你要在高一致性或者高可用性之间做出选择。你必须找到可用性和一致性的恰当重叠部分。

n  基于服务的需要来选择特定的实现方法。

n  对于结账的过程，你总是想让更多的物品放入顾客的购物车，因为这样可以产生收入。在这种情况下你需要选择高可用性。错误对顾客是隐藏的，过后才会被拿出来分析。

n  当一个顾客提交订单过来时，我们要将关注点更多的放在保持高一致性上。因为几个不同的服务——信用卡处服务、配送服务、报表功能等——在同时访问那些数据。

汲取的教训

l  为了构建真正的可伸缩的系统，你必须改变你的想法或者心态。混沌方法在概率意义上可能工作的很好。在传统的系统中我们展示的是一个完美的世界，没有什么东 西会出现问题、停止运转，之后我们在这个完美的世界上构造复杂的算法。实际上，事情总是会出问题的，这就是你必须要接受的事实。例如，试着多想想如何快速 完成服务器重启和如何快速恢复数据。合适的分布数据和服务，你可能向100%无故障又迈进了一步。创建可自愈的（self-healing）、自组织的 （self-organizing）系统架构。    

l  创建一个没有分享的基础架构。对于开发和部署来说，基础架构也是共享资源，就像在逻辑层和数据层共享的资源一样，你也会遭遇到出问题的时候。可能会导致锁 机制和屏蔽机制，并产生死锁。一个面向服务的架构，允许采取并行和分离的开发流程，这样可以使得功能特性的开发也具有“可伸缩性”，与系统的增长相匹配

l  将系统及其API同时开放，这样你会围绕着你的应用创建了一个生态系统。

l  管理巨大的分布式系统的唯一方法，就是让所有的事情尽可能的简单。保持事情简单的办法就是保证设计的时候没有隐藏的需求和隐藏的依赖关系。采用尽可能少的技术来解决你解决的问题。人为的创造一些不需要的复杂系统层次架构对公司并没有益处。

l  围绕服务进行组织可以提供敏捷性。你可以并行的做事情，因为输出结果是一个服务。这使得缩短了产品和服务投放到市场去的时间。需要创建一个基础架构来保证服务可以被很快的构建起来。

l  任何事情，在有真正的实现之前，就来了一堆炒作消息，这其中肯定存在着问题。

l  在内部使用服务品质协议（Service Level Agreement，简称SLA）来管理服务。

l  任何人都可以很快的为他们的产品添加Web Services。以服务的形式来实现你的一部分产品，并开始使用这些服务。

l  由于性能，可靠性和成本控制的原因，可能需要自己来构建基础设施架构。自己构建这些基础架构即便Amazon关门了也不必说是某某公司的错误导致的。自己 构建的系统可能没有其他的易用，不过相对使用第三方的东西来说，你可以更快地对自己构建的基础架构进行修补、调试和部署。

l  采用“‘方法’和‘目的’”这样的思辨方式，来区分好与坏。我曾参加过几次前Amazon员工做的演讲，从中发现，这是Amazon和其他公司很不一样的 独特而有趣之处。其深层道理是，通过将选择的权利交给真正的顾客，来看哪种做法最合适，并基于这些测试来发现顾客的真正需要。Avinash Kaushik把这个叫做避免HiPPO（the highest paid people in the room，屋子里拿薪水最高的人）的影响。通过A/B测试和Web Analytics等技术手段可以达成目的。如果你对应该做什么有疑问，先开发一些功能，让人们使用这些功能，再看哪一种变通使用方式能够带给你想要的结 果。

l  创建一个节俭的环境。例如，Amazon就把门当桌子来用。

l  了解你需要什么。Amazon早期有一个很糟糕的经历，就是没有达成预期目标的推荐系统： “这不是我们所需要的图书推荐系统。Amazon需要的是一个可以基于少量分散的数据，例如一些顾客的评分和购买记录，就可以很好的工作的图书推荐系统。 而且它的反应速度要足够快。这个系统也需要适应大量的数据和大量的图书类别。而且它还可以帮助读者发现一些他们真正需要却自己无法发现的图书需求。”

l  人性化的项目——人们跟随这个项目是因为他们对其感兴趣——可以激发更多的价值和创造力。不要低估因为兴趣而激发的力量。

l  在创建产品的过程中，让每个人都参与进来。在圣诞大采购来临之时，去仓库打包图书吧，这样才是团队精神。

l  创建一个可以用来测试的站点，测试通过之后才可以真正的向大众推出。

l  对于Web服务器使用的只读数据来说，一个健壮的、集群式的、冗余的、分布式文件系统是完美的。

l  如果更新没有成功的话，要有可以回滚到以前正常的状态的运作方式。必要的话开发一个工具。

l  转向更深入的基于服务的架构

l  面试的时候需要关注参加面试者的三个要点：热情，创造力和熟练程度。在Amazon，成功的最大特征就是对工作的热情。

l  要雇佣这样的员工，他们有着惊人的调试技术和系统知识，最重要的是，他们可以在高度压力的状况下，应对非常棘手的问题。

l  创新只能来自于底层。最了解问题的人才是最有可能解决问题的人。任何一个依赖于创新的组织必须可以容纳一定程度的混沌。忠诚和服从不是你的工具。

l  创新精神必须无处不在。

l  任何人都应该有机会去尝试，去学习，去实践。职位的变迁，服从，传统的习惯都不应该有多大的权利。创新的蓬勃发展，必须要有一套行之有效的考核办法。

l  拥抱创新。在整个公司员工的面前，Jeff Bezos会亲自颁发'Just do it'奖，一双旧的耐克鞋，给那些具有创新精神员工。

l  不要基于绩效给付薪酬。给予好的福利和高的薪酬，但是要让大部分人都能享受到。通过其他的方式来表达出对一些表现非常优异的员工的认可。'按劳分配'听起 来不错，但是在一个大公司内是不可能做到公平的。采用一些非货币的奖励，例如一双旧的耐克鞋其实也是很好的。那也是一种用来表达感谢的方式，说明有人在关 心他们。

l  迅速扩张。像Barnes& Nobel这样的大型对手紧跟在你的后面。Amazon曾经不是互联网上最大的书店，不是第二名，甚至也不是第三名。但是他们的远景规划和执行方式最终让他们笑到了最后。

l  在数据中心，员工花在解决基础设施问题上面的时间只有30%是和利润创造相关的。其他的70%的时间则是花在"繁重"的硬件采购、软件管理、负载均衡、维护、应对增容挑战等其他事情上。

l  严禁客户直接访问数据。这意味着你可以让你的服务具有可伸缩性，并在不影响客户的前提下，具有更好的可靠性。这有些类似于Google的能力，他们能够通过对服务器栈的独立、分布的改进，来提升所有的应用。

l  创建统一的服务访问机制。这使得服务易于集成，还可以完成请求路由去中心化、分布请求追踪、以及其他一些高级的基础架构技术。

l  让世界上任何开发人员都能够通过Web服务接口，免费访问Amazon.com。这也是成功的一个重要因素。因为它引发的诸多创新，仅靠Amazon自己的队伍是无法想象出来或者无法实现的。

l  开发人员自己知道哪些工具用起来最顺手，什么样的工具最适合目前的工作。

l  不要在工程师身上强加过多的限制。为某些功能的完成提供一些激励措施，比如与监控系统的集成，或者与其他基础架构工具的集成等功能。但是对于其他的功能，要保证团队的独立性。

l  开发人员与艺术家类似，如果有足够的自由，他们就可以把工作做到最好，但是他们也需要好的工具。提供尽量多的支持工具，围绕着服务的开发，提供环境的支持，使得环境不会成为开发工作的阻碍。

l  谁构建，谁运行。这让开发人员与他们所开发的软件的日常运营工作相联系。也带给他们与顾客之间的日常联系。这种顾客反馈循环对于提升服务质量来说是至关重要的。

l  每隔两年，开发人员就应该与客户服务部门在一起待一段时间。在那里，他们可以听到真实的，回答客服电子邮件，并深刻领会他们作为技术人员所开发的东西造成的影响。

l  让大家聆听“来自顾客的声音”，内容是一个顾客讲述自己使用网站所产生的用户体验的真实故事。这可以让管理层和工程师们体会到，我们是在为实实在在的人们开发这些技术。通过客服统计数据，我们可以提早发现做错了哪些事情，或是发现哪些是客户的真实痛点。

l  就像Google一样，Amazon的基础架构是他们的巨大核心竞争力。通过一些相对简单的底层服务，他们可以构建出非常复杂的应用。他们可以彼此独立地完成各个服务的增容，维护非并行系统的可用性，并在不需要修改大量系统配置的情况下，快速发布新的服务。

 

eBay的架构

文/Todd Hoff 译/于晓潮

有谁不想知道eBay是如何开展业务的呢？成为世界上最大的高负荷量的网站之一，这个过程可不容易。创建这样一个庞然大物，需要真正的工程学：在网站的稳定性、运转速度、性能和成本之间达到一个平衡。

你可能无法模仿eBay增容系统的方法，但是其中的问题和可能的解决方案是值得我们学习借鉴的。

平台

Ÿ   Java

Ÿ   Oracle

Ÿ   WebSphere

Ÿ   Horizontal Scaling

Ÿ   Sharding                                       

Ÿ   Mix of Windows and Unix

统计数据

Ÿ   每天一般处理260亿个SQL请求，对1亿件供出售的商品进行跟踪记录

Ÿ   2.12亿名注册用户，10亿张照片

Ÿ   每天10亿次页面访问量，产生1.05亿张列表，2PB的数据。每月30亿应用程序接口呼叫。1999年6月到2006年第三季度间，页面浏览量、邮件的发送量、带宽增长了35倍。

Ÿ   99.94%的可用性，通过“每个人都可以使用网站的所有部分”与“在某个地方有些用户无法使用网站的至少一个部分”对比计算得出。

Ÿ   数据库虚拟化，涵盖分布在100多个服务器集群中的600种产品实例。

Ÿ   15,000 个J2EE应用服务器。大概100组的功能（又叫做apps）。“池”的概念：处理所有销售业务的机器。[DSJ1] 

架构

Ÿ   一切设计都依照“如果负荷增长十几倍会怎么样”来考虑。采取平行性增容而非垂直性增容，即拥有很多平行的盒子。

Ÿ   架构被严格分成：数据层、应用层、搜索、运行

Ÿ   表示层使用MSXML框架（即使在Java中）

Ÿ   Oracle数据库，Websphere Java（1.3.1版本）

Ÿ   依照主访问路径、以及对一个主键的模数为界限，划分数据库

Ÿ   每个数据库至少有三个在线数据库，分布在8个数据中心。

Ÿ   一些数据库备份在15分钟、4个小时之后运行

Ÿ   数据库依照功能分割为70余项，包括：用户、项目账户、反馈、交易等。

Ÿ   不使用存储过程，有一些非常简单的触发机制。   

Ÿ   密集使用CPU的任务从数据库层移到应用层。因为应用服务器便宜而数据库则是制约瓶颈，所以参照完整性、连接和分类在应用层完成。

Ÿ   没有客户端事务处理和分布式事务处理。

Ÿ   J2EE：使用servlets、JDBC、连接池（具有重新写入功能），其它很少使用。

Ÿ   应用层中没有状态信息。状态信息存在于cookie或者scratch数据库中。

Ÿ   应用服务器之间没有对话——采用严格的架构分层。

Ÿ   网站上的一般商品在卖出之前其搜索数据（比如价格）改变5次，因此实时的搜索结果非常重要。

Ÿ    Voyager——eBay建立的实时反馈架构。使用基本数据库提供的的可靠的多点映射机制（multicast），来完成节点搜索、内存中的搜索索引、水平分割、N切片、在M个实例中平衡负载、存储请求等功能。

经验总结：

Ÿ   减容，而不是扩容

——在每一层上平行增容

——功能分解

Ÿ   推荐异步整合

——最小化可用性耦合

——增加增容的选择

Ÿ   虚拟组件

——降低物理依存

——提高配置弹性

Ÿ   应对故障的设计

——自动的故障检测和通知

——在商务特性中采用“失效保护模式”

Ÿ   因为数据库是制约瓶颈，所以将任务从数据库移到应用层。Ebay在这方面做的非常极端。我们看到其它的架构使用缓存和文件系统来解决数据库的瓶颈问题，而Ebay甚至用应用层处理很多传统的数据库操作（如表连接）。

Ÿ   按自己的意愿使用和舍弃，不必采用全套框架，只使用对你有用的。eBay没有使用完整的J2EE stack，只是采用servlets、JDBC、连接池等。

Ÿ   不要害怕构建满足你的需求并按需求发展的解决方案。每一个现成的解决方案都不可能完全让你高枕无忧，你必须自己走完剩下的路。

Ÿ   随着业务的成长，运行控制成为增容的越来越大的一部分。如果运行一个即时使用的系统，你必须考虑如何升级、配置和监视数以千计的机器。

Ÿ   架构进化——任何一个成长中的网站面临的主要挑战。在保持现有网站运行的同时，需要有改变、改善和开发新系统的能力。

Ÿ   一开始就过于担心可增容性是错误的。因为分析和担心可能永远也不会发生的流量而陷入恐慌是不必要的。

Ÿ   完全不考虑可增容性是不对的。事情永远不会做完，系统总是在进化和改变，你需要建立一个有能力应付架构进化的组织。并且一开始就把这些期望和能力融入你的 业务中去，不要让人和组织成为你网站瘫痪的原因。不要认为系统一开始就应该是完美的，一个好的系统是在解决真正的问题和担忧中成长起来的，期待改变，适应 改变才是正确的态度。

 

YouTube网站架构

文/Todd Hoff 译/罗XP

YouTube的成长速度惊人，目前每天视频访问量已达1亿，但站点维护人员很少。他们是如何管理，以实现如此强大供应能力的？被Google收购后，又在走什么样的发展道路呢？

平台

l  Apache

l  Python

l  Linux (SuSe版本)

l  MySQL

l  psyco（python->C动态编译器）

l  lighttpd （取代Apache作为视频服务器）

统计数据

l  每天高达1亿的视频访问量。

l  创建于2005年2月。

l  2006年3月，每日视频访问量达到3千万。

l  2006年7月，每日视频访问量达到1亿。

l  2个系统管理员，2个系统扩展架构师。

l  2个产品功能开发人员，2个网络工程师，1个DBA。

性能监控手段

网站维护人员每天多次重复的工作，类似于执行下面这段代码。

while (true)

{

identify_and_fix_bottlenecks();

drink();

sleep();

notice_new_bottleneck();

}

Web服务器

l  NetScalar用于实现负载均衡和对静态内容的缓存。

l  Apache运行于mod_fast_cgi模式。

l  一台Python应用服务器专门负责Web请求的路由。

l  应用服务器与各个数据库和其他类型信息源建立会话，取得所需数据并生成HTML页面。

l  通过增加服务器，一般就可以实现对Web层的扩展。

l  Python代码的效率一般不是瓶颈所在，真正瓶颈在于RPC请求。

l  Python应用的开发和发布 快速灵活，这是他们能够应对激烈竞争的重要保证。

l  正常情况下，能将每个页面的响应时间控制在100ms以内。

l  利用psyco（python->C的动态编译器），通过JIT编译方法实现内部循环的优化。

l  在CPU高敏感的活动（如加密）中使用C扩展。

l  预生成某些HTML页面并缓存。

l  在数据库中实现行级缓存。

l  对Python结果对象缓存。

l  预先计算某些数据，并发送至对应应用，以形成本地缓存。这项策略目前还未大规模运用。不需要每个应用服务器都花很多时间将预先计算，并将结果数据发送到所有服务器。有一个代理机专门负责此项工作——监控数据的变化情况，预先计算并发送。

视频服务

l  成本，包括带宽、硬件购置和电力的消耗。

l  每段视频均通过刀片群集（mini-cluster）服务器管理，也就是说由多个机器联合提供视频内容服务。

l  刀片群集管理的优势：

n  多个磁盘提供内容服务，意味着更快的速度。

n  提供了动态余量。一台机器停止服务，其他可以接管。

n  实现了在线备份。

l  使用lighttpd作为视频的Web服务器：

n  Apache的成本太高。

n  使用epoll 同时操作多个fds（文件描述符）。

n  从单进程切换到多进程，以处理更多连接。

l  将频繁访问的内容转移到CDN （content delivery network）：

n  CDN将内容复制到多个源，因此对用户来说，获取数据时可以选择最优路径。

n  CDN服务器主要依靠内存提供服务，否则因访问频繁，可能引起抖动。

l  低访问量的内容（每天1-20的访问量），YouTube服务器以colo 模式管理。

n  长尾效应。单个视频的访问量不高，但大量视频合起来就不一样了。各磁盘块被访问到的概率是随机的。

n  在这种情况下，花费了大量投入的缓存 ，作用并不大。这个问题是当前研究的一个热点。如果你有一个长尾型的产品，请记住缓存不见得就是解决性能问题的救世主。

n  优化调整RAID 控制器，在底层策略上下功夫。

n  调整每台服务器上的内存，不要太大也不要太小。

视频服务中的几个关键点

l  整体方案力求简洁、廉价。

l  网络路径保持最短，不要在内容和终端用户间部署太多设备。路由器、交换机等可能承受不了这么高的负载。

l  尽量采用普通硬件。高档硬件的支撑设备很昂贵，实际中往往发现它们的作用并不大。

l  使用简单、通用的工具。YouTube优先考虑Linux自带的大多数工具。

l  正确处理随机寻道问题（采用SATA、优化调整等）。

视频截图的处理

l  实现视频截图和缩略图的高效访问，有着惊人的难度。

l  如果每视频平均4个缩略图，那么总图量是非常庞大的。

l  缩略图存储在有限几台机器上。

l  大量小型对象服务中存在的难点问题：

n   磁盘寻道频繁，操作系统级inode（译者注：Linux/Unix系统中记录文件信息的对象）缓存和页缓存多。

n  每个目录受到最大文件数限制。Ext3文件系统可管理的目录层级非常多，即便依托2.6内核将大目录处理性能提高100倍 左右，在文件系统中存储大量文件情况下，仍然不是一个值得称许的解决策略。

n  平均含60个缩略图的页面的访问量很大。

n  在如此高负载条件下，Apache的性能急剧下降。

n  使用squid（反向代理）作为Apache的前端，能起到一定作用。但随着负载的上升，性能最终会呈下降趋势——处理能力由原来的300个/s降为20个/s。

n  尝试使用lighttpd。这是一个单进程且单线程的应用，每个进程拥有独立缓存。为了提高性能，需要运行多个进程实例。如此一来，造成了资源浪费和性能限制等问题。

n  大量图片需要处理的情况下，向系统新增一台机器，需要24个小时。

n  重启机器后，系统需要花费6-10小时，来将内容从磁盘载入缓存。

l  为了解决这些问题，他们使用了Google的分布式数据存储策略——BigTable ：

n  将文件拢在一起，避免了小文件问题。

n  速度快；即使运行在不可靠网络上，其错误率也是可以容忍的。

n  未知风险小，因为它使用了分布式的多级缓存。缓存工作于colo 结构上。

数据库 [DSJ2] 

l  早期：

n  使用MySQL存储用户、标签和详细描述等原数据。

n  数据存储在挂10磁盘、10卷的单片RAID上。

n  租借硬件。负载上升，添加新设备时他们需要数天时间。

n  和其他很多系统一样，他们走过了这样一段历史：单服务器，主从服务器（单台主服务器，依靠多台从服务器实现读数据的负载均衡），数据库分割（逐渐稳定于分割模式）。

n  存在数据复制延迟的问题。主服务器是多线程的，硬件条件好，性能高；而从服务器运行于单线程模式，且硬件条件差一些。数据从主服务器到从服务器的复制是异步的，因此从服务器上的数据往往严重滞后于主服务器。

n  数据更新后，缓存将被清除，需从I/O更慢的磁盘读取，从而造成复制更为缓慢。

n  在这种以数据复制为中心的架构下，稍微提升写性能，都必须付出巨大成本。

n  他们的解决办法之一是将数据分割到两个不同群集，从而分解访问压力：一个视频池和一个普通群集。这个解决方案的出发点是：访问者最想看到的是视频，因此应该为这些功能分配最多资源；而YouTube社交功能是次重要的，因此做次优配置。

l  后来：

n  继续执行数据库分割策略。

n  按用户划分数据。

n  数据的读、写操作分离。

n  改进了缓存数据定位策略，减少I/O。

n  所需硬件减少了30%。

n  数据复制延迟降为0。

n  现在几乎能做到对数据库任意扩展。

数据中心策略

l  开始的时候使用托管机房。除非事先签订了协议，不能自行扩展硬件和网络系统。因此，他们后来选择了colo，可以完全按照自己的设计要求部署系统。

l  使用5/6个数据中心，外加CDN。视频的来源可以是任何一个数据中心，而非就近选择等模式。若访问频度很高，则移至CDN。

l  视频的访问性能依赖于带宽，而不是其他因素。对于图片，其他因素的影响就很大（例如页面平均图片数）。

l  利用BigTable将图片复制到各个数据中心。

经验教训

l  敢于坚持。 局部创新和一些有一定风险的策略，能够解决短期问题。如果一直坚持下去，就一定能找到长期解决方案。

l  确定事情的优先级。找出服务中的关键部分，优先为其配置资源、投入力量。

l  学会选择与合作。不要害怕将项目的关键部分外包。YouTube使用CDN向广大用户提供内容。如果完全依靠自己建设这样一个网络，需要花费的成本和时间都是惊人的。在你的系统中，应该可以存在这类同样的部件。

l  一切从简! 简单，将保证系统具有良好的可重构性以及对问题的快速响应。没有人真正知道怎么样才算是简单，如果在需要做出改变时，相关人员没有产生畏难情绪，就说明达到了简单的目标。

l  数据分割 。数据分割策略将实现对磁盘、CPU、内存和IO实体和指标的优化配置，改善的不仅仅是写数据的性能。

l  对瓶颈资源做持续改善：

n  软件层：数据库、缓存

n  操作系统层：磁盘I/O

n  硬件层：内存、RAID

l  团队是成功的基础。在一个有良好纪律的团队中，所有成员都能够准确把握整个系统，了解深层问题。拥有一个好的团队，将无往而不胜。

 

Facebook 详解

文/ wikipedia 译/张雷

（Facebook在Palo Alto市的总部）

（Facebook创始人兼CEO Mark Zuckerberg）

（Facebook最初的Logo）

简介

Facebook是一个社会化网络站点。它于2004年2月4日上线。

Facebook 的创始人是Mark Zuckerberg，他是哈佛大学的学生，毕业于Asdsley高中。最初，网站的注册仅限于哈佛学院（译者注：哈佛大学的本科生部）的学生。在之后的 两个月内，注册扩展到波士顿地区的其他高校（波士顿学院 Boston College、波士顿大学 Boston University、麻省理工学院 MIT、特福茨大学 Tufts）以及罗切斯特大学 Rochester、斯坦福大学Stanford、纽约大学 NYU、西北大学和所有的常春藤名校。第二年，很多其他学校也加入进来。最终，在全球范围内只要有一个大学后缀电子邮箱的人（如 .edu，.ac.uk等）都可以注册。之后，在Facebook中也可以建立起高中和公司的社会化网络。从2006年9月11日起，任何用户输入有效电 子邮件地址和自己的年龄段，即可加入。用户可以选择加入一个或多个网络，比如中学的、公司的或地区的。

据2007年 7月数据，Facebook在所有以服务于大学生为主要业务的网站中，拥有最多的用户——三千四百万活跃用户（包括在非大学网络中的用户）。从2006年 9月到2007年9月间，该网站在全美网站中的排名由第60名上升至第7名。同时Facebook也是美国排名第一的照片分享站点，每天上载八百五十万张 照片。这甚至超过其他专门的照片分享站点，如Flickr。

网站的名字Facebook来自传统的纸质“花名册”。通常美国的大学和预科学校把这种印有学校社区所有成员的“花名册”发放给新来的学生和教职员工，帮助大家认识学校的其他成员。

运营状况

网站对用户是 免费的，其收入来自广告。广告包括横幅广告和由商家赞助的小组（2006年4月，有消息称Facebook每周的收入超过一百五十万美元）。用户建立自己 的档案页，其中包括照片和个人兴趣；用户之间可以进行公开或私下留言；用户还可以加入其他朋友的小组。用户详细的个人信息只有同一个社交网络（如学校或公 司）的用户或被认证了的朋友才可以查看。据TechCrunch（译者：硅谷最著名的IT新闻博客）报道，“在Facebook覆盖的所有学校中，85% 的学生有Facebook档案；（所有这些加入Facebook的学生中）60%每天都登陆Facebook，85%至少每周登陆一次，93%至少每个月 一次。”据Facebooke 发言人Chris Hughes说，“用户平均每天在Facebook上花19分钟。”据新泽西州一家专门进行大学市场调研的公司“学生监听”在2006年进行的调查显 示，Facebook在“本科生认为最in的事”中排名第二，仅次于苹果的iPod，和啤酒与性并列。

起步

Mark Zuckerberg在Andrew McCollum和Eduardo Saverin的支持下，于2004年2月创办了“The Facebook”。当时他是哈佛大学的学生。月底的时候，半数以上的哈佛本科生已经成了注册用户。同时，Dustin Moskovitz和Chris Hughes也加入进来，帮助推广网站，将Facebook扩展到麻省理工学院、波士顿大学和波士顿学院。扩展一直持续到2004年4月，包括了所有长春 藤院校和其他一些学校。之后的一个月，Zuckerberg，McCollum和Moskovitz搬到加利福尼亚州的Palo Alto市（译者：斯坦福大学所在地，硅谷的发源地），在Adam D'Angelo和Sean Parker（译者：著名的第一代P2P音乐分享网站Napster的创始人）的帮助下继续Facebook的发展。同年9月，另一个社会化网络站点 ConnectU的合伙人Divya Narendra，Cameron Winklevoss和Tyler Winlevoss把Facebook告上法庭。他们称Zuckerberg非法使用了他们在让他帮助建站时开发的源代码。与此同时，Facebook获 得了PayPal创始人Peter Thiel提供的约五十万美金的天使投资。到12月时，Facebook的用户数超过100万。

2005

2005年5 月，Facebook获得Accel Partners的一千两百七十万美元风险投资。2005年8月23日，Facebook从AboutFace公司手中以20万美元购得 facebook.com域名，从此从名字中把The去掉了。网站当时进行了重大改进。据Zuckerberg称，目的是提高用户档案页面的用户友好性。 这个月，McCollum回哈佛大学继续进修，同时仍旧以顾问的身份为Facebook工作，并在暑假来公司工作。Hughes则继续在剑桥市（译者：哈 佛大学所在地）履行他公司发言人的职责。2005年9月2日，Zuckerberg推出了Facebook高中版，并称这是最合乎逻辑的下一步。最 初，Facebook高中版虽然被定位为需要邀请才能加入的社区，但是仅15天以后大部分高中的网络不需要密码也可以加入了（虽然Facebook账户还 是需要的）。到10月份，Facebook已经扩展到大部分美国和加拿大的规模更小的大学和学院。除此之外，还扩展到英国的21所大学、墨西哥的 ITESM、波多黎各大学以及维京群岛大学。2005年12月11日，澳大利亚和新西兰的大学也加入了Facebook。至此，Facebook中共有超 过2000所大学和高中。

2006

2006年2 月27日，应用户要求，Facebook允许大学生把高中生加为他们的朋友。约一个月后，2006年3月28日，《新闻周刊》报道Facebook可能被 收购，谈判正在进行中。据报道，Facebook拒绝了一个七亿五千万美金的收购条件，甚至有传闻收购价格达到了20亿美金。同年四月，Peter Thiel、Greylock Partners和Meritech Capital Partners额外投资了两千五百万美元。5月，Facebook扩展到印度的印度理工学院和印度管理学院。6月，Facebook状告 Quizsender.com抄袭其设计风格，要求赔偿十万美元。7月25日，Facebook增加了更多提高收入机会的功能。在同苹果iTunes合作 的推广活动中，加入“苹果学生小组”的用户可以在9月10日之前每周下载25首单曲。这个推广活动的目的是让学生们在秋季学期开学前对苹果和 Facebook的服务都更熟悉和喜爱。8月，Facebook又加入了德国的大学和以色列的高中。8月22日，Facebook推出Facebook记 事本功能——一个可以添加标签、嵌入图片和评论的博客服务。同时用户可以从其他博客服务中导入。2006年9月11日，Facebook对所有互联网用户 开放，这引起了很多现有用户的抗议。但两周后，Facebook注册仍旧对所有拥有有效电子邮件地址的人开放。

2007

2007年5 月10日，Facebook宣布了一个提供免费分类广告的计划，直接和其他分类广告站点，如Craigslist竞争。这个被称为“Facebook市 场”的功能于2007年5月14日上线。2007年5月24日，Facebook推出应用编程接口（API）。通过这个API，第三方软件开发者可以开发 在Facebook网站运行的应用程序。这被称为Facebook开放平台（Facebook Platform）。同年6月，和iTunes的合作继续为用户提供免费音乐单曲下载。7月，Facebook完成了第一次对其他公司的收购，从 Blake Ross和Joe Hewitt手中收购了Parakey（译者：Ross和Hewitt是火狐浏览器的作者，Parakey是一个被称为网络操作系统的平台）。7月24 日，Facebook聘用YouTube的前CFO Gideon Yu为CFO，替换了Michael Sheridan。8月，Facebook成为新闻周刊的封面故事。

2007年9月25日，微软宣布他们可能会