翻译说明：
这是Solid State Group网站上的一篇很友好的文章，解决了我在设计中遇到的很多问题，故在此我翻译其文，并对原作者表示非常感谢！
查看原文：http://diger.cn/blog/?p=324
英文地址： http://www.solidstategroup.com/page/1592
1、说明本文阐述了8条我们发现的在用CSS设计中有用的解决方案。
yaosansi's Blog
程序员的技术资料主要涉及ASP.NET WEB开发，.NET程序开发，视频开发等相关技术。
您的位置:
首页 - 2007 November
- 本站大部分内容从网上收集,收集目的仅供研究、学习。涉及版权或不希望收录您的文章请您及时与我联系。
- 本站IM群，请自行选择。请各位朋友按照自己喜好加入。加入群后请及时发言，防止被清理。谢谢您的合作！！！
- QQ群:Y①WEB开发(ASP.NET）号码:7351660 QQ群:Y②WEB开发(ASP+.NET）号码:11864905
- QQ群:Y③WEB开发(DIV+CSS）号码:16610506 QQ群:Y④WEB开发(JS+AJAX）号码:16143998
- QQ群:Y⑤WEB开发(新手）号码:12777715 MSN群:yaosansi[at]126.com
CSS hacks与争议
分类: XHTML+CSS 浏览: 日期: 2007年11月24日
评论:(0) Tags: CSS
页面中图像格式的选用之我见
分类: Others 浏览: 日期: 2007年11月24日
今天有个学生问我：页面中使用GIF格式，失真太大，怎么办呢？这个问题比较简单啊，只要用JPG就可以了。我们常用的页面的图片格式有三种，GIF、JPG、PNG。那么这三种格式我们怎么选择使用呢？下面就我的一些经验来谈谈我对于这三个格式的使用上的一些看法。
下面我们先了解一下几种格式的比较正式的解释(注：以下内容源自百度知道)：
GIF 意为Graphics Interchange format（图形交换格式），GIF图片的扩展名是gif。现在所有的图形浏览器都支持GIF格式，而且有的图形浏览器只认识GIF格式。GIF是一种索引颜色格式，在颜色数很少的情况下，产生的文件极小，它的优点主要有：
- GIF格式支持背景透明。GIF图片如果背景色设置为透明，它将与浏览器背景相结合，生成非矩形的图片。
- GIF格式支持动画。在Flash动画出现之前，GIF动画可以说是网页中唯一的动画形式。GIF格式可以将单帧的图象组合起来，然后轮流播放每一帧而成为动画。虽然并不是所有的图形浏览器都支持GIF动画，但是最新的图形浏览器都已经支持GIF动画。
- GIF格式支持图形渐进。渐进是指图片渐渐显示在屏幕上，渐进图片将比非渐进图片更快地出现在屏幕上，可以让访问者更快地知道图片的概貌。
- GIF格式支持无损压缩。无损压缩是不损失图片细节而压缩图片的有效方法，由于GIF格式采用无损压缩，所以它更适合于线条、图标和图纸。
GIF格式的缺点同样相当明显。索引颜色是历史遗留的产物，在DOS下的老游戏几乎无一例外的采用索引颜色，这种格式本来早就应该淘汰了。但是由于带宽的限制，GIF从DOS时代红到了Internet时代。GIF这种索引颜色格式最大的缺点就是它只有256种颜色，这对于照片质量的图片是显然不够的。
评论:(0) Tags: 图像格式
几处IE与firefox的js和css几处不同点
分类: JavaScript 浏览: 日期: 2007年11月24日
1.firefox不能对innerText支持，也不知道为什么。firefox支持innerHTML但却不支持innerText，所以上网查了一下，原来它改支持textContent来实现innerText，不过实现得没有那么好，默认把多余的空格也保留了。如果不用textContent，如果字符串里面不包含HTML代码也可以用innerHTML代替
2.禁止选取网页内容：
在IE中一般用js：obj.onselectstart=function(){return false;}
而firefox用CSS:-moz-user-select:none
3.滤镜的支持(例：透明滤镜)：
IE:filter：alpha(opacity=10);
firefox：-moz-opacity:.10;
4.捕获事件：
IE：obj.setCapture() 、obj.releaseCapture()
Firefox： document.addEventListener("mousemove",mousemovefunction,true);
document.removeEventListener("mousemove",mousemovefunction,true);
5.获取鼠标位置：
IE:event.clientX、event.clientY
firefox：需要事件函数传递事件对象
obj.onmousemove=function(ev){
X= ev.pageX;Y=ev.pageY;
}
6.DIV等元素的边界问题：
比如：设置一个div的CSS:：{width:100px;height:100px;border:#000000 1px solid;}
IE中：div的宽度（包括边框宽度）：100px，div的高度（包括边框宽度）：100px；
而firefox：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
所以在做这个兼容IE和firefox的拖动窗口时，在js和css的写法上要动点脑筋，给大家两个小技巧
一.判断浏览器类型：
var isIE=document.all? true:false;
我写了一个变量，如果支持document.all语法那么isIE=true，否则isIE=false
二.在不同浏览器下的CSS处理：
一般可以用!important来优先使用css语句（仅firefox支持）
比如：{border-width:0px!important;border-width:1px;}
在firefox下这个元素是没有边框的，在IE下边框宽度是1px
又发现几处XHTML与正常状态下的JS、CSS的区别
前阶段写了兼容IE/Firefox的拖动窗口发现了这两个浏览器的几处区别：发现几处IE与firefox的js和css几处不同点【原】
今天又写了兼容XHTML的版本，因为现在不是流行web标准嘛，偶不能落后啊！再说现在ASP.NET中的所有页面都是应用XHTML标准的，如果在布局页面中删了这句标准代码，里面的布局和控件visual studio就不显示了。
呵呵，在网页开头加了这个代码就是所谓的XHTML标准了<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
改了一下JS和CSS，调试了N次，发现了XHTML标准下的几个不同点：
1.document.documentElement 与 document.body
代码中设置页面的CSS时一定要用：document.documentElement
比如：document.documentElement.style.overflow='hidden';
overflow-X、overflow-Y 这两个分坐标属性XHTML是不支持的；
2.在取得网页窗口区域和获取滚动条位移距离时也要用document.documentElement
即这四个属性（clientWidth、clientHeight、scrollLeft、scrollTop）一定要用document.documentElement
但是document.body.appendChild()和document.body.removeChild()却是可以用的，而且用document.documentElement.appendChild()和document.documentElement.removeChild()代替却会报错；
**********所以我总结了一下仅clientWidth、clientHeight、scrollLeft、scrollTop和document.documentElement.style时才用document.documentElement
3.呵呵，加了这个标准以后IE的边框问题也出现了变化，现在和firefox趋于一致了，是不是这个就是XHTML的优点——跨浏览器的标准
上篇文章提到：
设置一个div的CSS:：{width:100px;height:100px;border:#000000 1px solid;}
IE中（正常情况）：div的宽度（包括边框宽度）：100px，div的高度（包括边框宽度）：100px；
firefox（正常情况）：：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
加了XHTML标准后的（IE和firefox打和了，^_^）：
IE中（XHTML）：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
firefox（XHTML）：：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
文章出自【星火燎原】
2.禁止选取网页内容：
在IE中一般用js：obj.onselectstart=function(){return false;}
而firefox用CSS:-moz-user-select:none
3.滤镜的支持(例：透明滤镜)：
IE:filter：alpha(opacity=10);
firefox：-moz-opacity:.10;
4.捕获事件：
IE：obj.setCapture() 、obj.releaseCapture()
Firefox： document.addEventListener("mousemove",mousemovefunction,true);
document.removeEventListener("mousemove",mousemovefunction,true);
5.获取鼠标位置：
IE:event.clientX、event.clientY
firefox：需要事件函数传递事件对象
obj.onmousemove=function(ev){
X= ev.pageX;Y=ev.pageY;
}
6.DIV等元素的边界问题：
比如：设置一个div的CSS:：{width:100px;height:100px;border:#000000 1px solid;}
IE中：div的宽度（包括边框宽度）：100px，div的高度（包括边框宽度）：100px；
而firefox：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
所以在做这个兼容IE和firefox的拖动窗口时，在js和css的写法上要动点脑筋，给大家两个小技巧
一.判断浏览器类型：
var isIE=document.all? true:false;
我写了一个变量，如果支持document.all语法那么isIE=true，否则isIE=false
二.在不同浏览器下的CSS处理：
一般可以用!important来优先使用css语句（仅firefox支持）
比如：{border-width:0px!important;border-width:1px;}
在firefox下这个元素是没有边框的，在IE下边框宽度是1px
又发现几处XHTML与正常状态下的JS、CSS的区别
前阶段写了兼容IE/Firefox的拖动窗口发现了这两个浏览器的几处区别：发现几处IE与firefox的js和css几处不同点【原】
今天又写了兼容XHTML的版本，因为现在不是流行web标准嘛，偶不能落后啊！再说现在ASP.NET中的所有页面都是应用XHTML标准的，如果在布局页面中删了这句标准代码，里面的布局和控件visual studio就不显示了。
呵呵，在网页开头加了这个代码就是所谓的XHTML标准了<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
改了一下JS和CSS，调试了N次，发现了XHTML标准下的几个不同点：
1.document.documentElement 与 document.body
代码中设置页面的CSS时一定要用：document.documentElement
比如：document.documentElement.style.overflow='hidden';
overflow-X、overflow-Y 这两个分坐标属性XHTML是不支持的；
2.在取得网页窗口区域和获取滚动条位移距离时也要用document.documentElement
即这四个属性（clientWidth、clientHeight、scrollLeft、scrollTop）一定要用document.documentElement
但是document.body.appendChild()和document.body.removeChild()却是可以用的，而且用document.documentElement.appendChild()和document.documentElement.removeChild()代替却会报错；
**********所以我总结了一下仅clientWidth、clientHeight、scrollLeft、scrollTop和document.documentElement.style时才用document.documentElement
3.呵呵，加了这个标准以后IE的边框问题也出现了变化，现在和firefox趋于一致了，是不是这个就是XHTML的优点——跨浏览器的标准
上篇文章提到：
设置一个div的CSS:：{width:100px;height:100px;border:#000000 1px solid;}
IE中（正常情况）：div的宽度（包括边框宽度）：100px，div的高度（包括边框宽度）：100px；
firefox（正常情况）：：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
加了XHTML标准后的（IE和firefox打和了，^_^）：
IE中（XHTML）：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
firefox（XHTML）：：div的宽度（包括边框宽度）：102px，div的高度（包括边框宽度）：102px；
文章出自【星火燎原】
评论:(0) Tags: Firefox JS CSS
如何减少网页的内存与CPU占用
分类: WebSite 浏览: 日期: 2007年11月24日
有的网页看起来并不大但打开会很卡，有的网页虽然很长但使用流畅，占用用户电脑的内存与CPU就影响这些。
浏览器问题，有各自的浏览器处理内存问题会影响到，但几乎没办法控制得了，Windows上的：
- IE系列，刷新回收的量不大，但最小化会释放内存，。
- Firefox2据说也会在最小化回收，可我从没见过最垃圾，用多少是多少，基本不回收。据说prototype的ajax还会引起内存一直增加。
- Opera最好。一直控制得很好。不存在什么问题。。
Linux的内存分配机制与Win的不一样，有多少用多少，如果浏览器占光时说不定会干掉系统。
页面问题，浏览器渲染页面会消耗内存和CPU，能减少一点就减少点。
评论:(0) Tags: 内存 CPU
理论普及——用户体验
分类: WebSite 浏览: 日期: 2007年11月24日
一、概念分析1：UE用户体验
英文叫做user experience，缩写为UE, 或者UX。
当指电子商务网站的时候也被称作顾客体验（CUSTOMER EXPERIENCE). 它是指用户访问一个网站或者使用一个产品时的全部体验。他们的印象和感觉，是否成功，是否享受，是否还想再来/使用。他们能够忍受的问题，疑惑和BUG的程度
附英文原文供参考：
the user experience, mostly called "customer experience" when referring to e-commerce websites; the totality of the experience of a user when visiting a website. Their impressions and feelings. Whether they're successful. Whether they enjoy themselves. Whether they feel like coming back again. The extent to which they encounter problems, confusions, and bugs.
评论:(0) Tags: 用户体验
Web 2.0网站性能调优实践
分类: WebSite 浏览: 日期: 2007年11月24日
Web2.0网站性能调优实践
文/王宗义
当前web2.0革命风起云涌，web2.0强调服务，而服务最基本的要求是速度快和稳定，离开这两个谈功能强大和易用性都没有任何意义。本文介绍一些关于笔者运营一个web2.0网站的优化心得和经验，希望能够和大家共同探讨。
Web2.0网站不同于以往以静态信息为主的网站架构，以往的结构大体分为2层，一个是客户端浏览器，一个就是web服务器；而web2.0以动态和交互为主，一般是3层或者4层，在静态信息网站的结构上的web服务器后端会增加应用服务器和数据库。一般会把浏览器和web服务器归为最上一层即为web层，应用服务器为中间一层，数据库为最底层。从优化角度来讲，越上层优化获得益处越大，优化也是从上自下而来。
Web层优化
DNS的解析时间
这个时间就是在用户第一次访问网站的时候产生，解析时间会影响用户的访问感受，因此想要网站响应速度快，第一就是不要在DNS解析上产生问题。另外DNS的TTL时间也要考量，IE的DNS过期时间是30分钟，TTL设置的比这个长一点就可以。另外在web服务器上使用keep-live也会减少DNS查询次数。
降低浏览器发起请求的数量
尽量降低浏览器发起请求的数量，就是说尽量能够让浏览器缓存任何可以缓存的东西。这样当用户访问过一次后，第二次访问可能会使得发起的请求数趋近1或者等于1，如果是静态的页面则可能是0。方法包括：
把所有的样式表文件并为1个
把所有的js文件并成1个
图片尽量能够合成1张，这个跟以前不一样，现在大多数是adsl上网，反而是大量的零碎图片能够影响速度
页面布局与样式
页面采用xhtml，采用div+css布局，而把样式表和xhtml文件分开，一则能够降低xhtml文件大小，二则能够对样式表文件进行其他缓存处理。这里还有个ui设计的原则，ui跟系统结构一样，越简洁越好，这样整体页面代码会比较少，速度也会比较不错。
JavaScript文件
JavaScript文件也最好放到html文件外，原因同上。
静态文件的优化方法
a)目前大多数的浏览器都支持gzip压缩文件，因此为文本、静态页面、样式表、JavaScript文件等可以压缩处理的文件进行压缩处理能够减少内容获取时间，一般压缩完的大小为原大小的10-30%。这个在apache等web服务器上进行设置，笔者使用lighttpd的设置为：
server.modules = (
….
"mod_compress",
…
)
compress.cache-dir="/usr/local/lighttpd/cache"
compress.filetype = ("text/plain", "text/html", "text/css", "text/javascript")
b)还可以在静态文件服务器前面增加缓存服务器比如squid，进一步增强客户端的访问性能。如果有好的财力，还可以使用一些商业的CDN加速服务。
应用Cookie的注意事项
Cookie的应用要注意，要限制cookie的应用域和应用的目录以及过期时间。不然如果用户是第一次访问的话，可能连一个小小的静态图片都要发送cookie到服务器，这样增加了通信负载。另外要限制cookie的大小，一个3k的cookie能够增加延迟达到80ms。
提高页面速度
页面由2-4个不同域名的服务器提供服务能够提高速度，这个国外也有研究证明。比如主html文件由app.domain.com提供，样式表由style.domain.com提供，图片等由img.domain.com提供，这样浏览器可以同时从多个服务器下载文件，速度就能够上去。但是最好不要超过4个。
样式表文件位置
把样式表文件放在页面的<head>，这样能够先读取。因为在ie中有个样式表的问题，样式表如果没有加载完会影响后面的html内容的页面显示，因此虽然html文件都已经在浏览器了，但是页面还是显示不出来。
把JavaScript移到html文件末尾
把JavaScript移到html文件末尾。为什么这么做呢，因为JavaScript处理的过程中会阻塞后面的页面显示，并且也会使得http请求也被阻止。笔者的网站就有过这样的例子，网站上放了一个合作方的JavaScript，结果每次访问时候感觉页面都停滞，用户体验特别差，后来让同事处理了一下，放到末尾等页面加载完了再显示在原有位置，一下子就好了。
尽量避免跳转
尽量避免跳转比如301和302。如果必须的话，对301和302的页面添加过期头。笔者原来的单点登录就需要进行跳转，后来改进了不需要跳转，整体的速度效果就出来了。
移除重复的脚本
要移除重复的脚本，ie会对重复的脚本发起重复的http请求，大多数网站在运营一段时间都有可能出现这个情况，笔者的网站中就经常有市场人员添加的重复的广告脚本。
AJAX内容
AJAX内容也是可以进行缓存的，同样可以压缩和缓存异步调用的xml、json等数据。
对爬虫进行限制
对爬虫进行限制，国内的一些爬虫非常厉害，并且不遵守robots规矩，经常有反应某某厉害爬虫把网站搞瘫的事件。怎么对爬虫进行限制呢，只能在web服务器上下功夫了，apache等服务器都能够进行限制，笔者的lighttpd限制10个并发的配置如下：
evasive.max-conns-per-ip = 10
web层的优化目的就是极大的利用了浏览器的缓存特性，从而达到几乎是本地访问的速度，下图是笔者访问douban.com首页的效果图对比：
前一列数据是空的缓存所需要下载的文件大小和http请求数量，后面是真实访问的带cache的情况，效果特别明显。http请求减少了95%，内容cache了82%。
应用程序层优化
应用服务器的优化
Php的可以采用一些优化手段比如Zend Optimizer、eAccelerator、MMCache、Zend Performance Suite等
Java的可以采用一些性能强的jdk、应用服务器，对jdk参数进行优化等等
使用ETag
ETag就像版本控制服务器中的版本号一样，每次更新后的ETag是不一样的，而浏览器处理就类似版本服务器的客户端一样，先把版本号发到服务器请求。ETag的处理过程，先是Web服务器在响应的http头中发送ETag，比如这样：
ETag: "1111-2222-3333"
Last-Modified: Thu, 07 Oct 2007 15:20:18 GMT
而浏览器如果再次请求该页面就会发送类似如下的头：
If-None-Match: "1111-2222-3333"
If-Modified-Since: Thu, 07 Oct 2007 15:20:18 GMT
此时，如果该页面没有任何变更，则web服务器会响应一个304的头，并且不需要附带页面内容给浏览器（即不需要再动态生成页面内容），这样就大大减少了服务器的处理和网路通信负载。
同步变异步
同步变异步，在web2.0网站中经常有很复杂的处理，比如一个用户的注册还需要发邮件等操作，有时候可能还有其他的处理，这样用户的等待时间比较长，并且容易出现错误。此种情况下，把其他处理变成异步的，从而直接把页面尽快响应给用户。笔者的一个数据上传的程序也是如此处理，一大堆数据，上传时间可能就1-2秒，而处理时间可能长的需要接近10秒（需要在数据库中进行上千次的插入操作），而在应用服务器容器内处理耗时则更长，笔者后来改成异步处理以后，用户满意度则大幅上升。
使用缓存
还是缓存，可能的情况下尽量使用缓存，毕竟现在内存非常便宜，用空间换取时间效率应该是非常划算的。尤其是对耗时比较长的、需要建立网络链接的，方法：采用memcached进行数据库或者常用数据的缓存；应用数据库缓冲池减少建立数据库连接的时间
采用gzip压缩动态页面
可能情况下，也可以采用gzip压缩动态页面。如果服务器较多，cpu负载不高，则可以考虑对动态页面增加gzip压缩功能
集群处理
访问压力大的时候，对应用服务器采用集群处理。
应用服务器的优化主要是减少程序处理的时间，提高运行效率。
数据库优化
这个议题跟具体数据库关系比较大，议题也比较广泛，笔者就只简要列举一下：
设置专门的DBA，专门负责数据库的安装、优化；对sql进行优化采用数据库集群和复制功能分担数据库压力。
其他优化措施
网站的优化涉及的方面比较多，其他方面涉及的还包括网站架构、操作系统、服务器硬件、网络设备、isp机房网络等等的调优。
工具
笔者用到的工具，都是firefox插件，所以firefox是必备的了：
1、LiveHTTPHeaders (http://livehttpheaders.mozdev.org/)
2、Firebug (http://getfirebug.com)
3、YSlow (http://developer.yahoo.com/yslow/)，要先装Firebug
4、Web Developer (http://chrispederick.com/work/web-developer/)
除了这些免费的工具外，还可以采用一些商业的网站性能监测服务。一般网站性能监测服务商都会在不同的isp设置数据采集点，然后会定期模拟浏览器的访问对网站进行访问获取各种数据，比如dsn查询时间、第一个包获取时间、整个页面加载时间等等，然后汇总到数据中心。数据中心则可以产生性能报表、不同时间的可访问率、哪个isp容易出问题、发出警报等等。如果预算足够的话，可以采用这个服务。国外的有keynote、ip-label等，功能比较齐全，但是服务费用比较贵而且国内的点比较少。国内近些年也开始涌现出一些厂商，比如基调网络。笔者使用的监测系统的图例：
笔者网站3年不同阶段的优化过程
优化的原则是尽量不去优化，在未发生性能问题的时候，没有必要去专门考虑细节的性能问题，当然大的结构应该是能够适应网站不断发展变化的。笔者的网站近3年的优化过程如下：
1、开发完成，刚上线的时候，不做优化，用户量少，用了3台服务器。
2、10万用户的时候，主要对sql进行了优化，还是3台服务器。
3、10万用户到100万的过程中，采用了AJAX等，因此开始关注JavaScript的优化手段，访问量也快速上去，因此对静态文件进行分离并优化。服务器也进行了扩展，扩展到5台服务器。
4、100万-200万用户，业务系统增加了很多，因此数据库采用了复制，程序方面应用了各种缓存处理，在数据库和程序之间增加了memcached进行数据缓存。
5、在200万用户以上，主要在程序架构上做文章，对某些服务使用了集群。另外为了监测国内不同城市、isp的网络状况，使用了商业化的网站性能监测服务。
评论:(0) Tags: Web 2.0 性能
YouTube架构
分类: WebSite 浏览: 日期: 2007年11月24日
YouTube网站架构
文/Todd Hoff译/罗小平
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 团队是成功的基础。在一个有良好纪律的团队中，所有成员都能够准确把握整个系统，了解深层问题。拥有一个好的团队，将无往而不胜。
评论:(0) Tags: YouTube 架构
Twitter的增容处理
分类: WebSite 浏览: 日期: 2007年11月24日
Twitter的增容处理
文/Patrick Joyce译/杨昊
由于之前爆发的一些问题，大家产生了对Twitter的成见。并不是说对Rails进行增容很难，实际上针对基于Rails的网站进行增容并不是问题所在，对所有的网站来讲，增容从来都不是一个容易的问题。
Twitter的故事
Twitter源自于ODEO公司的一个小的分支项目，它是Jack Dorsey提出的，并且成为了世界上最大的Rails应用。Jack Dorsey 对AIM的状态消息十分着迷。问题在于，如果想把消息发到世界的各个角度，你必须得坐在电脑前面。
Twitter自去年三月发布之后访问量少得可怜，直到去年的西南偏南音乐节，大家都能从大屏幕上看到Twitter的使用过程，自此之后一下火了起来，访问量骤增。然后又平静了一阵。接着媒体技术粉墨登场，又掀起了一股热潮。
所以，你该怎样面对这些呢？
l 更多的主机—仍旧是一个包含主/从副本的数据库
l Joyent网站提供的具有32个CPU核的SUN主机
l 横跨19个CPU核的120个mongrel实例
l 横跨16个CPU核的消息处理
l 横跨2核的Jabber服务实例
l 一个构建于8核主机之上的MySQL实例
l 16GB以上的memcache应用
为何需要这些呢？
l 平均每秒200-300的连接数量
l 高峰期每秒800个连接
l 它们处理了11000个连接
l MySQL每秒处理2400个
l Alexe（有所保留地）说他们有着巨大的流量，那还没计算占用了很大流量的API访问。在他们最新的一次测试中通过API的流量访问是web流量的20倍
而配备了cache_fu与acts_as_cached这两个Rails插件的Memcache成了他们的救星。此外，他们还使用扩展了的cache_stats插件获取状态。
他们写了一个自定义的API缓存插件，在执行过滤之前和之后完成自定义操作。他们打算共享抽取出来的缓存。如何使缓存失效是这样做的一个难点。他们既做基于时间的过期限制，也做事件驱动的过期限制。
在数据库设计方面，诸如一些ID列表之类，他们采取了反正规化（denormalize）的方式。通过对id列表进行缓存，这样避免了数据库中的连接操作，这为他们减轻了许多数据库方面的压力。
他们与Gmail的创建人Paul Buchheit在处理系统缓存时，如何构建一个健壮的分布式队列。因为此前他们的架构工作做的有些过多了。一秒钟会有多少条消息呢？9条。6个月的时间里又能有多少？这个系数是10。只要将他们扔到磁盘里面进行处理就好了。
他们希望能够开放队列系统的源代码。它是基于memecache系统的。通过memcache，任何消息都可以加入到队列中，并使用memcache客户端进行访问。
他们所做的最有帮助的事情之一，就是与社区之间的讨论和互动。你不能总猫在你的办公室。社区能够提供很多帮助。和他们进行讨论，你可以得到众多的顾问。社区中有太多优秀的人了，你没有理由不去借助他们的帮助。
问答环节
问：对于缓存中的事件驱动失效机制，其相关的逻辑是放在什么地方的？在Mongrel里面？还是在Rails和XMPP的集成里面？
答：是放在Jabber服务器中，它可以将这些以Ruby写就的处理客户端完全隔离开来。
问：他们打算什么时候加入分区机制？如何处理用户间的随机关系？
答：用户不是关键。他们仍未进行分区的原因是，他们想要基于时间进行划分，因为大多数请求从时间上看是本地的。他们计划在未来3到4个月里做这件事情。Oracle完成了这工作，但Alex说他宁肯把自己的帽子吃掉，也决不会去买oracle的许可证。所以当他们解决了之后就会推出来。
试着尽量发现如何高效地开展开源工作，并努力去多做一些。
问：你的商业模式是什么？计划如何赚钱？
答：每个人都在问这个问题。简单点回答就是下一个问题（大笑）。他们有一些想法，这些聪明人们正在做一些事情。它一定能够让大家耳目一新。
问：他们有多少eJabberd节点？
答：很多，多得令人吃惊。
问：在eJabberd和rail用户之间进行同步会有问题吗？
答：不会。
问：有了所有这些mongrel，你们是如何完成部署并保证全部正常运行的？
答：他们希望从观众中得到建议。他们付出了很多努力，做了复查和改进。如果你在他们进行部署的时候是连接着的，你会与500个用户相联。这是很惊人的。他们仍没有一个很好的办法来解决这个。对于Mongrel中的队列，他们由Ezra的一个讲演中受到了启发。
问：这么说当你重启的时候你便杀掉了所有的mongrel进程，或是作了一次“回滚”？有些公司就是采取了回滚的方式来解决问题。
答：他们关掉了所有进程，因为队列在mongrel之中，若他们那样做就会填满了所有队列。他们这样尝试过，但得到的结果却是乱七八糟的。
问：怎样看待“Twitter是愚蠢的，因为他们没有采用ETag”这种说法？
答：他们确实在用ETag，但并不起作用，因为它们在末尾有一个显示消息请求时间的时间戳。Web流量的分块小得足以将其忽略不计了。Yahoo高性能小组（High Performance group）在演示中提到了它是无关紧要的。
问：ETag不会对API缓存有帮助吗？
答：只有在客户端执行它们时才可以，大多数情况下是没有帮助的。
问：下一步目标？
答：回调API有很大潜力。第三方的开发人员在打算做这件事。让我们期待着把。
我们热爱XMPP，并在和Jabber社区的人们一起努力通过一些很cool的新方法来使用Jabber以推进其发展。
评论:(0) Tags: Twitter 架构
Amazon的体系结构
分类: WebSite 浏览: 日期: 2007年11月24日
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的基础架构是他们的巨大核心竞争力。通过一些相对简单的底层服务，他们可以构建出非常复杂的应用。他们可以彼此独立地完成各个服务的增容，维护非并行系统的可用性，并在不需要修改大量系统配置的情况下，快速发布新的服务。
评论:(0) Tags: Amazon 架构
Facebook架构
分类: WebSite 浏览: 日期: 2007年11月24日
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日，微软宣布他们可能会收购Facebook的部分股份。据称Facebook被完全收购可能性不大，因为其创始人Mark Zuckerberg希望保持独立。
网站功能
墙（The Wall）
墙就是用户档案页上的留言板。有权浏览某一个用户完整档案页的其他用户，都可以看到该用户的墙。用户墙上的留言还会用Feed输出。很多用户通过他们朋友的墙，留短信儿。更私秘的交流则通过“消息（Messages）”进行。消息发送到用户的个人信箱，就象电子邮件，只有收信人和发信人可以看到。
2007年7月起，用户可以在墙上贴附件。之前，只允许文本内容。
礼物（Gift）
（Facebook礼物）
2007年2月，Facebook新增了“礼物”功能。朋友们可以互送“礼物”－－一些由前苹果设计师Susan Kare设计的有趣的小图标。礼物从Facebook的虚拟礼品店选择，赠送时附上一条消息。收到的礼物以及所附的消息会显示在收礼者的“墙”上，除非送礼者设定这个礼物是私秘的。另外，在墙的上方还有一个“礼盒”。用户收到的所有礼物都在礼盒中。公开的礼物显示送礼者的名字，私秘的礼物则显示“私人”。
另有一个“匿名”的选项。虽然所有人都可以看到礼物，但只有收礼者可以看到送礼者的名字和消息。这种礼物只在礼盒中，而不在墙上显示。
Facebook用户注册时免费获得一个礼物，以后送出每个礼物需要花费一美元。最初推出的礼物是有关“情人节”的。同年2月由此产生收入的50%捐献给Susan G. Komen乳腺癌基金会。之后，Facebook每天推出一款新礼物，大多数都是限量版，或只是限期供应。用户个人主页会显示每日礼物的广告。随着Facebook开放平台应用程序的出现，第三方开发的应用程序对1美元购买礼物的模式构成威胁。请注意，Zachary Allia（译者：一个第三方程序开发员）开发的“免费礼物”，与Facebook的官方礼物是不同的。
市场（Marketplace）
2007年5月，Facebook推出Facebook 市场。用户可以免费发布下列分类广告：卖二手货、租房、工作等。供求两方均可发布。所有Facebook用户都可以使用这个功能。目前是免费的。
捅（Pokes）
Facebook提供一个“捅（Poke）”的用户功能，用户可以给别人发送一个“Poke”。Facebook常见问题中这样解释：“Poke是你和朋友互动的一种方式。当我们设计这个功能时，我们觉得提供这么一个什么意思也没有的功能其时挺酷。用户们给Poke不同的解释。我们鼓励你给它你自己的解释。”实际上这个功能的目的只是让用户能引起别的用户的注意。尽管很多用户确实用这个功能来引起别的用户注意，或只说声“嘿“，但有些用户仍把它理解为“性”的意味。这个解释造成了一个很热门的Facebook小组的产生－－“Poke”够了，咱们干脆做爱吧。到2007年9月，这个小组共有二十五万用户。
有时朋友之间会进行一种被称为“Poke仗”的游戏－－两个用户间用“Poke”功能，互相Poke来Poke去。
另有一些衍生出来的新功能，如“X 我”，和“超级Poke”，让用户可以把Poke替换成任何动作。
状态（Status）
状态，让用户向他们的朋友和Facebook社区显示他们现在在哪里、做什么。Facebook让用户填入状态的提示是“（某某用户）正在。。。”，用户填入剩下的部分。在用户好友列表的“新近更新”区，显示这些状态。
活动（Events）
Facebook活动的功能帮助用户通知朋友们将发生的活动，帮助用户组织线下的社交活动。
开放平台上的应用（Application）
2007年5月24日，Facebook推出Facebook 开放平台。利用这个框架，第三方软件开发者可以开发与Facebook核心功能集成的应用程序。
最流行的应用程序包括：
顶级朋友：用户可以选择和显示他们最好的朋友
涂鸦板：一个图形效果的“墙”
我喜欢：一个社会化音乐发现和分享服务，包括音乐会信息和有关音乐知识的小游戏
甚至有象棋、拼字游戏之类的游戏出现。而第三方网站如进行Facebook应用数据统计的Adonomics，相关博客如AppRate、Inside Facebook、Face Reviews等等或应运而生或对Facebook应用青眼有加。
2007年7月4日，Altura 风投宣布“Altura 1 Facebook投资基金”，成为第一个只投资Facebook相关项目的风险投资。2007年7月10日，Bay Partners宣布成立“应用工厂（AppFactory）”，一个只投资Facebook应用的种子基金。
2007年8月29日，Facebook改变了他们对应用程序热度的衡量标准，更倾斜于那些有深度价值的应用。因为之前，衡量标准仅以用户数为标准，使得那些高度“病毒传播”（译者：指极易于在用户间口口相传）但没什么用处的程序排名很高。著名IT博客Valleywag曾批评Facebook 应用是“一大堆垃圾”。
截止2007年9月26日，共有超过4500个Facebook应用出现。
Facebook标识语言（Facebook Markup Language）
Facebook 标识语言是HTML的子集。Facebook应用的开发者可以用这种语言定制他们的应用程序的外观。
Facebook视频
与Facebook开放平台同时推出的，还有一个Facebook自己开发的应用程序－－视频分享。用户可以上传视频、通过“Facebook移动”上传手机视频，以及用摄像头录像。同时用户可以给视频中的朋友加“标签”。这一功能被认为会与MySpace的相关功能竞争。但Facebook的视频只能在Facebook网络内观看。然而，一段发表在Userscripts.org上的Greasemonkey代码让用户可以下载Facebook视频或将之转贴在其他网站。
Facebook的域模型
下图用UML类图的形式，显示了Facebook系统所管理的信息。它提炼出了Facebook数据库中的实体、关系、字段。
比如，图中显示了有关工作、学校、信用卡、显示用户名等的字段。（黄色方框代表类）
请注意该图为概念类图，而不是具体实施的细节。如欲了解更多数据模型的细节，请参考Facebook查询语言（FQL）－－一种类似SQL的查询语言的相关资料。
技术构架
Facebook使用LAMP（Linux、 Apache、 MySQL、 PHP）作为技术构架。Facebook的一个技术构架工程师Steven Grimm在博客中写到：
几乎我们所有的服务器都运行开源软件。我们的Web服务器是Linux，Apache和PHP。我们数据库是MySQL。我们使用memchached来保证网站的快速反应。一些后台应用Python、Perl和Java，以及一些gcc和Boost。程序员用Subversion和git来进行代码管理。还有很多－－象很多网站一样，从头到脚都是开源软件。
收购传闻
2006年随着MySpace被新闻集团收购，关于Facebook会被一家大的媒体公司收购的传闻出现。Facebook的创始人Zuckerberg说过他不想出售公司，并否认了这些传闻。他已经拒绝了九亿七千五百万美元左右的收购价格，不知还有谁愿意出高出这个的价格收购Facebook。分析师Steve Rosenbush猜测是维亚康姆（Viacom）。2006年9月，Facebook和Yahoo开始进行关于收购的认真谈判，价格约10亿美元。同年10月，随着Google以16亿美元收购YouTube，有传闻说Google开价23亿美元欲从Yahoo手中抢购Facebook。
Facebook的董事Peter Thiel暗示，根据2015年10亿美元收入的估计，Facebook内部的估值是80亿美元。这一估值依据对与Facebook用户构成类似的维亚康姆的MTV品牌的估值。
2007年9月，微软向Facebook示好，欲以3-5亿美元投资该公司5%的股份。（译者：这使得Facebook的估值在60-100亿美元左右）其他公司，如Google也表示过类似兴趣。
注：原文来自英文维基百科“Facebook”条目
译文来自《译言－Facebook启示录小组》
评论:(0) Tags: Facebook 架构
Google架构
分类: WebSite 浏览: 日期: 2007年11月24日
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有限时，压缩是一个好的选择。
评论:(0) Tags: Google 架构
eBay的架构
分类: WebSite 浏览: 日期: 2007年11月24日
eBay的架构
文/Todd Hoff 译/于晓潮
有谁不想知道eBay是如何开展业务的呢？成为世界上最大的高负荷量的网站之一，这个过程可不容易。创建这样一个庞然大物，需要真正的工程学：在网站的稳定性、运转速度、性能和成本之间达到一个平衡。
你可能无法模仿eBay增容系统的方法，但是其中的问题和可能的解决方案是值得我们学习借鉴的。
平台
Ÿ Java
Ÿ Oracle
Ÿ WebSphere
Ÿ 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、连接池等。
Ÿ 不要害怕构建满足你的需求并按需求发展的解决方案。每一个现成的解决方案都不可能完全让你高枕无忧，你必须自己走完剩下的路。
Ÿ 随着业务的成长，运行控制成为增容的越来越大的一部分。如果运行一个即时使用的系统，你必须考虑如何升级、配置和监视数以千计的机器。
Ÿ 架构进化——任何一个成长中的网站面临的主要挑战。在保持现有网站运行的同时，需要有改变、改善和开发新系统的能力。
Ÿ 一开始就过于担心可增容性是错误的。因为分析和担心可能永远也不会发生的流量而陷入恐慌是不必要的。
Ÿ 完全不考虑可增容性是不对的。事情永远不会做完，系统总是在进化和改变，你需要建立一个有能力应付架构进化的组织。并且一开始就把这些期望和能力融入你的业务中去，不要让人和组织成为你网站瘫痪的原因。不要认为系统一开始就应该是完美的，一个好的系统是在解决真正的问题和担忧中成长起来的，期待改变，适应改变才是正确的态度。
评论:(0) Tags: eBay 架构
赞助商链接
网站分类
赞助商广告
文章归档
- 2010 June (2)
- 2010 May (3)
- 2010 April (10)
- 2010 March (2)
- 2009 November (1)
- 2009 October (1)
- 2009 September (2)
- 2009 August (1)
- 2009 July (5)
- 2009 June (1)
- 2009 May (1)
- 2009 March (6)
- 2009 February (4)
- 2009 January (2)
- 2008 December (2)
- 2008 November (6)
- 2008 October (9)
- 2008 September (12)
- 2008 August (25)
- 2008 July (18)
- 2008 June (29)
- 2008 May (15)
- 2008 April (31)
- 2008 March (20)
- 2008 February (21)
- 2008 January (10)
- 2007 December (41)
- 2007 November (18)
- 2007 October (11)
- 2007 September (6)
- 2007 August (24)
- 2007 July (2)
- 2007 June (4)
- 2007 April (31)
- 2007 March (27)
- 2007 February (17)
- 2006 December (31)
- 2006 November (18)
- 2006 October (28)
- 2006 September (46)
- 2006 August (38)
- 2006 July (25)
- 2006 June (42)
- 2006 May (32)
- 2006 April (36)
- 2006 March (93)
- 2006 February (79)
- 2006 January (55)
- 2005 December (120)
- 2005 November (31)
- 2005 October (65)
- 2005 September (91)
- 2005 August (96)
