大型网站架构不得不考虑的10个问题

这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。

 

这里讨论一下大型网站需要注意和考虑的问题

 

1、海量数据的处理

 

众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。

 

2、数据并发的处理

 

在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。

 

另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。

 

3、文件存贮的问题

 

对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。

 

也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。

 

所以我们不得不承认，文件存贮是个很不容易的问题

 

4、数据关系的处理

 

我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。

 

5、数据索引的问题

 

众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。

 

索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题，

 

6、分布式处理

 

对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。

 

7、Ajax的利弊分析

 

成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。

 

8、数据安全性的分析

 

对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们知道的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空间和qq空间的群发了。大家愿意试试，实际上并不是很难。

 

9、数据同步和集群的处理的问题

 

当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题

 

10、数据共享的渠道以及OPENAPI趋势

 

Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。

 

 

案例分析：电子商务网站（淘宝网）的系统架构解析—淘宝网

 

淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。

 

　　对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。

 

　　操作系统

 

　　我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已¾¬走过了十七个年头，在PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。

 

　　应用服务器

 

　　在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是IBM的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目前JEE应用服务器的比较。这边就不在赘述。

 

　　在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的唯一选择。那个时候虽然也有一些其他的开源的Web Server，但是从功能和稳定性上来说都无法和Apache相对。在今天来说，Lighty也会是一个非常好的选择。Lighty是一个非常轻量级、占用内存资源也比较少的Web Server。虽然功能上没有Apache强大，但是在不少场景下，性能是非常出色、强于Apache的。而微软的IIS，就只能工作在Windows的系统上了。并且使用IIS的话，基本上也就是选择了ISAPI、ASP或者ASP.NET进行Web应用的开发了。

 

　　数据库

 

　　说完了我们采用的操作系统、应用服务器、WebServer后，下面就来谈谈我们的数据库。在淘宝网的应用中，采用了两种关系型数据库管理系统。一个是Oracle公司的Oracle 10g，另外一个是Sun MySQL的MySQL。Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。

 

　　一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统、搜索、分布式框架、缓存系统等等。在淘宝网，这些系统都是自主开发的，没有采用目前商业的或者开源的产品。有些系统，会存在着一些开源的产品或者商业产品。但是，考虑到淘宝网自己的需求和大并发量的压力，这些系统都选择了自主开发。开发框架

 

　　前面谈的都是系统级的产品，下面我们说说开发框架的使用。可能有朋友想问，作为一个如此大规模的网站，淘宝网的Web展现层采用的是什么框架，是怎么实现的呢？曾¾¬也有到淘宝的应聘者问过我这个问题，他问我说是不是用的struts。我告诉他说不是的。其实淘宝网的Web展现层的框架用的不是struts，不是webwork，不是spring mvc等等。淘宝网的Web展现层的框架用的是集团内部自主开发的一套Web框架。这个框架能够解决一些其他Web框架不能解决的、在淘宝的应用中又会出现并需要解决的问题。在淘宝的多个应用中，也采用了一些开源的框架，比如Spring、iBatis、jBPM、Hessian、Mina等等。这些开源软件的采用为我们构建应用系统提供了很大的帮助。

 

　　采用开源软件构建系统，我想有两个很大的好处：

 

　　一个是降低成本。假设你有1000台应用服务器，如果你每台服务器上采用的不是JBoss AS或者其他开源的软件，而是使用商业的Oracle BEA的Weblogic或者IBM的WebSphere，那么为这1000台机器的应用购买License的费用是非常高的。

 

　　另外一个好处(我觉得最大的好处)是你可以看到软件的源码，你可以研究了解软件内部的工作过程、原理。这对于应用设计、开发、查错、优化都是非常有帮助的。

 

　　淘宝网的开源观

 

　　对于开源软件的应用，有些人可能担心质量的问题，有些人可能担心软件本身发展更新的问题，等等。对于质量的问题，我想现在很多的开源软件尤其是一些很著名的开源软件都有很完善的组织，有完善的开发、测试、发布流程。在一个新版本完成前，会有多次的测试版本发布，最后才是正式版。这和商业软件是一样的。并且因为代码公开，反而更加的容易发现错误，提高质量。至于第二个问题，我想跟第一个问题一样，关键是组织和规划而不在是否开源，并且在很多著名的开源软件背后，会有厂商在进行支持。软件本身的发展应该是不会成为问题的，不太会出现软件突然停止发展的情况。

 

　　在今后的发展中，我们还是会一如既往的关注开源软件的发展，也还会根据需要采用不同的开源软件。在选择一个开源产品的时候，我会考虑以下几点：

 

1. 这个软件目前的功能和它的RoadMap

 

2. 软件本身的架构

 

3. 该软件开发的活跃度

 

