英文站推广运营模式 1写在前面写给个人站长的，英文站推广运营模式。英文站是一个公认的秘密金矿，很多人去挖了，获得了丰厚的回报。还有很多人想去挖，却又不知道该如何动手，一直没有行动，那么这里值得犹豫不前不知如何下手的你看看。2整体内容2.1内容意见如何谋划构思一个站点，无论是什么语言什么类型的站点都是很重要的。2.1.1做什么内容这个问题是个最不是问题的问题。大家都是地球人，兴趣爱好都是一样的，只是语言不同。英文站你找不到内容做那中文站你肯定也一样找不到内容做。保留这一条的思维，拿中文站的内容举一反三。2.1.2百度与google百度很懂中文，其实也很懂英文。top.baidu.com和index.baidu.com肯定已经是你必去之地（如果还没有，你可能需要吃点钙片了）再推荐一个dict.baidu.com这三个二级域名，就是百度给我们的进攻英文站的有力后盾。google一直是老大热榜也有一定参考www.google.cn/rebang/home英语八级也得用的translate.google.com2.1.3内容重要参考站点关键词：论坛，虽然人气都很低迷，但是资料里也难免不暴露站点（点用户的签名看他们的站吧）美国的空间商有很多都提供了论坛支持，美国最大IDC的官方客服论坛lunarforum.com当然，如果有这心思，当然不能放过webmasterworld.com.2.1.4内容从哪里来有前途的内容要有前途的人才能找到。辛辛苦苦找到的一个好关键词，千万要记得守护好它。最好的办法就是匀速增加原创内容。内容如何原创，自己写，拼凑单词，节选别人修改，自动翻译填充的都可以，但是千万不要ctr+v。2.2程序选择很多人都在英文站程序的问题的犹豫着。其实程序选择的问题不是一个问题。自己熟练的才是最好的。2.2.1体验建站程序自己在本机搭建好环境，把主流的CMS或blog程序都在本地调试一次，有个选择，有个概念，有个底。即使是打算自己做程序也推荐体验一下。几个常用国外程序：Drupal  Joomla! Moodle Nucleus WordPress Geeklog pLog Serendipity （去下载站搜索软件寻找对比观察）2.2.2关于国产CMS对于对国产cms使用烂熟或对英语一窍不通的朋友，其实国产的CMS也不失为一个好选择。同样uft-8编码同样生成html，所有的程序不过是完成这一步，仅仅是后台操作的不同。html既然都一样生成，那么内容和优化才是重点。2.3空间建议稳定的空间，独立的IP是必要也是必须的。2.3.1空间哪里来代购，或自己直接兑换palpay在网站上直接买，非常简单，国外空间很容易购买，只是使用稍麻烦点，但一般也没有问题。lunarpages，godaddy什么的，百度一搜很多，落伍也有人专门代购。优惠码是个好东西，互利互惠。2.3.2独立IP一般来说国外空间相比国内很夸张，组件支持完备在线率又高。但是会有GFW的危险，所以独立IP是很必须的。当然如果独立IP也被GFW了就有必要研究一下你的内容了。2.3.3域名一般空间会送，与空间结合使用良好。优先使用国外的域名。域名优先使用常见单词，各方面都有优势。然后这点省略跳过。2.4推广维护一路走来，做出一个站来说对于现在的网络环境来说简直是不废吹灰之力，但是推广和维护一直是所有网站的一个很大的大问题。2.4.1不能忘记的步骤提交搜索引擎，越多越好，这是合法的推广。每个站只提交一次，然后忘记它，值得关心的只有google和yahoo。google网站管理员，提交sitemap，刚开始的更新时间标记以越慢越好。2.4.2行不通的推广套路群发邮件。但是可以点发邮件，如前面重要参考站点上获得的email地址可以发送询问技术和内容参考的新手问题，热心人总会为你奉献几个真实的国外IP和PV，设置还有可能获得不错的改良意见。（这招是我的必杀计都给奉献了）垃圾链接。但是可以抽点评论回复博客之类可以留链接的地方。核心思想跟上一条是一样的，还可以自由发散。2.4.3友情链接首先注意，提防和自己人交换友情链接，互相祸害。和自己的站交换就更别去碰了。和老外交换，勤快的发送你的email，表示你的诚意，一般情况下的老外小站都很好交换链接。控制你的链接数量，我的参考办法是1点PR=5个链接。比如你的PR1，那外链请少于5个，2是10，依此类推。2.4.4英文站在中文搜索里不要刻意去做链接。当然，高PR站的外链当然多多益善。单向过去的链接是个不错的提高PR的办法（高PR的意义在于更容易与高PR的老外站换链接）2.5提醒注意2.5.1不作弊才是王道。2.5.2没有流量没关系，只要你觉得确实自己是有货的，请坚持下去。2.5.3勤快的更新，一天一百篇不如连续十天每天一篇。2.5.4不要轻易尝试自动采集，即使你的采集器很完美。2.5.5永远不要把你的英文站亮出来。2.5.6中文站可以高调，但英文站只能低调。3最后总结英文站是一个公认的秘密金矿，很多人去挖了，获得了丰厚的回报。但也还有很多人去挖了，但是却毫无收获。英文是一个公认的秘密金矿，却不是每一个人的秘密金矿。

