大型网站的服务器架构设计-2

大型网站的服务器架构设计-1

上述架构对于一般中小型商用网站已经足够。在用户规模达到100万人左右，随着网站流量不断增加，就会出现网站性能不佳的问题，一般表现为：

• Database Loading 过重，CPU Loading 始终维持在80%以上；
• 存放图片及静态资源的硬盘Loading 过高，显示比较慢；
• 前端网页容易出现 timeout 的错误信息；

进入成长期

遇到上面的问题，其实是好消息，表示网站已至成长期，一般网站会进行下列系统优化，并横向扩展Web Server。

1. 数据库优化

Query 优化、Index 优化，将负荷重的Table 进行反范式规范重新设计，以减少Database的负荷。

建立Master/Salve 数据库，分散Master 数据库服务器的Loading，将读写数据库动作分离，Master DB Server 只负责Insert / Update / Delete 等等更新操作和复制，Salve DB Server 负责Query操作。

提升数据库Server的硬件能力，如增加 CPU / RAM等等，将32bit 版本转为 64bit版本。

2. 分散式存档存储

建立多个File Server，写hash function 将上传的图片及资源文件平均分散到 File server上的文件夹。

3. 建立 Cache

可是有ASP.NET 的Cache 存储数据集，或使用PHP APC 建立 opcode Cache，将不经常变化的动态网页区块转成静态Cache 用户控件。

4. 代码优化

减少的大量的数据库访问操作，可使用 Connection pool 加快链接数据库的速度，使用MVC 架构等等。

流量大爆发期

到这个阶段，说明前面的努力没有白费，而技术人员每天几乎都要熬到半夜才能回家，调整代码性能及硬件扩展的都做了。但此时公司业务和流量爆炸性成长，网站会员达到 200 万，也该月的成长速度，半年内会达到 1000 万人，系统根本无法支持。

此时系统会发生的问题：

由于网站流量很大，导致存放图片资源的硬盘不堪重负，读取及写入的量已超过其读写物理限制，而变得十分缓慢；

数据库性能的提高已经不能通过增加Slave DB 来解决了，若要转为大型数据库中心，费用相当高；

IDC 带宽成本惊人，特定促销或事件，会导致网站灌爆；

Facebook、Youtube、Twitter、Myspace 这些流量快速成长的小型公司，都有遇到爆炸性流量的問題，而且也都乐于分享解決方式，我们可以在网上找到许多资料。不同类型的网站，其要求也可能不一致。如 SNS 网站对速度要求高，对准确性要求不高；而电子商务网站，对速度和准确性都有要求。此时，可能一般的数据库 或 SAN 存储架构都无法满足其快速读取大量数据的需求，因此产生了目前称为云端运算的技术，这些网站已不是上百台Server，而是拥有成千上万的Server。此时，不要担心资金问题了，如果网站达到这个境界，一堆人排队送钱过来。

下面归纳一些解决方案：

1. Memory Cache

http://memcached.org/ 这个不同于 ASP.NET 的Cache，ASP.NET的Cache 分散在不同的Server上，不能共用也不能相互更新。在数据库和AP Server中间架设 Memcached server，将访问频率高的信息Cache在Memory中，会提高读取性能。

可以将比较老旧的Server 或CPU 等级不高的Server 串接，建立Memcached server 群组，在Memcached client 端建立 consistent hashing 机制，来分散各个cache 值到各台Server，使用consistent hashing 可以让日后增加新Server时，不会导致cache存放位置大乱，而必须重新到数据库读取，造成数据库瞬间瘫痪。

架构如下，图片来源：Designing and Implementing Scalable Applications with Memcached and MySQL

其原理可参考下文：http://forum.homeserver.com.tw/index.php?topic=5.0

当数据库过大时，还可以用DB Sharding的方式，将Master DB 依Customer ID 切成多个Shard，来增加效率，有兴趣的可以参考下面的文章：Database Sharding At Netlog

2. NoSQL

