[置顶] 轻掠Web 图片服务器
本文转自:http://www.dbanotes.net/web/web_image_server.html
现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。
事关图片的存储
把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。
如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。
独立，独立的服务器
无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。
如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。
独立，独立的域名
如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。
前几天有个朋友在线上问我，”一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉的留言】
2009/02/19 23:10 | 作者: Luke Lai | 同意转载, 转载时请以超链接形式标明文章原始出处，谢谢!
网址: http://www.it-infra.cn/Ultradns_vs_IP_Anycast/
今天又收到Ultradns发过来的每月Intenet infrastructure的邮件，其中有条挺有意思的，是关于IP Anycast，中文翻译应该叫IP任播吧。曾经跟Ultradns相关的技术经理沟通过Ultradns的架构，感觉那哥们跟偏重于商务，技术都是美国那边控制着，包括在中国建点也是美国那边直派技术人员过来，其实Ultradns的技术还是挺牛。
听说销售最好的业务员没有比较最差的业务员多打几个电话，这里可以看得出来，销售最牛的业务员一定有自己实现的方法，一定跟其它的业务员有区别。随着对Ultradns的了解，觉得Ultradns还是真有自己的一套。它的基础架构跟一般我们从书中上学到的DNS架构完全不一样。其中就是核心架构IP Anycast + BGP。
关于IP Anycast简单解释Neustart公司这么说的：
UltraDNS在五大洲已经搭建14个公共节点，虽然在国外鼎鼎大名,但在中国没有什么名气。我想也是跟UltraDNS的基础架构有一定的关系，这种架构第一要求拥有自己的公网IP地址段。第二要跟该国家的主要运营商有BGP广播。目前国内运营部不像国外那么好商谈，坐地起价，漫天要价，而且BGP震荡且不提供任何SLA保证。呵呵，Ultradns也正是因为这种架构“枷锁”在中国难以到处开花，上次听说Ultradns已经在香港开了一个Node，提供一些国外网站在华业务的支持。
呵呵，乱七八糟说了一通UltraDNS，其实IP Anycast还可以应用在企业内部作为DNS高速及冗余可靠方案，回头有时间再写点。
简单的UltraDNS结构图，没有搜到详细些，但也有想象空间，呵呵，版权所有@NeuStart
参考资料：
UltraDNS: http://www.ultradns.com/technology/overview.html
IP Anycast: http://en.wikipedia.org/wiki/Anycast
[置顶] 某中大型网站系统架构--实战案例研究
网址: http://www.it-infra.cn/Web_Site_Architecture
你是否一直考虑网站架构要有冗余性，安全性? 同时又有经济性呢？
你是否经历过痛苦的思索网站的架构到底怎么样还算合理？
怎么保证关键业务能够冗余，而其它业务可以选择冗余或不冗余。资金紧张的情况下 可以选择不冗余，一旦资金到位，系统架构又具备一定的灵活性，从而非常方便增加冗余设备？
相信每个网站的系统网络部门都经历了网站系统架构的艰苦摸索，从一开始只有简单的几台服务器，随着业务增长，到了上百台服务器，但从未停止过探索。下面我想把从几次实战的中实验贡献出来，该架构已经在好几个较大的网站已经实施过，其中一个已经运行了4~5年，其中经历过无数次业务高峰的考验。
网址: http://www.it-infra.cn/SSL_Troubleshooting/
Troubleshooting SSL
SSLDUMP: http://www.rtfm.com/ssldump
– 提供SSL解密及详细命令
HTTPWATCH: http://www.httpwatch.com
– 在浏览器中安装为插件
SSLDUMP解密前(Application Data)：
SSLDUMP解密后(Application Data)：
增长的访问量给社区网络的技术体系带来了巨大挑战。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月瘫痪事件的地理上分布式架构。