网站架构方案应包括哪些方面 网站架构方案应包括如下几个方面：网络管理系统：包括网络结构、服务器架构与有关硬件设备部署的整合设计。应用管理系统：包括web服务、数据库服务、应用服务、邮件服务的整合设计；业务管理系统：包括网站内容管理、社区论坛、资源管理、视频点播、短信娱乐、广告管理等业务内容的整合设计；网络安全系统：包括数据存储备份恢复、系统监控、流量分析、应用审计等网络安全的整合设计；文档目录可以划分为：一、概　　述 5二、需求分析 52.1 异构系统 62.2 异构应用 82.3 异构数据 82.4 网站结构 92.5 内容海量 102.6 内容深度 102.7 服务深度 102.8 发布系统 112.9 网络安全 112.10 信息安全 11三、方案整体规划 113．1设计目标 113．2实施规划 12四、网络解决方案 134.1 拓扑结构图 144.2 硬件选型、分布与规划 144.2.1 数据库服务器 144.2.2 web发布服务器 154.2.3 cgi服务器 154.2.4 内容管理发布服务器 154.2.5 内容管理生成服务器 154.2.6 数据存储设备 154.2.7 安全设备 164.2.8 防病毒 164.2.9 原有服务器与置换服务器比较 164.3 新增硬件配置清单 18五、软件解决方案 185.1系统架构 185.2系统软件整合 195.3 网站内容管理系统 205.3.1网站内容管理系统介绍 205.3.2网站后台管理系统 215.3.3网站采编应用系统 225.3.4网站调查投票子系统 255.3.5站点内容全文检索子系统 265.3.6文章评论系统 265.3.7网站论坛、聊天室子系统 265.3.8网站会员认证管理子系统 315.3.9网站广告发布子系统 32六、网站音视频管理系统 326.1用户需求分析 326.2 产品概述 336.3技术特点 336.4基础构架和运行环境 346.5 功能描述 344.3.6 拓扑结构图 394.3.7音视频系统组成 39七、项目实施进度安排 427.1项目领导小组 427.2 项目实施小组 427.3质量监督小组 437.4系统集成实施进度计划及工作日程表 43八、培训、支持和服务 448.1 培训服务 448.1.1 基本操作培训 448.1.2 系统管理培训 448.1.3 培训安排 458.1.4 培训内容 458.2 技术支持服务 458.2.1 硬件平台技术支持 458.2.2 应用软件平台技术支持 458.3 售后服务 46九、小结 46附录 47硬件产品说明 47hp dl 580 47hp dl 380 49

网站架构设计原则-小规模低性能低流量 到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。拥抱熟知的技术动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。架构层次清晰化起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。Web Server <–> (AppServer)<–>Cache(eg. Memcached)<–>DB层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。数据冗余? 有必要很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。前端优化很重要因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。功能增加要谨慎不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。从开始考虑性能这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。好架构不是设计出来的这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：发展–>发现问题–>反馈–>解决问题(执行力)–> 改进->进化到下一阶段–新问题出现(循环)有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。作者: Fenng 网址: http://www.dbanotes.net/arch/small_site_arch.html

Apache的HTTP压缩GZIP优化配置 HTTP压缩对于纯文本内容可压缩至原大小的40％一下，从而提供60％以上的数据传输节约，虽然WEB服务器会因为压缩导致CPU占用的略微上升，但是 可以节约大量用于传输的网络IO。对于数据压缩带来的用户浏览速度提升（让页面符合8秒定律），这点总体负载5%-10%上升是非常值得的。毕竟通过数据 压缩会比通过不规范的HTML代码优化要方便得多。mod_gzip的安装：修改Makefile中的 apxs路径：然后make make install配置：mod_gzip+mod_phpLoadModule gzip_module modules/mod_gzip.so…AddModule mod_gzip.c…<IfModule mod_gzip.c>mod_gzip_on Yesmod_gzip_minimum_file_size 1000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.htm$mod_gzip_item_include file \.html$mod_gzip_item_include file \.php$mod_gzip_item_include file \.php3$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directory# mod_gzip的临时工作目录: mkdir /tmp/mod_gzip; chmod -R 777 mod_gzipmod_gzip_temp_dir /tmp/mod_gzipmod_gzip_dechunk Yesmod_gzip_keep_workfiles No</IfModule> mod_gzip和mod_php的配合：不要让mod_gzip和mod_php使用同一个临时目录，php_session存放目录可以通过 php.ini设置到session.save_path = /tmp/php_sessmod_gzip和Resin配合：从resin的邮件列表上查到的：要让mod_gzip在mod_caucho后加载，否则mod_gzip不起作用…othr modulesAddModule mod_so.cAddModule mod_caucho.c#notice: mod_gzip must load after mod_cauchoAddModule mod_gzip.cAddModule mod_expires.c…配置：mod_gzip + resin<IFModule mod_gzip.c>mod_gzip_on Yesmod_gzip_dechunk yesmod_gzip_keep_workfiles Nomod_gzip_minimum_file_size 3000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.html$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directorymod_gzip_item_include handler caucho-request</IFModule>配置：mod_gzip + mod_proxy 反相代理加速并压缩 IIS注意要增加缺省的文件编码属性映射。AddType text/html .aspAddType text/html .aspx<IFModule mod_gzip.c>AddType text/html .aspAddType text/html .aspxmod_gzip_on Yesmod_gzip_dechunk yesmod_gzip_keep_workfiles Nomod_gzip_minimum_file_size 3000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.html$mod_gzip_item_include file \.asp$mod_gzip_item_include file \.aspx$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directorymod_gzip_item_include handler proxy-server</IFModule>参考资料：mod_gzip的下载http://sourceforge.net/projects/mod-gzip/mod_gzip项目首页http://www.schroepl.net/projekte/mod_gzip/Apache2 中的mod_deflate：压缩率比mod_gzip略低http://httpd.apache.org/docs-2.0/mod/mod_deflate.html模块化安装Apachehttp://www.chedong.com/tech/apache_install.html作者：车东 发表于：http://www.chedong.com/tech/compress.html

