<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>旁门左道 &#187; 架构</title>
	<atom:link href="http://log.medcl.net/item/category/%e6%9e%b6%e6%9e%84/feed/" rel="self" type="application/rss+xml" />
	<link>http://log.medcl.net</link>
	<description>记录生活</description>
	<lastBuildDate>Wed, 08 Feb 2012 02:51:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
		<item>
		<title>[转] 揭秘全球最大网站Facebook背后的那些软件</title>
		<link>http://log.medcl.net/item/2010/07/change-jiemi-behind-the-worldu002639s-largest-web-site-facebook-that-software/</link>
		<comments>http://log.medcl.net/item/2010/07/change-jiemi-behind-the-worldu002639s-largest-web-site-facebook-that-software/#comments</comments>
		<pubDate>Thu, 22 Jul 2010 04:37:31 +0000</pubDate>
		<dc:creator>medcl</dc:creator>
				<category><![CDATA[未分类]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[Facebook]]></category>

		<guid isPermaLink="false">http://log.medcl.net/?p=508</guid>
		<description><![CDATA[2010年6月，Google公布全球Top 1000网站。Facebook独占鳌头。   以Facebook现在的经营规模，诸多传统服务器的技术均将崩溃或根本无法支撑。那么面对5亿的活跃用户，Facebook的工程师们又将如何让网站平 稳运转呢？伯乐在线 - 职场博客的这篇文章将展示Facebook的工程师完成这个艰巨任务所用到的一系列软件。 Facebook级别规模的挑战 在我们深入细节之前，先了解一组Facebook不得不面对数据，你就可以想象这种规模。 1.Facebook每月的PV量：630，000，000，000 （6万3千亿） 2.Facebook上的图片数量超过其他图片网站的总和（包括诸如Flickr这样的图片网站） 3.每个月有超过30亿的图片上传到Facebook 4.Facebook系统每秒可以处理120万张图片。这还不包括Facebook的CDN处理的图片。 5.每月处理超过250亿的信息内容（包括用户状态更新，评论等） 6.Facebook的服务器数量超过3万台（此数据为2009年的数据） Facebook所用的软件 从某些方面来说，Facebook还是属于LAMP类型网站，但是，为了配合其他大量的组件和服务，Facebook对已有的方法，已经做了必要的改变、拓展和修改。 比如： 1.Facebook依然使用PHP，但Facebook已重建新的编译器，以满足在其Web服务器上加载本地代码，从而提升性能； 2.Facebook使用Linux系统，但为了自身目的，也已做了必要的优化。（尤其是在网络吞吐量方面）； 3.Facebook使用MySQL，但也对其做优化。 还有定制的系统，比如， Haystack -- 高度可扩展的对象存储，用来处理Facebook的庞大的图片；Scribe -- Facebook的日志系统。 下面展现给大家的是，全球最大的社交网站Facebook所使用到的软件。 Memcached   Memcached是一款相当有名的软件。它是分布式内存缓存系统。Facebook（还有大量的网站）用它作为Web服务器和MySQL服务器之间的缓存层。经过多年，Facebook已在Memcached和其相关软件（比如，网络栈）上做了大量优化工作。 Facebook运行着成千上万的Memcached服务器，借以及时处理TB级的缓存数据。可以这样说，Facebook拥有全球最大的Memcached设备。 HipHop for PHP   和运行在本地服务器上代码相比，PHP的运行速度相对较慢。HipHop把PHP代码转换成C++代码，提高编译时的性能。因为Facebook很依赖PHP来处理信息，有了HipHop，Facebook在Web服务器方面更是如虎添翼。 HipHop诞生过程：在Facebook，一小组工程师（最初是3位）用了18个月研发而成。 Haystack   Haystack是Facebook高性能的图片存储/检索系统。（严格来说，Haystack是一对象存储，所以它不一定要存储图 片。）Haystack的工作量超大。Facebook上有超过2百亿张图片，每张图片以四种不同分辨率保存，所以，Facebook有超过8百亿张图 片。 Haystack的作用不单是处理大量的图片，它的性能才是亮点。我们在前面已提到，Facebook每秒大概处理120万张图片，这个数据并不包括其CDN处理的图片数。这可是个惊人的数据！！！ BigPipe   BigPipe是Facebook开发的动态网页处理系统。为了达到最优，Facebook用它来处理每个网页的分块（也称“Pagelets”）。 比如，聊天窗口是独立检索的，新闻源也是独立检索的。这些Pagelets是可以并发检索，性能也随之提高。如此，即使网站的某部分停用或崩溃后，用户依然可以使用。 Cassandra   Cassandra是一个没有单点故障的分布式存储系统。它是前NoSQL运动的成员之一，现已开源（已加入Apache工程）。Facebook用它来做邮箱搜索。 除了Facebook之外，Cassandra也适用于很多其他服务，比如Digg。 Scribe   [...]]]></description>
		<wfw:commentRss>http://log.medcl.net/item/2010/07/change-jiemi-behind-the-worldu002639s-largest-web-site-facebook-that-software/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>RESTful.NET</title>
		<link>http://log.medcl.net/item/2010/06/restful-net/</link>
		<comments>http://log.medcl.net/item/2010/06/restful-net/#comments</comments>
		<pubDate>Sat, 05 Jun 2010 11:46:05 +0000</pubDate>
		<dc:creator>medcl</dc:creator>
				<category><![CDATA[.NET]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[RESTful]]></category>
		<category><![CDATA[分享]]></category>

		<guid isPermaLink="false">http://log.medcl.net/item/2010/06/restful-net/</guid>
		<description><![CDATA[Restful View more presentations from medcl. 相关源文件：RESTful Tags: RESTful, 分享]]></description>
		<wfw:commentRss>http://log.medcl.net/item/2010/06/restful-net/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The Google File System中文版</title>
		<link>http://log.medcl.net/item/2010/06/the-google-file-system-english-version/</link>
		<comments>http://log.medcl.net/item/2010/06/the-google-file-system-english-version/#comments</comments>
		<pubDate>Wed, 02 Jun 2010 05:09:51 +0000</pubDate>
		<dc:creator>medcl</dc:creator>
				<category><![CDATA[云里雾里]]></category>
		<category><![CDATA[分布式]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[gfs]]></category>
		<category><![CDATA[google]]></category>

		<guid isPermaLink="false">http://log.medcl.net/?p=552</guid>
		<description><![CDATA[译者：alex 摘要 我们设计并实现了Google GFS文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。   虽然GFS的设计目标与许多传统的分布式文件系统有很多相同之处，但是，我们的设计还是以我们对自己的应用的负载情况和技术环境的分析为基础的，不管现在还是将来，GFS和早期的分布式文件系统的设想都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。   GFS完全满足了我们对存储的需求。GFS作为存储平台已经被广泛的部署在Google内部，存储我们的服务产生和处理的数据，同时还用于那些需要大规模数据集的研究和开发工作。目前为止，最大的一个集群利用数千台机器的数千个硬盘，提供了数百TB的存储空间，同时为数百个客户机服务。   在本论文中，我们展示了能够支持分布式应用的文件系统接口的扩展，讨论我们设计的许多方面，最后列出了小规模性能测试以及真实生产系统中性能相关数据。   分类和主题描述 D [4]: 3—D分布文件系统 常用术语 设计，可靠性，性能，测量 关键词 容错，可伸缩性，数据存储，集群存储 1. 简介 为了满足Google迅速增长的数据处理需求，我们设计并实现了Google文件系统(Google File System – GFS)。GFS与传统的分布式文件系统有着很多相同的设计目标，比如，性能、可伸缩性、可靠性以及可用性。但是，我们的设计还基于我们对我们自己的应用的负载情况和技术环境的观察的影响，不管现在还是将来，GFS和早期文件系统的假设都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。   首先，组件失效被认为是常态事件，而不是意外事件。GFS包括几百甚至几千台普通的廉价设备组装的存储机器，同时被相当数量的客户机访问。GFS组件的数量和质量导致在事实上，任何给定时间内都有可能发生某些组件无法工作，某些组件无法从它们目前的失效状态中恢复。我们遇到过各种各样的问题，比如应用程序bug、操作系统的bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效等造成的问题。所以，持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在GFS中。   其次，以通常的标准衡量，我们的文件非常巨大。数GB的文件非常普遍。每个文件通常都包含许多应用程序对象，比如web文档。当我们经常需要处理快速增长的、并且由数亿个对象构成的、数以TB的数据集时，采用管理数亿个KB大小的小文件的方式是非常不明智的，尽管有些文件系统支持这样的管理方式。因此，设计的假设条件和参数，比如I/O操作和Block的尺寸都需要重新考虑。   第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。对文件的随机写入操作在实际中几乎不存在。一旦写完之后，对文件的操作就只有读，而且通常是按顺序读。大量的数据符合这些特性，比如：数据分析程序扫描的超大的数据集；正在运行的应用程序生成的连续的数据流；存档的数据；由一台机器生成、另外一台机器处理的中间数据，这些中间数据的处理可能是同时进行的、也可能是后续才处理的。对于这种针对海量文件的访问模式，客户端对数据块缓存是没有意义的，数据的追加操作是性能优化和原子性保证的主要考量因素。   第四，应用程序和文件系统API的协同设计提高了整个系统的灵活性。比如，我们放松了对GFS一致性模型的要求，这样就减轻了文件系统对应用程序的苛刻要求，大大简化了GFS的设计。我们引入了原子性的记录追加操作，从而保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性。本文后面还有对这些问题的细节的详细讨论。   Google已经针对不同的应用部署了多套GFS集群。最大的一个集群拥有超过1000个存储节点，超过300TB的硬盘空间，被不同机器上的数百个客户端连续不断的频繁访问。  2.设计概述 2.1设计预期 在设计满足我们需求的文件系统时候，我们的设计目标既有机会、又有挑战。之前我们已经提到了一些需要关注的关键点，这里我们将设计的预期目标的细节展开讨论。 系统由许多廉价的普通组件组成，组件失效是一种常态。系统必须持续监控自身的状态，它必须将组件失效作为一种常态，能够迅速地侦测、冗余并恢复失效的组件。 系统存储一定数量的大文件。我们预期会有几百万文件，文件的大小通常在100MB或者以上。数个GB大小的文件也是普遍存在，并且要能够被有效的管理。系统也必须支持小文件，但是不需要针对小文件做专门的优化。 系统的工作负载主要由两种读操作组成：大规模的流式读取和小规模的随机读取。大规模的流式读取通常一次读取数百KB的数据，更常见的是一次读取1MB甚至更多的数据。来自同一个客户机的连续操作通常是读取同一个文件中连续的一个区域。小规模的随机读取通常是在文件某个随机的位置读取几个KB数据。如果应用程序对性能非常关注，通常的做法是把小规模的随机读取操作合并并排序，之后按顺序批量读取，这样就避免了在文件中前后来回的移动读取位置。 系统的工作负载还包括许多大规模的、顺序的、数据追加方式的写操作。一般情况下，每次写入的数据的大小和大规模读类似。数据一旦被写入后，文件就很少会被修改了。系统支持小规模的随机位置写入操作，但是可能效率不彰。 系统必须高效的、行为定义明确的（alex注：well-defined）实现多客户端并行追加数据到同一个文件里的语意。我们的文件通常被用于”生产者-消费者“队列，或者其它多路文件合并操作。通常会有数百个生产者，每个生产者进程运行在一台机器上，同时对一个文件进行追加操作。使用最小的同步开销来实现的原子的多路追加数据操作是必不可少的。文件可以在稍后读取，或者是消费者在追加的操作的同时读取文件。 高性能的稳定网络带宽远比低延迟重要。我们的目标程序绝大部分要求能够高速率的、大批量的处理数据，极少有程序对单一的读写操作有严格的响应时间要求。 2.2 接口 GFS提供了一套类似传统文件系统的API接口函数，虽然并不是严格按照POSIX等标准API的形式实现的。文件以分层目录的形式组织，用路径名来标识。我们支持常用的操作，如创建新文件、删除文件、打开文件、关闭文件、读和写文件。   另外，GFS提供了快照和记录追加操作。快照以很低的成本创建一个文件或者目录树的拷贝。记录追加操作允许多个客户端同时对一个文件进行数据追加操作，同时保证每个客户端的追加操作都是原子性的。这对于实现多路结果合并，以及”生产者-消费者”队列非常有用，多个客户端可以在不需要额外的同步锁定的情况下，同时对一个文件追加数据。我们发现这些类型的文件对于构建大型分布应用是非常重要的。快照和记录追加操作将在3.4和3.3节分别讨论。 2.3 架构 一个GFS集群包含一个单独的Master节点（alex注：这里的一个单独的Master节点的含义是GFS系统中只存在一个逻辑上的Master组件。后面我们还会提到Master节点复制，因此，为了理解方便，我们把Master节点视为一个逻辑上的概念，一个逻辑的Master节点包括两台物理主机，即两台Master服务器）、多台Chunk服务器，并且同时被多个客户端访问，如图1所示。所有的这些机器通常都是普通的Linux机器，运行着用户级别(user-level)的服务进程。我们可以很容易的把Chunk服务器和客户端都放在同一台机器上，前提是机器资源允许，并且我们能够接受不可靠的应用程序代码带来的稳定性降低的风险。 GFS存储的文件都被分割成固定大小的Chunk。在Chunk创建的时候，Master服务器会给每个Chunk分配一个不变的、全球唯一的64位的Chunk标识。Chunk服务器把Chunk以linux文件的形式保存在本地硬盘上，并且根据指定的Chunk标识和字节范围来读写块数据。出于可靠性的考虑，每个块都会复制到多个块服务器上。缺省情况下，我们使用3个存储复制节点，不过用户可以为不同的文件命名空间设定不同的复制级别。   [...]]]></description>
		<wfw:commentRss>http://log.medcl.net/item/2010/06/the-google-file-system-english-version/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>小议 MySpace DataRelay</title>
		<link>http://log.medcl.net/item/2010/05/the-discussion-about-myspace-datarelay/</link>
		<comments>http://log.medcl.net/item/2010/05/the-discussion-about-myspace-datarelay/#comments</comments>
		<pubDate>Thu, 20 May 2010 15:04:15 +0000</pubDate>
		<dc:creator>medcl</dc:creator>
				<category><![CDATA[.NET]]></category>
		<category><![CDATA[分布式]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[资源分享]]></category>
		<category><![CDATA[BerkeleyDB]]></category>
		<category><![CDATA[DataRelay]]></category>
		<category><![CDATA[KeyValue]]></category>
		<category><![CDATA[MySpace]]></category>
		<category><![CDATA[nosql]]></category>

		<guid isPermaLink="false">http://log.medcl.net/?p=444</guid>
		<description><![CDATA[最近看MySpace的DataRelay代码，有点抓狂（无文档、注释极少、缺少用例），DataRelay是MySpace开源的一个中间层框架，核心是一个支持插件的消息系统，内部使用了微软的CCR（Concurrency and Coordination Runtime，a component originally released as part of the Microsoft Robotic Studio）来作为消息的分发，包括3个核心组件： Forwarder - This handles the actual moving of messages, both from client to server and between servers ，实现消息的不同服务器节点以及客户端之间的数据分发传递. BerkeleyDB - This handles storing data, and is the component used for basic key/value caching,Oracle的KeyValue数据库，查询效率高，数据能够持久化到硬盘，支持多个节点来实现分布式缓存. Index Cache - This is a two tiered [...]]]></description>
		<wfw:commentRss>http://log.medcl.net/item/2010/05/the-discussion-about-myspace-datarelay/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>豆瓣技术架构的发展历程 @ QCon Beijing 2009</title>
		<link>http://log.medcl.net/item/2010/05/watercress-technical-architecture-development-process-qcon-beijing-2009/</link>
		<comments>http://log.medcl.net/item/2010/05/watercress-technical-architecture-development-process-qcon-beijing-2009/#comments</comments>
		<pubDate>Wed, 19 May 2010 05:06:10 +0000</pubDate>
		<dc:creator>medcl</dc:creator>
				<category><![CDATA[云里雾里]]></category>
		<category><![CDATA[分布式]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[QCon]]></category>
		<category><![CDATA[豆瓣]]></category>

		<guid isPermaLink="false">http://log.medcl.net/?p=443</guid>
		<description><![CDATA[转，学习 豆瓣技术架构的发展历程 @ QCon Beijing 2009 View more presentations from hongqn. 现场视频：InfoQ: 豆瓣网技术架构变迁 Tags: QCon, 架构, 豆瓣]]></description>
		<wfw:commentRss>http://log.medcl.net/item/2010/05/watercress-technical-architecture-development-process-qcon-beijing-2009/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Force.com的多租户架构 [转]</title>
		<link>http://log.medcl.net/item/2010/05/multi-tenant-force-com-structure-change/</link>
		<comments>http://log.medcl.net/item/2010/05/multi-tenant-force-com-structure-change/#comments</comments>
		<pubDate>Wed, 19 May 2010 04:53:03 +0000</pubDate>
		<dc:creator>medcl</dc:creator>
				<category><![CDATA[云里雾里]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[Architecture]]></category>
		<category><![CDATA[Force.com]]></category>
		<category><![CDATA[saas]]></category>
		<category><![CDATA[多租户]]></category>

		<guid isPermaLink="false">http://log.medcl.net/?p=436</guid>
		<description><![CDATA[由于Force.com所负载的应用不论是在定制方面的灵活性上，还是所承受的负载上，对基于多租户的架构而言，都是史无前例的，导致之前提到的一些模型或者改动已经无法满足要求了，所以Salesforce在Force.com引入了通过Metadata（元数据）驱动的多租户架构来动态生成快速的，可伸缩的和可定制的应用。接下来，将一步步为大家揭开Force.com多租户架构的神秘面纱，首先是它的总体架构。   总体架构 在介绍Force.com的整个架构之前，请看下图，此图是根据Salesforce首席架构师Craig Weissman在2009年旧金山QCon大会上的演讲总结而成。   图1. Force.com的架构图 首先，在最前面是Gateway（网关），网关将接受所有访问Force.com的请求，无论它是访问Sales Cloud，还是关于第三方定制程序的。接下来，网关会根据这个请求所属的租户把请求转发给对应的POD，什么是POD？简单的来说，POD就是一组集群服务器，每个POD都运行同一套Force.com系统，而且每个POD支持成千上万个租户，Salesforce总共有10多个POD来支撑它所有服务的运营，并把所有租户平衡地分配给每个POD，而且主要通过建立新的POD来支撑新的租户。当POD收到请求之后，POD会先通过其内置的Load Balancer（负载均衡器）来将请求转发给负载略轻的App Server（应用服务器），由于为了简化架构和方便伸缩（Scale），所以应用服务器是Stateless（无状态），而且在一个POD内会有多个应用服务器以应对大规模的请求。最后，当应用服务器在处理请求的时候，如果发现请求所需的数据没有被Cache住的话，应用服务器会调用这个租户所属的Shared DB（共享数据库）来取得相关数据，虽然共享数据库是使用成熟的Oracle数据库产品，但是在数据库表的设计上面为多租户做了很多地优化。 接下来，将介绍Force.com是如何通过Metadata来动态生成和定制应用的。   Metadata驱动 首先，Force.com的Metadata是基于大家非常熟悉的面向对象的概念，所以也可以把Metadata认为是对象，也就是说Force.com是由一个个对象组装而成，而且Force.com中的对象可以是表格，也可以是UI，甚至可以是用户权益等。一个Force.com的对象和这个对象下面的字段可以对应一个数据库的表和这个表的列，而且Force.com对象之间的关系（relationship）在功能上类似于数据库的引用完整性約束（referential integrity constraint），但与数据库中每个数据库表对应于独立的存储地址不同的是，Force.com使用几个共享的大数据库表来作为堆存储（heap storage）来放置所有对象，另外这些存储Metadata的表也被称为“UDD（Universal Data Dictionary）”。 接着，是关于应用的，一个在Force.com上运行的应用实例是通过组合许许多多个对象来生成的，也可以说一个应用实例是使用Metadata来描述的，比如，在应用初始的时候，每个客户都是使用同一个版本和同样规模的对象，而且用户通过添加和更新对象来定制应用，比如增加新的UI和字段等，同时系统会对共享的和定制的对象进行严格地分离，使得既能非常方便地更新共享代码，也能保证某个用户定制过的部分不影响到其他用户。在实现上，Force.com并没有实际地为一个新对象生成一个数据库表，而且以元数据的形式存储在几张大表中，并在运行时候，Force.com会有一套引擎来通过分析数据库中的Metadata来动态生成一个虚拟应用实例和这个应用所需的模块（Virtual Application Componets），比如公共UI（Common Application Screen），定制UI（Tenant-Specific Screen）和其他对象等。 图2. 虚拟应用模块图（源自参[1]） 还有，虽然Metadata驱动这种和Java很类似的动态生成机制在速度上有天生缺陷，但是Force.com也内置与Sun的Hotspot技术有异曲同工之妙的Metadata Cache来加速常用Metadata的读取。 下面，将分别介绍Force.com的两大组成部分：应用服务器和共享数据库。   应用服务器 应用服务器主要包括五大核心模块：   Metadata Cache：用于存放那些最近用到的和比较常用的Metadata来加速应用的生成。 大规模数据处理引擎：主要用来加速处理大量的数据读写和在线事务。 多租户感知的查询优化引擎：这个引擎将通过维护多租户的信息来帮助Oracle自带的基于成本的查询优化器更好地适应多租户环境。 运行时应用生成器：这个生成器主要根据用户的请求来动态生成应用，并且利用上面提到的查询优化引擎来提升效率。 全文检索引擎：在数据库对数据进行更新的同时，这个引擎会异步更新这个数据的相关索引。     共享数据库 图1. Force.com的架构（图源自参[1]） 整个共享数据库主要有三种类型的数据库表：   Metadata表：主要存放用户定制的对象和对象所包含的字段的结构信息，也被称为“UDD”。 数据表：主要存储那些用户定制的对象和对象所包含的字段的数据。 Pivot表：用来维护那些用于检索（indexing），唯一性和关系等denormalized （去规范化）数据以优化系统的效率。   [...]]]></description>
		<wfw:commentRss>http://log.medcl.net/item/2010/05/multi-tenant-force-com-structure-change/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

