欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

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

程序员文章站 2022-04-28 15:48:25
...

《大型网站系统与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搞服务化,可能等你网站做出来,市场已经被别人瓜分完了,那岂不是悲催。

 

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