.Net架构网站遇到大表的处理办法 最近做的web2.0网站本身遇到一个大表(2000万rows左右)，因为对于performance，web本身可用性的考虑，必须想办法boost perf.这种情况应该都用partition来搞定了，这也符合分治等算法的思想，想办法降低问题本身的复杂度，然后在一个一个解决。mysql中一般到100万操作就有点麻烦了，index要好好的做。这里还遇到了一个文本检索问题，MyIASM storage engine里面有个full-text index，但是不知道它对于中文支持如何，而且不清楚它是怎么分词的，不大清楚后台逻辑，Mysql这种index limitation很多，很难scalable，所以基本上直接考虑用search engine那一套。直接上了lucene+solr+solrsharp.小表like还可以忽悠忽悠，大点就慢的如老牛……Partition通过了解发现解决方案倒是不少，以前做过了解过这方面知识储备。对hivedb，hscale等都没想过要尝试，发现。net在使用open source很多都不是很舒服。最开始尝试了mysql partition，一开始听起来方法这种方案很Perfect!是mysql解决horizontal partioning的很好方案，等document看完了，发现5.1版本的partion limitation太多了，只能适合某些特性的场景，例如按照用户id做split;普通那种非unique key，primary key是很难搞定的，简单方法是给表本身不添加任何主键，自己来实现主键生成机制。这样仿佛可以了，但是通过explain partitions来做下analysis，发现结果定位具体parition不好，这就很难降低IO本身的高成本了。没有通过具体测试不知道可能是 explain partition本身不准确原因还是……mysql partition还有一个很大的弊病，就是很难跨机器，当然如何能够把Mysql存储做成分布式，也还好，但是这个技术代价都上了不少档次，risk过高了，只能算是下下策了，备用好了。这些不爽的地方导致偶们直接抛弃了这种方案，直接用手工切分来搞定这种问题，我想这也是大部分这种需求的常见 solution把。手工切分本身技术还比较简单，就是要考虑表的编码，管理等多个方面，以及如何快速定位到可能的partition，这些在设计方面都应该注意了。而且对于多partitions的结果，应该使用多线程等并发，同步技术来提高perf.这里的partition还做到支持对某一个partition做进一步切分，这样切分到每一个partition块尽量表中数据在50万以下，这样加上db index，速度应该能够满足一定的需求的，手工切分本身很容易scale out，可以把表放在不同的机器上等等load balance方法来scale.回想感觉最有意思还是表编码自身的考虑有点意思，我很大程度的灵感来源于IP地址的划分，因为这个表自身增长速度会很慢，所以采用unsigned int来搞定，43亿来表示2000万还是小意思嘛。我主要是通过前缀+长度来定义表的标识。1，2，3前缀可以让给数据比较密集的表，因为它们可以支持10位，其它就用9位来表示，可能有些不再切分范围内的就让他们从0开始增长把。这里partition list本身维护可以序列化到filesystem中，每次Load class时候deserialize一下，然后就是本身partition如何快速定位就需要用点复杂点的data stuctures了。出处:IT专家网论坛

YouTube架构分析 YouTube的成长速度惊人，目前每天视频访问量已达1亿，但站点维护人员很少。他们是如何管理，以实现如此强大供应能力的？被Google收购后，又在走什么样的发展道路呢？转载一些相关的文章，参考学习一下原文: YouTube ArchitectureYouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。平台ApachePythonLinux(SuSe)MySQLpsyco，一个动态的Python到C的编译器lighttpd代替Apache做视频查看状态支持每天超过1亿的视频点击量成立于2005年2月于2006年3月达到每天3千万的视频点击量于2006年7月达到每天1亿的视频点击量2个系统管理员，2个伸缩性软件架构师2个软件开发工程师，2个网络工程师，1个DBA处理飞速增长的流量Java代码  while (true)   {     identify_and_fix_bottlenecks();     drink();     sleep();     notice_new_bottleneck();   }   while (true) { identify_and_fix_bottlenecks(); drink(); sleep(); notice_new_bottleneck(); }每天运行该循环多次Web服务器1，NetScaler用于负载均衡和静态内容缓存2，使用mod_fast_cgi运行Apache3，使用一个Python应用服务器来处理请求的路由4，应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面5，一般可以通过添加更多的机器来在Web层提高伸缩性6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC7，Python允许快速而灵活的开发和部署8，通常每个页面服务少于100毫秒的时间9，使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环10，对于像加密等密集型CPU活动，使用C扩展11，对于一些开销昂贵的块使用预先生成并缓存的html12，数据库里使用行级缓存13，缓存完整的Python对象14，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。视频服务1，花费包括带宽，硬件和能源消耗2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有3，使用一个集群意味着：-更多的硬盘来持有内容意味着更快的速度-failover。如果一台机器出故障了，另外的机器可以继续服务-在线备份4，使用lighttpd作为Web服务器来提供视频服务：-Apache开销太大-使用epoll来等待多个fds-从单进程配置转变为多进程配置来处理更多的连接5，大部分流行的内容移到CDN：-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。-调节RAID控制并注意其他低级问题-调节每台机器上的内存，不要太多也不要太少视频服务关键点1，保持简单和廉价2，保持简单网络路径，在内容和用户间不要有太多设备3，使用常用硬件，昂贵的硬件很难找到帮助文档4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具5，很好的处理随机查找(SATA，tweaks)缩略图服务1，做到高效令人惊奇的难2，每个视频大概4张缩略图，所以缩略图比视频多很多3，缩略图仅仅host在几个机器上4，持有一些小东西所遇到的问题：-OS级别的大量的硬盘查找和inode和页面缓存问题-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图-在这种高负载下Apache表现的非常糟糕-在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存-如此多的图片以致一台新机器只能接管24小时-重启机器需要6-10小时来缓存5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：-避免小文件问题，因为它将文件收集到一起-快，错误容忍-更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable还有从DBA Notes看到过的一些：一、系统主要用Python开发，用psyco提高性能看到这个我总算知道Google为什么要收购YouTube了，都喜欢用Python嘛，本 来就有缘。用Python开发的速度显然比用C/C++、 Java等高不少，这一点eBay就比较传统，用C++/Java来写，结果落得需要几百个工程师，编译一次很久。最感兴趣的是用了psyco这个东西，所说这玩意相当于Java中的JIT编译器，通常能将Python代码的执行速度提高4倍，对于算法集中的代码甚至能提高10到100倍。二、使用lighttpd给视频内容本身提供服务时用了lighttpd，不能Apache，据说性能提高不少，但有了说这个还不好，应该用nginx，俄罗斯人写的一玩意。三、最流行的内容自己不管，放在CDN上YouTube很会享受，最常访问的内容自己的系统不管，放在运营商和Google（估计是被Google收购之后吧？）的内容分发网络上。他们自己的服务器只要处理一些不常访问的漏网之鱼就可以了，负载大大减轻。四、缩略图是最大的问题，自己搞不定，最后用Google的BigTable搞定俗话说人小鬼大绝对是有道理的，那么大的视频没什么问题，小小的缩略图却是个大问题。原来YouTube的开发人员用lighttpd，发现效果不太好，就改了代码，但效果还是不行。最后被Google收购后用了BigTable才算搞定这个问题。五、MySQL swap问题，把swap关掉就行了YouTube用MySQL存元数据，结果在Linux上swap颠簸很厉害，解决的方法也简单，把swap关掉就好了。而且人家胆子大，服务还在那里跑，这边就把它关了。六、MySQLYouTube 用MySQL也是摸着石头过河，一开始只用一个主服务器和replication，显然过一阵子这个方法就不行了。后面他们尝试把视频和非视频业务分开处 理，但这个方法也顶不了多久。最终还是走到数据分区这条正道上来。对数据库服务器的磁盘系统的选择也很有意思，最早是用10块盘做RAID 1+0，但发现盘太多了也使不上劲，所以后来改后一堆RAID 1。

