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

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