除了一些固定的数据增长，时常需要变动的数据如个人Profile、Friend List … 等等，还有一些其他辅助性数据，如留言…. 等等，这些数据不停的增长，人一多，数据量更大，这些数据由关系型数据库处理相当耗时，且意义不大，因此就有一些俗称的NoSQL的Solution产生。

其概念为，如太多人读取单一硬盘的大量数据，超过了硬盘的 IO 处理能力怎么办？有人想到吧数据切成多个Block 碎片，复制并分散到3个不同的存储节点，有需求的时候在从这些节点取出组合，这样就分散了单一硬盘的使用量，并且效率更好，以这样的概念建立的新的数据库系统，并衍生出新的数据库形态。

目前主流的平台有 –

Google GFS / BigTable – Google开发并使用在多个服务上；

Hadoop HDFS / Hive / Hbase — Yahoo及Facebook 都使用Hadoop , Facebook使用HIVE做Data warehouse；

Apache Cassandra — Facebook提出的open source架构，目前使用者为Digg，Twitter本来计划使用，于2010年7月暂停了转移计划；

HyperTable — 百度使用Hadoop HDFS结合HyperTable 的技术，用Mapreduce做搜索引擎的核心计算。

Kyoto Cabinet / Tokyo Tyrant — 日本最大社群网站MIXI就是使用该架构，其他用户有Plurk及Scribd， Plurk以此架构衍生出新的opensource架构LightCloud；

Amazon Dynamo — Amazon 使用的key-value 数据库，主要应用在储存best seller lists, shopping carts, customer preferences, session management, sales rank, and product catalog…等数据，目前并没有对外开放使用。

Voldemort — Linkedin 使用该key-value数据库；

MongoDB – Foursquare为用户代表，与key-value形态的DB不同的是，MonogoDB支持document形态的数据，如XML存储，想必Foursquare 用户的check-in 数据全存储在MongoDB上了。

这里的Database 大都以 key-value 为存储方式，因此无法用关系型数据库的标准语法来读取数据，也不支持原始数据的update，但这样的架构很适合存储超大量的数据，如Twitter每个人的Timeline、Facebook 上的News Feed、搜索引擎Crawl 的Web 资料、Web game的Notification … 等等，这类数据有如下特性：

1. 不断的大量数据增长；

2. 不停在Add new 新数据，但不必更新（update）；

3. 随时需要导出大量的数据；

如果网站的数据有上述特性，可以考虑这个Solution，想必对性能及规模扩张有很大的帮助。

其他相关NoSQL 信息请参考 http://nosql-database.org/

3. CDN

当网站使用了Memcached 及 NoSQL DB 改善了数据处理性能问题后，大量的图片等静态资源还是会有性能上的瓶颈，这样就需要使用CDN（Content Delivery Network）的解决方案来改善了。

CDN 公司大都有超大规模的机房遍布各地，可以帮助其客户在不用升级设备的状况下，使用其超大规模的架构，把内容散播出去，客户完全不用担心Web Server Loading的问题，其技术原理如下：

• CDN 会定时到客户网站，进行复制并散播到其网络节点去；
• 客户需要把Cache内容的DNS位置指向CDN；
• 使用者连上客户网站时，其实连到CDN 最近的Cache节点，不用绕过多层的网络节点；

Youtube 及 Facebook 都有使用到CDN服务，Facebook的图片就是用CDN来加速，但由于CDN费用的关系，Facebook 建立了新架构HayStack 来降低对CDN的依赖。

结 论

我们可以发现，这波的超大型网站都没有使用商用平台，一开始也都不用高档的商用Server，所有的架构都有论文基础，并且愿意Open source 出来，Startup 公司思考的是用最经济的方式达到最高效益，而非完全依赖商用平台花钱了事，这种研究精神十分值得敬佩及学习。不像国内的某些公司，在谈到如何解决网络超大流量时，一副无可奉告，是高级机密的态度 …… 可见国内对于分享技术这块还有很大的进步空间。

非常感谢台湾朋友提供这一篇有用的文章。

原文链接：

巨型网站的分散式架构设计（云端运算的基础）