Facebook开源源代码下载 Facebook开源源代码下载   Facebook Open PlatformFacebook Open Platform is a snapshot of the infrastructure that runs Facebook Platform. It includes the API infrastructure, the FBML parser, the FQL parser, and FBJS, as well as implementations of many common methods and tags.Facebook的开放平台是一个快照的基础设施运行的Facebook的平台。它包括空气污染指数的基础设施， FBML分析器，分析器的FQL ，并FBJS ，以及实现许多共同的方法和标签。下载地址：http://developers.facebook.com/fbopen/download_fbopen.phpYou can also get the latest source code from the public svn repository.Release NotesBefore you begin, please download and read the full release notes.This release includes the API infrastructure, the FQL parser, the FBML parser, and FBJS, as well as implementations of many common methods and tags. We’ve included samples and some dummy data to help you get started fast.Facebook Open Platform also has extensibility points built in so you can add your own functionality, such as your own FBML tags, API methods, etc.A list of recommended operating systems and compilers for this installation process is on the Facebook Developers Wiki.If you find a bug, please submit it to the Facebook Open Platform product category at http://bugs.developers.facebook.com/We encourage you to give us feedback and to share your thoughts with other developers in the Facebook Platform Developer Forum at http://forum.developers.facebook.comHow Is This Licensed?Facebook Open Platform (except for the FBML parser) is licensed under a Common Public Attribution License (CPAL), which follows the Mozilla Public License (MPL) with two additions:1. That you include attribution to Facebook on any modifications.2. That network deployment, or making modifications available over the network, counts as distribution, which makes the license appropriate for Web services.You can find the CPAL here.The FBML parser is licensed under the MPL. You can find the MPL here.How Can I Contribute?大小: 2.66 K 尺寸: 210 x 79 浏览: 3 次 点击打开新窗口浏览全图If you’d like to contribute to Facebook Open Platform, please sign and return our Contribution Agreement. We’ll evaluate any submitted patches or features to decide whether they’d be strong inclusions into the overall Facebook Open Platform release. If we incorporate your changes, we’ll send you a t-shirt!What’s Included in the Package?The fb-open-platform.tar.gz archive contains the tools necessary to implement Facebook Open Platform — including the API, FBML (Facebook Markup Language), FBJS (Facebook JavaScript), and FQL (Facebook Query Language) — in your own environment. It also contains libfbml-1.2.0.tar.gz, which contains the essential libraries for parsing and rendering FBML.Think this sounds like a fun thing to work on? Join the team.

