《大型网站架构技术方案集锦-具体内容》由会员分享，可在线阅读，更多相关《大型网站架构技术方案集锦-具体内容（20页珍藏版）》请在金锄头文库上搜索。
1、1大型网站架构技术方案集锦-具体内容PlentyOfFish 网站架构学习采取 Windows 技术路线的 Web 2.0 站点并不多，除了 MySpace ，另外就是这个 PlentyOfFish。这个站点提供 Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人 Markus Frind）的 站点价值 10 亿，估计要让很多人眼热，更何况 Markus Frind 每天只用两个小时打理网站-可操作性很强嘛。之所以选择 Windows .NET 的技术路线是因为 Markus Frind 不懂 LAMP 那一套东西，会啥用啥。就这样，也能支撑 超过 30
2、00 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于 PlentyOfFish 架构的细节。记录一下感兴趣的部分。带宽与 CPUPlentyOfFish 比较特殊的一个地方是 几乎不需要 Cache，因为数据变化过快，很快就过期。我不知道这是因为 ASP.NET 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过 CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了 30% 的 CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。负载均衡微软 Windows 网络负载均衡(Network
3、Load Balancing) 的一个缺陷是不能保持 Session 状态(我没有用过这玩意儿，不能确认 )，价格也不便宜，而且复杂；网络负载均衡对 Windows 架构的站点又是必须-IIS 的总连接数是有限制的。PlentyOfFish 用的是 ServerIron (Conf Refer)，ServerIron 使用简单，而且功能比 NLB 更丰富。 数据库一共三台 SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器。因为 Cache 没啥用，所以要花大力气优化 DB。每个页面上调用 DB 次数越少越好，越简单越好，这是常识，
4、不过不是每个人都体会那么深而已。微软好不容易找到了一个宣传案例，所以在 Channel 9 上有一个 PlentyOfFish 的访谈。PlentyOfFish 取自天涯何处无芳草 (Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。-EOF-2YouTube 的架构扩展在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。Kyle Cordes 对这个视频中的内容做了介绍。里面有不少
5、技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)简单的说 YouTube 的数据流量, 一天的 YouTube 流量相当于发送 750 亿封电子邮件., 2006 年中就有消息说每日 PV 超过 1 亿, 现在? 更夸张了 ,每天有 10 亿次下载以及6,5000 次上传, 真假姑且不论 , 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 有这个规模 . 但技术上和 YouTube 就没法子比了.Web 服务器YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI
6、模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)视频视频的缩略图(Thumbnails) 给服务器带来了很大的挑战。每个视频平均有 4 个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack
7、 Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 迷你 Cluster 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些漏网的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。数据库YouTube 用 M
8、ySQL 存储元数据-用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是 分区,这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章, 应用程序控制查找机制)3YouTube 也用 Memcached.很想了解一下国内 Web 2.0 网站的数据信息,
9、有谁可以提供一点 ?-EOF-WikiPedia 技术架构学习分享维基百科(WikiPedia.org )位列世界十大网站，目前排名第八位。这是开放的力量。来点直接的数据： 峰值每秒钟 3 万个 HTTP 请求 每秒钟 3Gbit 流量, 近乎 375MB 350 台 PC 服务器(数据来源)架构示意图如下：Copy Mark BergsmaGeoDNS在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? A 40-line patch for BIND to add geographical filters support to the existent views
10、in BIND, 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的-面向各个国家，各个地域。负载均衡：LVS4WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.图片服务器:LighttpdLighttpd 现在成了准标准图片服务器配置了。不多说。Wiki 软件: MediaWiki对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶
11、颈在哪里，看这样的图树展示一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。 Cache! Cache! Cache!维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的 Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。 数据库: MySQLMediaWiki 用的 DB 是 MySQL. MyS
12、QL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。 复制、读写分离. 应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。参考文档：Wikimedia architecture （ PDF)Todd Hoff 的文章-EOF-Tailrank 网站架构每天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。5专门爆料网站架构的 Todd Hoff 对 Ke
13、vin Burton 进行了采访。于是我们能了解一下 Tailrank 架构的一些信息。每小时索引 2400 万的 Blog 与 Feed，内容处理能力为 160-200Mbps，IO 写入大约在 10-15MBps。每个月要处理 52T 之多的原始数据。Tailrank 所用的爬虫现在已经成为一个独立产品：spinn3r。服务器硬件目前大约 15 台服务器，CPU 是 64 位的 Opteron。每台主机上挂两个 SATA 盘，做 RAID 0。据我所知，国内很多 Web 2.0 公司也用的是类似的方式， SATA 盘容量达，低廉价格，堪称不二之选。操作系统用的是 Debian Linux
14、。Web 服务器用 Apache 2.0，Squid 做反向代理服务器。数据库Tailrank 用 MySQL 数据库，联邦数据库形式。存储引擎用 InnoDB， 数据量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些 多核模式下互斥锁的问题(This Bug?)。到数据库的 JDBC 驱动连接池用 lbpool 做负载均衡。MySQL Slave 或者 Master 的复制用 MySQLSlaveSync 来轻松完成。不过即使这样，还要花费 20 的时间来折腾 DB。其他开放的软件任何一套系统都离不开合适的 Profiling 工具，Tailrank 也不利外，针
15、对 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是开放的。Tailrank 的一个比较大的竞争对手是 Techmeme，虽然二者暂时看面向内容的侧重点有所不同。其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。从现在来看，Tailrank 离预期目标还差的很远。期待罗马早日建成。-EOF-6LinkedIn 架构笔记现在是 SNS 的春天，最近又有消息 传言新闻集团准备收购 LinkedIn。有趣的是，LinkedIn 也是 Paypal
16、 黑帮 成员创建的。在最近一个季度，有两个 Web 2.0 应用我用的比较频繁。一个是 Twitter，另一个就是 LinkedIn。LinkedIn 的 CTO Jean-Luc Vaillant 在 QCon 大会上做了 ”Linked-In: Lessons learned and growth and scalability“ 的报告。不能错过，写一则 Blog 记录之。LinkedIn 雇员有 180 个，在 Web 2.0 公司中算是比较多的，不过人家自从 2006 年就盈利了，这在 Web 2.0 站点中可算少的。用户超过 1600 万，现在每月新增 100 万，50 会员来自海外( 中国用户不少，也包括我).开篇明义，直接说这个议题不讲监控、负载均衡”等话题，而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ，关键 DB