4. 该开源软件是否是遵守该领域内的国际规范的

 

5. 在同类产品中，要挑选有比较优势的。并且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其他软件的移植。

 

对于企业级系统、互联网应用来说，采用开源软件不仅可以降低成本，更重要的是能够真正了解软件的内部工作机制。还可以在现在的基础上进行增强和定制，也能够从开源软件中借鉴到很多好的设计和实现。希望国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者能够成为一些开源软件的贡献者。而作为淘宝网，我们也会非常积极的参与到开源的活动中，也会努力为开源的发展做出我们应有的贡献。

 

中小型电子商务网站架构

 

一个小型的电子商务网站，例如日交易量5万订单以下，或者说每天差不多五千万个pv左右。我们可以讨论下，整个架构应该如何设计。

业务分离，域名分离

现在好的电子商务网站都是按照业务分开，细化每个业务线。这样有利于系统的扩展，也有利于对系统的维护。例如:商品可以独立出来，交易独立，用户独立等等。各个系统之间需要交互的信息可以通过远程传输来实现。在一个比较有规模的团队中，最好有个组专门来维护一个独立的业务，有利于团队对业务渗透和业务的维护。

由于业务分开，系统分开，当然在域名上也应该分开， 例如：整个网站的域名为www.abcd.com。那商品系统域名就应该为item.abcd.com。交易可以使用order.abcd.com。这样的好处显而易见，在访问上就可以分流。很多公司是通过www.abcd.com/item这样处理，所有流量都统一进入www.abcd.com然后再处理，这样对主服务器压力就非常大。这个道理很简单。就像一个口小身大的瓶子一样，水很难灌进去。现在很多电子商务公司都没有意识到这个问题。这些简单的方法都没有注意到。

 

独立搜索引擎

最近几年很多人都习惯于通过搜索找到自己喜欢的东西，一个好的网站一定要有独立的搜索引擎，分词要好，实时数据更新最好，最好做成分布式搜索。为了能够准确定位商品，对商品一定要有非常完善商品属性，例如：我在搜索一件红色 夏季的衣服，我就会输入红色 夏季进去，如果商品没有颜色属性，没有季节属性，就无法定位到我想要的商品上面。除了完善的商品属性，还应该建立比较好的推荐搜索，保持关键字推荐，搜索结果推荐。

搜索是一个非常庞大和奥妙的课题，本人知之甚少，也不好班门弄斧。我是做java出身，经常使用Lucene也很喜欢Lucene。很多人都误会Lucene做搜索不够强大，其实技术要做好，一样很强大。twitter就是使用Lucene做搜索，也比较强大了，熟能生巧。

 

数据架构

数据架构范围太大，太广，起这个标题有点大题小做了。其实一个比较大的系统，最起码的数据架构要求就是数据库拆分。垂直划分很简单,就按照业务分成不同的数据库。另外一种是水平划分，把同一个业务数据划分到不同的数据。到最后就应该是可以考虑读写分离，读写分离就好像高速公路一样，左右车道分开，中间有隔离带，当然速度就上去了。

在我的博客上有一篇文章主要讲读写分离。

 

缓存数据

缓存是我最喜欢的的技术，也是目前很多系统都会使用到的技术，为了提高系统性能，提高速度，缓存使用必不可少。最有名的莫过于memcache啦，淘宝的tair也很不错。这些都是大型分布式缓存，其实如果是小型系统，可以自己开发缓存，可以根据业务要求，把对应的数据放到内存中，就可以了。其中技巧很多，一切都以合适场景为主。

还有另外一个现在非常流行的技术就是cdn缓存，提供商很多，淘宝比较牛，自己开发cdn，而且架构也非常好。

说到缓存还有静态页面缓存，浏览器客户端缓存。等等，这些都可以在一定程度上提高性能。

 

异步通信系统

在一个分布式系统中，系统之间交互必不可免，就会涉及到很多系统之间消息同步，状态同步，消息记录等，一个好的异步消息系统，可以很好提高系统的强壮性和扩展性。例如为了保证数据或者状态一致性，通过消息系统就可以保证数据一致。在交互时，向消息队列中提交对象，再进行系统之间状态交互。就算系统状态 失败消息中也保证了对象的存在。在上面提到的读写分离中，就可以通过异步消息系统做数据同步。

 

完善的系统监控

 

在一个比较大型的分布式环境中，一定要有监控系统。例如：流量监控，硬件监控，系统性能监控，如果再深入的话，可以对某个页面进行监控，设置页面的其中一块进行监控。特别在硬件监控或者性能监控时如果发现异常，就应该预警，这样也好防范于未然。

 

一个好的系统其实应该从扩展性、安全性、性能和可靠性来考虑，其中三言两语说不完。架构适合就好，可以采用先行之而后优。