Google网站架构分析 Google是可伸缩性之王。每个人都知道Google是因为他们对大量，复杂信息的快速搜索，但是Google的技术并不只是在搜索领域闪闪发光。他们构建大型应用的平台方式能够让他们以惊人的竞争速度在网络规模应用上面大展拳脚。Google的目标一直是构建更高性能更高规模基础设施来支持他们的产品。他们怎么做到的呢？参考资料以及信息来源视频：在Google上构建大型系统 (Video: Building Large Systems at Google)Google实验室：Google文件系统 (Google Lab: The Google File System)Google实验室：MapReduce：在大规模集群上简化数据处理 (Google Lab: MapReduce: Simplified Data Processing on Large Clusters)Google实验室：BigTable: (Google Lab: BigTable.)视频：BigTable: 一个分布式的结构化存储系统 (Video: BigTable: A Distributed Structured Storage System.)Google实验室：松散耦合的分布式系统的 Chubby Lock服务 (Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems.)Google是如何工作的 作者 David Carr发表于Baseline杂志 (How Google Works by David Carr in Baseline Magazine.)Google实验室：翻译数据：使用Sawzall并行分析(Google Lab: Interpreting the Data: Parallel Analysis with Sawzall.)可伸缩性大会上Dare Obasonjo的笔记 (Dare Obasonjo’s Notes on the scalability conference.)平台• Linux• 多种不同的语言： Python, Java, C++数据揭秘目前的情形：• 2006年估计有450,000个价格便宜的商用服务器• 2005年Google索引了80亿的web页面。到现在为止有多少，已经无法统计出来了。• 目前Google有超过200GFS的集群。一个集群能有1000甚至5000个机器。成百上千的机器从运行大到5peta字节存储的GFS集群检索数据。通过集群的总的读写吞吐量达到每秒400亿字节。• 目前在Google有6000个 MapReduce应用，并且每个月有几百个新的应用正在出现。架构的层次Google把他们的基础设施架构描述为三个层次栈：• 产品：检索，广告，电子邮件，地图，视频，聊天，博客• 分布式系统基础设施：GFS, MapReduce, 以及BigTable。• 计算平台：很多不同数据中心的很多机器• 确保公司员工容易低成本配置。• 看看每个应用基线的价格性能数据。把更多的钱花在硬件上以期不丢失日志数据，但是在其他类型的数据上花少一点。既然这样处理，实际上他们就不会丢数据。使用GFS（Google文件系统）的可靠存储机制• 可靠的可伸缩存储是任何应用的一个核心需要。GFS就是他们的核心存储平台。• Google文件系统- 大的分布式日志结构化文件系统，里面有大量数据• 为什么不用其他的而非要构建一个文件系统呢？因为他们需要控制所有的事情，而正是这个平台把他们和其他任何一个区分开来。他们需要：- 通过数据中心的高可靠性- 对于几千个网络节点的可伸缩性- 大的读写带宽需求- 支持十亿字节大的数据块- 高效的通过节点减少瓶颈的分布式操作• 系统有主服务器和分块服务器（chunk servers）- 主服务器在各种数据文件上保存元数据。数据以64MB大的块存储在文件系统中。客户机和主服务器对话来操作文件里的元数据，定位包含了磁盘上他们需要的数据的分块服务器。• 一个新的应用可以使用一个已经存在的GFS集群或者他们自己制作。去理解他们使用的通过数据中心的这个供应过程将是非常有趣的。• 主键是足够的基础设施来确保人们对他们的应用有多种选择。可以调整GFS以适应个人应用需要。使用MapReduce对数据做一些事情• 既然你有了一个好的存储系统，你怎样使用如此多的数据呢？假如说你有很多TB的数据存储在1000台机器上。数据库不能扩展或者有效地扩展到这样的规模。这时就要用到MapReduce了。• MapReduce是一个编程模型和用来处理和产生大规模数据集。用户指定一个映射函数处理一个键/值对来产生中间的键/值对集合，还指定一个缩小函数来合并所有的与同一中间键相关的中间值。许多现实世界的任务在这个模型里被表示出来。用这个函数风格写的程序自动并行化并且在一大集群商务机器上执行。运行时系统关心分割输入数据的细节，通过一系列的机器安排程序的执行，处理机器事故，以及管理所需的机器内部通信。这使得没有任何并行和分布式系统经验的程序员能够容易地利用一个大的分布式系统的资源。• 为什么使用MapReduce呢？- 在大量机器上分割任务的极佳方式- 处理机器故障- 在不同类型的应用上工作，如搜索和广告。几乎每个应用都有映射简化类型之类的操作。你可以预计算有用的数据，统计字数，分类几TB的数据，等等。- 计算可以自动地更加靠近IO源。• MapReduce 系统有三个不同类型的服务器。- 主服务器分配用户任务以映射和减少服务器。它也跟踪任务的状态。- 映射服务器接收用户输入，在它们上面实行映射操作。结果写入中间文件。- 化简服务器接收由映射服务器产生的中间文件并在它们上面实行化简操作。• 例如，你想要统计所有网页中字符的个数。你可以把存储在GFS中的页面放入MapReduce。这些都将在1000秒内发生，包括机器同步和协调，任务安排，事故处理和数据传输将会自动完成。- 步骤如下：GFS -> Map -> Shuffle -> Reduction -> 把结果存回GFS- 在MapReduce 里，一个映射把一个视图映射到另一个，产生一个键值对，在我们的例子里是单词和数量。- Shuffling 聚合键的类型- 化简把所有的键值对加起来产生最后的结果。• Google索引管道有大概20个不同的映射化简。一个管道把数据看做记录的一个整体束和聚合键。第二个映射-化简进来把那个结果拿走做其他的一些事情。等等。• 程序可以很小。可以小到20到50行的代码。• 一个问题是stragglers。Stragglers是一种比其他都要慢的计算。Stragglers会发生是因为慢的IO（比如一个糟糕的控制器）或者从一个临时的CPU尖峰信号。解决办法是运行多个同样的计算，当一个完成时就销毁所有其他的计算。• 在映射和化简之间转换的数据被压缩。这样做是因为服务器不受CPU约束，花时间在数据的压缩和解压缩上还是有意义的，可以节省花在带宽和I/O上的时间。在BigTable中存储结构化数据• BigTable 是一个大型的容错和自我管理系统，包括太（万亿）字节的内存和皮字节的内存。它每秒能够处理几百万的读写。• BigTable是一个构建在GFS之上的分布式散列机制。它不是一个关系数据库。它不支持联结或者SQL类型查询。• 它提供查找机制，可以通过键来访问结构化的数据。GFS存储不透明数据和许多应用所需的结构化数据。• 商业化数据不能伸缩到这个层次，它们不在1000个机器上工作。• 通过控制它们自己的低层次存储系统，Google得到更多的控制和有力的工具来改进它们的系统。例如，如果它们想要使得分布数据操作更简单的特征，它们可以在里面构建。• 当系统运行的时候，机器可以增加和减少，而整个系统还会正常工作。• 每个数据条存储在一个可以使用行键，列键或者时间邮票访问的单元中。• 每行存储在一个或者更多个tablet中。一个tablet是数据形式的64KB块的序列叫做SSTable。• BigTable 有三个不同类型的服务器：- 主服务器分配tablet到tablet服务器中。它们跟踪的位置，当需要时还会重新分配任务。- Tablet 服务器处理tablet的读写请求。当tablet超过规模限制（通常是100MB – 200MB）时，它们将它分开。当一个tablet服务器出故障时，会有100个tablet服务器每个捡起一个新的tablet，所以系统就恢复了。• 一个位置组可以被用作与几比特的数据相关的物理存储，为了有一个更好的参考位置。• Tablets尽可能在RAM里被缓存。硬件• 当你有很多个机器时，你如何构建它们以使花费代价最小电能消耗最少呢？• 使用超便宜的商业硬件，拼命利用它们在上面构建软件。• 增加 1,000-fold 计算机电力，如果你使用容易出事故的基础设施而不是构建在高度可靠的部件之上的基础设施时，可以有33倍更低的花费。你必须使用这一策略在不可靠之上构建可靠。• Linux，内部的架构设计，PC类主机板，低端存储。• 性能基线中每瓦的价格没有越来越好。存在着很多的电力和其他问题。• 使用混合收集和它们自己的数据中心。杂类• 很快找出改变而不是等着提问和回答。• 库是构建程序的主要方式。• 一些是以服务的形式提供的应用，比如crawling。• 基础设施处理应用程序的版本，所以它们就能够发布，不用担心破坏事情。Google未来的方向• 支持地理位置分布的集群• 为所有的数据创建单一的全局名字空间。当前数据由集群分离开的。• 更多更好的数据和计算的自动化迁移。• 解决当你用网络分割耦合大范围的复制时产生的一致性问题（例如，即使一个集群已经因为维修或是其他一些临时停电等原因而下线时，还能继续提供服务）Goolge告诉我们的经验• 基础设施是一个很有竞争性的优势。它当然是属于Google的。它们能更快更便宜地提供和生产新的网络服务，这在一定程度上是无人能比的。许多公司采取了完全不同的方式。许多公司把基础设施看做一种花销。每个组将使用完全不同的技术，而且他们很少有计划如何更经济地构建系统。Google把他们自己看做一个系统工程公司，以一个非常新的方式来看待构建软件。• 跨越多个数据中心仍是一个未解决的问题。大多数网站是一个至多是两个数据中心。如何在大量数据中心上充分分配网站，我们说，非常复杂。• 看一看Hadoop (产品)如果你没有时间来从头开始构建所有这个基础设施的话。Hadoop 是一个这里讲的一些主意的开源实现。• 一个平台方式被忽略的优点是初级开发人员可以在平台上很快自信地构建健壮的应用。如果每个项目需要创建同样的分布式基础设施轮，你将会陷入困境，因为知道如何这样做的人员相对稀少。• 协同工作并不总是废话。通过使系统中所有部件一起工作，一个改进会有助于所有的改进。改善文件系统，每个人都会立刻明显受益。如果每个项目使用一个不同的文件系统，那么就没有整个展的持续的改进。• 构建不需要降低系统性能的自我管理系统。这可以让你更容易地平衡各服务器的资源，动态增加更多空间，允许机器下线，以及更从容地处理升级。• 创建一个进化式基础设施。花时间在并行处理上会有回报的。• 不要忽视了学院。学术界有很多好的创意并没有转入生产环境里。Google所做的大部分先于艺术，不只是先于大规模配置。• 考虑压缩。当你有大量CPU可以挥霍和IO限制时，压缩是一个很好的选择。

