大型互联网架构浅谈

作者： John Waken
转载请著明： http://www.cnblogs.com/john-d/archive/2010/04/16/1713744.html



首先声明，本人系在校学生，无任何互联网架构经验，在此只是想写点自己的看法，如有不妥欢迎各位朋友指正。

几年来中国网民数量激增，已达到3亿多，热门网站在线人数也飙升，百度和腾讯仅凭借内地市场就挤进了Alex排行榜前十名，腾讯更是创下了同时一亿人在线的记录，没办法中国人多啊，但是一想到中国互联网公司由于文化和政策的原因不能在全球大放异彩也有点儿遗憾。这么多的在线请求，网站的压力可想而知了，不仅如此，公司还要保存大量的数据（这年头数据就是信息，信息就是财富）。这就要求网站能提供可靠的高并发访问、支持海量数据存储，同时互联网公司要么很早死翘翘要么大火，所以公司的架构要适应公司的发展，也就是具有很强的伸缩性。互联网公司的架构特点总结如下：
1、支持高并发访问
2、支持海量存储
3、高可靠性
4、可伸缩性
注意这几个特点不是独立的，而是会相互影响。

怎样才能达到以上要求呢？当然升级硬件可以解决一部分问题，但是更好的方法是采用良好的分布式架构。google可以说是采用分布式架构的典型了。Google可是相当抠门，连像样的服务器都舍不得买，用的是烂PC，但是人家有技术啊，人家就是有能耐用烂PC做超级计算机。当然国内的大型互联网公司肯定也采用了分布式架构，集群计算等。

什么是分布式系统呢，我的理解很简单，如果多个个体相互协作去解决一个问题，那么他们就组成了分布式系统。系统外部只知道这个系统能解决什么问题，对系内内部的组成和协作方式一无所知。

在上《操作系统》时，我们都被告知计算机系统分为若干层。同样，分布式系统也可以体现在各层，下图是我对单个计算机系统的分层。

         

这个分层和书上的有点儿不同，因为我更关注互联网行业，所以针对互联网应用提出自己的分层方法。
硬件： 这个就是那一大堆你看得见摸得着的东西咯
操作系统： OS最重要的作用是给上层程序提供运行环境，而不注重文件系统。
字节数据存储： 这个相当于操作系统的文件系统，提供无意义的字节存储
结构化数据存储： 这个相当于数据库了，不过不一定提供SQL查询
应用： 利用下层数据的计算程序

终极解决之道就是在硬件上提供分布式解决方案，不过这几乎不可能，也不值得，否者Berkeley也不必将TCP/IP协议分四层。

利用分布式的操作系统，把传统操作系统的功能分解开来，这个是可行的，如AT&T实验室开发的Plan9操作系统。不过对于整个行业来说不现实，IT业舍得丢弃巨大的Unix/Linux资源吗？就算Plan9一样是Ken Thompson大神设计的也不行啊！

所以还是在操作系统之上采用分布式比较靠谱。在字节存储层已经有很多分布式案例，如google的GFS文件系统，hadoop项目中的HDFS，Kosmix的KFS。这些文件系统起到了这样一个效果，把各个单独的计算机的磁盘统一起来形成一块巨型磁盘，在上面存储毫无意义的字节数据。

我们可以在分布式的字节存储层之上再采用分布式的数据库。也可以只采用分布式的数据库，只不过这样的话在结构化存储层要做更多的事。在结构化存储层分布式就是使用分布式数据库，如google的BigTable，Hadoop项目中分离出来的HyperTable，还有Amazon的Dynamo等

应用层上的分布式最著名的当然就是MapReduce的计算框架了。写到这里，我发现我的思路被Google左右了。

还有一点要注意的是，每个数据存储层之上都可以有个缓存，我们可以在缓存上分布式。比如很多网站采用MySql+memcached，并没有采用分布式的数据库，而是用了个分布式缓存系统，但是我觉得还是在结构化存储曾采用了分布式架构。

不管在哪一层分布式，都有共同的特点，最著名的恐怕就是CAP理论了，就是任何一个分布式系统都不能同时满足consistency、availability、partition tolerance。所以在设计分布式系统时，我们要根据应用需求来做出选择，然后采用一些算法（如广泛使用的一致性哈希算法、CouchDB采用的版本标注方法）来满足这些特性。

其实我知道就算写了这么多，都是虚的，还是对分布式一点儿都不懂。我的目的是总结自己的想法，对分布式开源项目有个总体的把握，这样我起码能知道自己在哪儿，不会云里雾里。

p.s: 几乎所有的分布式存储系统里都会实现一个基于reactor模式的事件驱动机制，Linux上一般采用NonBlocking+IO Multiplexing，所以如果您想看一些开源代码时，应该先熟悉Linux网络编程，看看怎样利用NonBlocking+IO Multiplexing实现一个基于reactor的事件驱动框架。