冰冻三尺非一日之寒——大型网站架构演进

阅读更多

《大型网站系统与Java中间件实践》试读后感

 

当下载了《大型网站系统与Java中间件实践》试读章节,看到其中唯一的一章第2章的标题,并简略地扫了一遍小节标题之后,我立马就想到——这绝对又是某位淘宝牛人写的书。

为什么这么肯定呢?因为前年我曾参加了公司组织的一场关于架构的系列讲座,请的讲师正是出身淘宝,以前做过架构后来转做讲师的。而在那场系列讲座中,一条重要的主线正是以淘宝网站发展历程为蓝本的“大型网站架构演变和知识体系”。

可以说,那是我有史以来听过的最过瘾的一场讲座,收益也颇大,从此也对阿里系架构和技术更加崇拜和着迷。所以当看到本书的试读章节时,有一种说不出的亲切感。然后在网上搜索了作者,果然是淘宝的大牛,原本就是大名鼎鼎的华黎。

好了,下面进入正题,谈谈对这一章试读后的感受。

 

古人说:冰冻三尺非一日之寒。事物的发展,往往都是一个演进的过程,而不是一蹴而就。大型网站的架构也是同等道理,都是随着网站规模的扩大、随着需求的提高,而不变演进发展的。一个网站,比如淘宝,其本身的规模,也同样是一个演进的过程,淘宝不是刚出来就成为大型网站的,也没有一个网站会是这样。随着淘宝规模的不断扩大,用户越来越多,日访问量越来越大,淘宝的架构也随之不断演进,能够承载更多的高并发的访问和处理海量的大数据。

 

那么,大型网站的架构是如何演进的呢?

 

创始之初——单个系统、单机部署

网站创始初期,很可能连代码都是买的,比如淘宝,从《淘宝技术这十年》上可以看到,淘宝网站最初是从国外买的一套代码,马云召集的一批人潜伏的一个别墅里加班加点修改后,淘宝就这样产生了。而那当然是一个现在看来很简单的一个小系统。这个时候还没有用户,一时半会也不会凭空冒出多少用户出来,所以那时候一台小服务器部署就可以了。

 

第一步——数据库与应用分离

当淘宝在强敌环伺之下,凭借一些购物网站模式创新,开始闯出一片天地并小有名气之后,用户访问量开始增大,单机环境开始难以承受持续增大的访问量了。

这个时候就要考虑优化方案了,这是第一次演进。这时候自然而然会想到,应用和数据库部署到同一台机器上,这台机器既要运行应用,又要运行数据库,CPU、内存要两部分抢着用,IO也是严重问题,那么将它们分开到两台机器不就好多了吗。所以第一步便是数据库与应用分离,由单机部署变成两台服务器:Web服务器+数据库服务器。如此,第一步演进就完成了。

 

第二步——Web服务器集群

当访问量进一步增大,由于用户访问和计算的工作全部集中在一台Web服务器进行,所以很快,Web服务器必将不堪重负。

这个时候,就要考虑增加Web服务器了,这便是我们说的集群。两台或多台Web服务器,部署同一个应用,它们之间没有交互,只是使用同一个数据库服务器。它们都可以同样地处理用户访问,但是每个用户该访问哪个Web服务器呢?这是使用集群以后必然要解决的问题。

一般有两种方案:

1、DNS分发

DNS分发多个IP地址,网站用户选择一个IP进行访问。这是最简单的方式,但是有一个问题,访问不均衡,有可能一台服务器用户访问太多已经爆满了,但是另一台服务器可能只承受着极少的访问基本处于闲置。所以一般会考虑下一个方案——负载均衡。

 

2、负载均衡

采用负载均衡的技术,网站用户永远只访问一个IP地址,所有用户访问会到达一个负载均衡器,然后具体由那台服务器处理,则由负载均衡器去分配,它可以平均分配,也可以根据服务器实际负载情况进行分配,这样各台服务器都可以充分发挥。

不过关于负载均衡的方案,试读章节中并未提及,主要有硬件负载均衡(花钱买设备,虽然很贵,但是很值得)、软件负载均衡(比如淘宝的LVS)等。

 

采用负载均衡之后会不可避免带来的一个问题是Session的问题。比如用户之前访问的是服务器A,Session保存在这个服务器A上面,再访问另一个页面的时候负载均衡器把请求分配到服务器B了,但是服务器B上并没有用户的Session,这样就导致问题了。

 

书中对此给给出了几种方案:

1、Session Sticky

负载均衡器能够根据每次请求的会话标识来进行请求转发,保证同一个会话的请求都在同一个Web服务器上处理。

这种方案的缺点是,负载均衡器开销大,可能成为瓶颈,另外如果一台Web服务器宕机,Session就丢失了,用户突然无缘无故就需要重新登录了。

 

2、Session Replication

也即Session复制,将Session同步复制每一个Web服务器上,保证所有Web服务器中都保存有所有的Session。

这种方案不适合集群机器很多的情况,集群机器越多,Session复制的开销就越大,内存和网络带宽都会有很大的消耗。

 

3、Session数据集中存储

Session集中存储在一个地方,所有Web服务器对Session进行访问都通过这个地方进行,而且存储Session数据的具体方式,可以使用数据库,也可以使用其他分布式存储系统。