亿万用户网站MySpace网站架构及成功秘密 《亿万用户网站MySpace的成功秘密》　◎ 文 / David F. Carr   译 / 罗小平     增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统，以期与自身的成长同步——目前，该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分，但那些指望迈入庞大在线市场的人，可以从MySpace的成长过程学到知识。用户的烦恼     Drew，是个来自达拉斯的17岁小伙子，在他的MySpace个人资料页上，可以看到他的袒胸照，看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接，另外还说自己参加了学校田径队，爱好吉他，开一辆蓝色福特野马。     不过在用户反映问题的论坛里，似乎他的火气很大。“赶紧弄好这该死的收件箱！”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息，但当他要查看一条消息时，页面却出现提示：“非常抱歉……消息错误”。     Drew的抱怨说明1.4亿用户非常重视在线交流系统，这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。     11月，MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示，MySpace当月访问量为387亿，而Yahoo是380.5亿。     显然，MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。事实上，MySpace的Web服务器和数据库经常性超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的 MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务，他们不得不在论坛抱怨不停。     尤其是最近，MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说，“难以想象，在有些时候，我们发现20%的错误日志都来自MySpace，有时候甚至达到30%以至40%……而Yahoo、 Salesforce.com和其他提供商用服务的站点，从来不会出现这样的数字。”他告诉我们，其他大型站点的日错误率一般就1%多点。    顺便提及，MySpace在2006年7月24号晚上开始了长达12小时的瘫痪，期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发生故障。为了让大家耐心等待服务恢复，该页面提供了用Flash开发的派克人（Pac-Man）游戏。Web站点跟踪服务研究公司总经理Bill Tancer说，尤其有趣的是，MySpace瘫痪期间，访问量不降反升，“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。现 Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师，因在Web站点方面的评论而闻名的Jakob Nielsen说，MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样，他相信MySpace对其成长速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新，但他们面对的的确是一个巨大的科学难题。”他说。     MySpace开发人员已经多次重构站点软件、数据库和存储系统，以满足爆炸性的成长需要，但此工作永不会停息。“就像粉刷金门大桥，工作完成之时，就是重新来过之日。”（译者注：意指工人从桥头开始粉刷，当到达桥尾时，桥头涂料已经剥落，必须重新开始）MySpace技术副总裁Jim Benedetto说。既然如此，MySpace的技术还有何可学之处？因为MySpace事实上已经解决了很多系统扩展性问题，才能走到今天。     Benedetto说他的项目组有很多教训必须总结，他们仍在学习，路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统，以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。背景知识MySpace logo    MySpace目前的努力方向是解决扩展性问题，但其领导人最初关注的是系统性能。3年多前，一家叫做Intermix Media（早先叫eUniverse。这家公司从事各类电子邮件营销和网上商务）的公司推出了MySpace。而其创建人是Chris DeWolfe和Tom Anderson，他们原来也有一家叫做ResponseBase的电子邮件营销公司，后于2002年出售给Intermix。据Brad Greenspan（Intermix前CEO）运作的一个网站披露，ResponseBase团队为此获得2百万美金外加分红。Intermix是一家颇具侵略性的互联网商务公司——部分做法可能有点过头。2005年，纽约总检察长Eliot Spitzer——现在是纽约州长——起诉Intermix使用恶意广告软件推广业务，Intermix最后以790万美元的代价达成和解。     2003年，美国国会通过《反垃圾邮件法》（CAN-SPAM Act），意在控制滥发邮件的营销行为。Intermix领导人DeWolfe和Anderson意识到新法案将严重打击公司的电子邮件营销业务，“因此必须寻找新的方向。”受聘于Intermix负责重写公司邮件营销软件的Duc Chau说。     当时有个叫Friendster的交友网站，Anderson和DeWolfe很早就是它的会员。于是他们决定创建自己的网上社区。他们去除了 Friendster在用户自我表述方面的诸多限制，并重点突出音乐（尤其是重金属乐），希望以此吸引用户。Chau使用Perl开发了最初的 MySpace版本，运行于Apache Web服务器，后台使用MySQL数据库。但它没有通过终审，因为Intermix的多数开发人员对ColdFusion（一个Web应用程序环境，最初由Allaire开发，现为Adobe所有）更为熟悉。因此，最后发布的产品采用ColdFusion开发，运行在Windows上，并使用MS SQL Server作为数据库服务器。     Chau就在那时离开了公司，将开发工作交给其他人，包括Aber Whitcomb（Intermix的技术专家，现在是MySpace技术总监）和Benedetto（MySpace现技术副总裁，大概于MySpace上线一个月后加入）。     MySpace上线的2003年，恰恰是Friendster在满足日益增长的用户需求问题上遭遇麻烦的时期。财富杂志最近的一次采访中，Friendster总裁Kent Lindstrom承认他们的服务出现问题选错了时候。那时，Friendster传输一个页面需要20到30秒，而MySpace只需2到3秒。结果，Friendster用户开始转投MySpace，他们认为后者更为可靠。     今天，MySpace无疑已是社区网站之王。社区网站是指那些帮助用户彼此保持联系、通过介绍或搜索、基于共同爱好或教育经历交友的Web站点。在这个领域比较有名的还有最初面向大学生的Facebook、侧重职业交流的LinkedIn，当然还少不了Friendster。MySpace宣称自己是“下一代门户”，强调内容的丰富多彩（如音乐、趣事和视频等）。其运作方式颇似一个虚拟的夜总会——为未成年人在边上安排一个果汁吧，而显著位置则是以性为目的的约会，和寻找刺激派对气氛的年轻人的搜索服务。     用户注册时，需要提供个人基本信息，主要包括籍贯、性取向和婚姻状况。虽然MySpace屡遭批评，指其为网上性犯罪提供了温床，但对于未成年人，有些功能还是不予提供的。　　MySpace的个人资料页上表述自己的方式很多，如文本式“关于本人”栏、选择加载入MySpace音乐播放器的歌曲，以及视频、交友要求等。它还允许用户使用CSS（一种Web标准格式语言，用户以此可设置页面元素的字体、颜色和页面背景图像）自由设计个人页面，这也提升了人气。不过结果是五花八门 ——很多用户的页面布局粗野、颜色迷乱，进去后找不到东南西北，不忍卒读；而有些人则使用了专业设计的模版（可阅读《Too Much of a Good Thing?》第49页），页面效果很好。     在网站上线8个月后，开始有大量用户邀请朋友注册MySpace，因此用户量大增。“这就是网络的力量，这种趋势一直没有停止。”Chau说。     拥有Fox电视网络和20th Century Fox影业公司的媒体帝国——新闻集团，看到了他们在互联网用户中的机会，于是在2005年斥资5.8亿美元收购了MySpace。新闻集团董事局主席 Rupert Murdoch最近向一个投资团透露，他认为MySpace目前是世界主要Web门户之一，如果现在出售MySpace，那么可获60亿美元——这比 2005年收购价格的10倍还多！新闻集团还惊人地宣称，MySpace在2006年7月结束的财政年度里总收入约2亿美元，而且预期在2007年度，Fox Interactive公司总收入将达到5亿美元，其中4亿来自MySpace。　　然而MySpace还在继续成长。12月份，它的注册账户达到1.4亿，而2005年11月时不过4千万。当然，这个数字并不等于真实的用户个体数，因为有些人可能有多个帐号，而且个人资料也表明有些是乐队，或者是虚构的名字，如波拉特（译者注：喜剧电影《Borat》主角），还有像Burger King（译者注：美国最大的汉堡连锁集团）这样的品牌名。     当然，这么多的用户不停发布消息、撰写评论或者更新个人资料，甚至一些人整天都泡在Space上，必然给MySpace的技术工作带来前所未有的挑战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费，它们的内容数据库通常可以优化为只读模式，因为用户评论等引起的增加和更新操作很少。而MySpace是由用户提供内容，数据库很大比例的操作都是插入和更新，而非读取。　　浏览MySpace上的任何个人资料时，系统都必须先查询数据库，然后动态创建页面。当然，通过数据缓存，可以减轻数据库的压力，但这种方案必须解决原始数据被用户频繁更新带来的同步问题。     MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后，必须做大量的调整和优化。Benedetto说，“但我们始终跟不上形势的发展速度。我们重构重构再重构，一步步挪到今天”。　　尽管MySpace拒绝了正式采访，但Benedetto在参加11月于拉斯维加斯召开的SQL Server Connections会议时还是回答了Baseline的问题。本文的不少技术信息还来源于另一次重要会议——Benedetto和他的老板——技术总监Whitcomb今年3月出席的Microsoft MIX Web开发者大会。　　据他们讲，MySpace很多大的架构变动都发生在2004和2005年早期——用户数在当时从几十万迅速攀升到了几百万。     在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。　　虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，“我们已经尽可能把事情做到最好”。 里程碑一：50万账户     按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。　　单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。　　但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。　　但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。　　在第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。里程碑二：1-2百万账户     MySpace注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾”，Benedetto说，这意味着 MySpace永远都会轻度落后于用户需求。“有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。”他补充道。　　这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。　　垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性，Benedetto说。里程碑三：3百万账户     当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。　　另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。　　2004年中，MySpace面临Web开发者称之为“向上扩展”对“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。　　但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。     另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。“搞不好，开发人员的所有工作都将白费”，Benedetto说。因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，“那时候，这个方案看似可能解决一切问题。”如稳定性，更棒的是对现有软件几乎没有改动要求。糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。”     因此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。     既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。　　当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。里程碑四：9百万到1千7百万账户     2005年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和 Java的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是 Microsoft目前主推的Web站点编程环境。　　可以说是立竿见影，MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。      最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了 ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。     账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。     原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。     某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。”Benedetto说。     最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。　　长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。     在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使SAN的任何组件过载。　　当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。     缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，“我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。　　增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。里程碑五：2千6百万账户     2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。”支持64位的数据库可以管理更多内存。     更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。意外错误     如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误”是怎么引起的呢？　　原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致惹人恼怒。一旦数据库罢工，“无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个‘意外错误’提示。”他解释说。　　去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量 MySpace合法用户连接时也会引起服务器反击。    “我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。”　　紧接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务器除了恳求你耐心等待，不能提供任何服务。     Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。     2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。       MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。“作为开发人员，我憎恶Bug，它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。“不过，MySpace对我们的用处很大，因此我们可以原谅偶发的故障和错误。” Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。     这就是为什么Drew在论坛里咆哮时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，“我已经两次给 MySpace发邮件，而它说一小时前还是正常的，现在出了点问题……完全是一堆废话。”另一个用户回复说，“毕竟它是免费的。”Benedetto坦承 100%的可靠性不是他的目标。“它不是银行，而是一个免费的服务。”他说。     换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户的钱财。“关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。”Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内任意点数据的危险，在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。     Benedetto说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而且，因为进行大规模真实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试，他们做的测试通常都是针对站点。   “我们犯过大量错误，”Benedetto说，“但到头来，我认为我们做对的还是比做错的多。”

