《大型网站系统与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问题需要程序实现），接着后面的演进就不是这么简单了，往往就需要修改程序了。