相对于前一种方案,当集群机器数量比较大时优势就很明显了。

 

4、Cookie Based

作者还介绍了第四种方案,将Session数据存储在客户端的cookie中,但是这存在非常严重的问题:cookie长度限制、安全性等等,而且还有一点作者没有提到的,有些客户端可能会禁用cookie的,所以这种方案一般好像不会采用。

 

前面两步的演进,都是通过增加服务器,主要是部署的时候做的事情(除了解决Session问题需要程序实现),接着后面的演进就不是这么简单了,往往就需要修改程序了。

 

第三步——数据库读写分离

上面解决的是Web服务器负载过重的问题,当Web服务器采用集群后,Web服务器方面没什么问题了,但是随着数据量和访问量的继续增大,接着数据库服务器往往很快会成为瓶颈。
这时可以采用读写分离的策略,因为每个系统中,总有某些表是写操作比较多,而有些表或者数据则大部分都是读操作,因此把读操作居多的表,分开到一个新的数据库中,读库专门用来读数据。当然,首先要解决的问题是将主库的数据复制到读库当中。一般数据库本身就提供了这种机制,比如MySQL支持Master(主库)+Slave(备库)的结构,提供了数据复制的功能。因为数据库本身提供的主从库同步功能一般较弱,也可以采用一些开源的解决方案,比如淘宝就开放了一些淘宝内部使用的数据库同步工具。同时,要注意复制的延迟,可能造成一定的数据不一致。

 

第四步——缓存

再接着演进,我们就要考虑是否引入缓存了,缓存主要分两个层面:一个是数据缓存、一个是页面缓存。试读章节中还没有具体讲缓存的方案,数据缓存一般采用memcached或一些内存数据库,页面缓存一般可以用oschache或ehcache,当然它们不仅仅能用于页面缓存,也可以用于数据缓存,比如数据库访问如果使用Hibernate,也是可以使用缓存的,就是通过ehcache实现的。

当然,使用了缓存,系统必然变得负责,特别是架构方面,会有很大的变化,但是这是处理高并发访问必然要经过的步骤。

 

第五步——分布式存储系统

后续的演进,可能就要考虑进入分布式存储系统了,因为并发访问量非常大的情况下,关系型数据库本身可能已经成为瓶颈了。作者这里说的分布式存储系统,没有讲得很具体,但是我想,应该就是指那些NoSQL的数据库了,比如Mong

oDB等等。当然,这会进一步导致系统架构发生翻天覆地的变化,所以比如结合具体需求场景,考虑是否有这样的必要。

 

第六步——数据垂直拆分、水平拆分

一个库里面涉及到很多模块的数据,不管怎样优化,有什么数据库,最终总会成为瓶颈,这时就要考虑垂直拆分了,把不同功能模块的数据拆分到不同库中。当然数据库多了之后就会带来一些问题:比如跨数据库的事务控制等等。

而当垂直拆分后的单个库又成为瓶颈之后,就要考虑水平拆分了。比如一张表数据量太大,那就水平拆分,按一定的规则,将数据存储到不同的表里或不同库的表里,例如不同地区用户的数据存到不同的库中。

 

数据库拆分之后带来的问题就是多数据源的整合,你可以在程序中根据情况连接不同的数据库,但是那样系统会很复杂,同时也很脆弱,因为每次拆分数据库,程序的代码都需要“大动干戈”。所以一般会提供一个统一的数据访问层,连接数据库的事情全部由这一层完成,上层的业务代码完全不用考虑连哪个数据库等问题。如果使用MySQL,还有一个更好的解决方案——Amoeba。这也是淘宝开发出来的一个多数据源整合的解决方案,它相当于在多个数据库和数据访问层代码之间建立了一个代理,数据访问层只需要访问这个代理Amoeba,就跟访问一个单独的数据库一模一样,而具体分成了哪些库、从哪些库读取数据、数据存储到哪个库等问题,全部由Amoeba完成。

Amoeba的简单应用,可以参看LZ的另一篇博客:

Amoeba For MySQL入门:实现数据库水平切分

 

第七步——拆分应用

前面几步演进一直围绕着数据,接下来的演进就回到应用本身了,当应用很大很庞杂以后,只是一个应用必然导致复杂度过高,所以就要考虑拆分成多个业务功能相对比较独立的应用。这样开发量自然很大,但是可以很大程度上解决架构无法满足高访问量大数据量的问题。

当然,这个步骤很多时候不是在这么晚的时候才考虑到,很多时候,在架构演进过程中,可能很早就开始进行拆分应用这一步了,这也是我们很容易想到的一步。

 

第八步——服务化

如果前面的演进都做了,还是不够,怎么办?比如亚马逊。这时候就可以考虑像亚马逊一样走服务化的路子,当然,这个路子走起来必然不会轻松不会容易。

 

 

以上,就是一个大型网站架构的演进过程,总之,应该按需进行,如果没有那么大的用户量访问量,非要搞缓存搞NoSQL搞服务化,可能等你网站做出来,市场已经被别人瓜分完了,那岂不是悲催。

 

冰冻三尺非一日之寒,架构的演进应当按需进行,循序渐进,不宜一蹴而就。

 

 

 

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(冰冻三尺非一日之寒——大型网站架构演进)