优化页面网站提高转化率 原文：Make sense of your site: tips for webpage design发表于：2009年3月16日星期一，上午9:28在 以前，当您收到用户的反馈，需要改动您的网站的时候，您可能需要对网页进行重新设计。现在，您可以在您的网站上进行一系列实验，让用户来决定哪种版本最 好，而不是只是跟着感觉走了。这里，我将向您介绍网站实验——同时运行同一网页的多种测试版本来了解哪一种网页方案更奏效。在开始实验之前，请您先为要做实验的部分设计出几种方案。实验的部分可以是一些小的改变，比如换掉一张图片，或者是大的改变，比如大面积调整您网站的布局或颜色方案。然后，您可以使用谷歌提供的免费工具—— 网站优化工具(中 文版)，通过向访问者自动展示网站的不同版本来测试这些不同方案。网站优化工具通过跟踪记录哪一种网站变化最能帮助您实现预定目标，从而能使您了解访问者 最喜欢哪种方案版本。您可以把预定目标设为达成销售、吸引用户提交了一个表单或者点击了某个链接，或者其他与您网站的互动形式。事实上，这个过程就像一个 简单的实验，并不需要很多复杂的数据分析。网站实验的结果经常出人意料。比如，我们曾用网站优 化工具对Picasa首页进行过一次实验，结果就让我们大吃一惊。在版本A里，我们使用了“免费”这个词，采用了以行动为导向的标题，并且放上了非常漂亮 的产品图片。在版本B里，我们删除了图片，用按钮取代了链接，以这个产品能给用户带来的价值为主打理念。如果换作是您，您认为哪种版本能带来更多的 Picasa下载呢？版本A：版本B：我 们起初预测版本A显然会更胜一筹，因为A版本的图片会很吸引眼球，并且免费的字眼应该看上去很有吸引力。然而，实验数据却表明界面更简明的B版本却是带来 下载量更多的。实际上，版本B比版本A多带来30%的下载量！这个例子表明：在有关网站重要决策的时候，有时您是需要依赖数据的，不能凭想当然。现在，您 或许会问自己，“我的网站可能有很多地方需要做实验，我应该从哪里着手呢？” 这里向您提供四点小建议： 建议一：通过8秒测验。用户需要一眼就能理解您网站的主题和目的。访问者通常都很忙，无暇顾及很多细节，您一定不想他们刚来到您的网站上就点击后退按钮吧？ 建议二：告诉用户您的网站能给他们带来什么。突出显示您的网站能给用户带来的清晰的、触手可及的实惠（比如，“节省更多!” “收益更多!” “使用我们的产品会让您更好！”） 建议三：使用更有吸引力的图片。您要尽量采用产品的图片而不是一般的图片，使用图标而不是大块的文字，使用按钮而不是链接。请记住，使用低质量的、不相关的图片只会有损您网站的信誉。 建议四：果断地促成销售。帮助您的访问者尽快进行下一步，使这一步骤明确并容易到达，而不是让用户再去费力寻找。关于号召行动的词汇，“立即购买”要比“添加到购物车”更好。 一旦您决定要测试哪个细节（比如号召用户采取某种行动、颜色方案、标题，布局或者视频），您就可以使用网站优化工具， 进行一项实验。对第一次使用网站优化工具的用户来说，我们推荐A/B实验，这是测试某两种版本哪个更奏效。网站优化工具会帮您处理繁杂的数据，并且当它发 现某一数据能证明某一个方案明显优于另一个时，能及时向您展示。这些结果将在您每个实验的报告中展示，相应的滑动条将变成红色，黄色或绿色。当滑动条变成 绿色的时候，意味着您的两种方案中的某一种已经开始胜出，能够明显地更有助于您实现预先设定的目标：请记住，实验数据产生的最佳实践也不是完全普适的，他们并不一定是最适合您的网站和访问者的。在过去，人们都是凭主观想法和直觉来决定网站的设计。现在，有了这些有力的工具、数据和曲线，您就可以让您的访问者来告诉您哪种网站设计是最适合您的了。现在就试一下吧，希望能给您的网站带来更佳的效果！