大型网站及其架构演进过程

——你的网站现在哪个阶段？

本章首先介绍了大型网站的特征：海量数据、高并发的访问量、网站本身业务和系统的复杂度。基于这些特点，可以确定大型网站必然是一种很常见的分布式系统，而本书重点要介绍的中间件系统也是在大型网站的架构变化中出现并发展的。

然后透过透过一个交易网站的架构演进史来形象反应了大型网站的架构演进过程。

大型网站中，其实最核心的功能就是计算和存储。一个网站从小到大的演进可以说都是在围绕着这两个方面进行处理。

通常我们会选择一个开源的Server作为容器，直接使用JSP/Servlet等技术或者使用一些开源框架来构建我们的应用，选择一个数据库管理系统来存储数据，通过JDBC进行数据库的连接和操作。

2.2.1 用Java技术和单机来构建的网站。如图2-3

图2-3 技术单机构建的网站

2.2.2 从一个单机的交易网站开始：我们重点关注的是随着数据量、访问量提升，网站结构发生的变化。

  图2-4 基于Java技术用单机构建的交易网站

    各个功能模块之间是通过JVM内部的方法调用来交互，而应用和数据库之间是通过JDBC访问。

2.2.3 单机负载告警，数据库与应用分离

    随着服务器的负载持续升高，把数据库与应用从一台机器分到两台机器，调整以后我们能够缓解当前的系统压力。

 图2-5 应用与数据库分开的结构

2.2.4 应用服务器负载告警，如何让应用服务器走向集群。

    应用服务器压力变大时，把应用从单机变为集群。应用服务器从一台变为了两台，用户对两个应用服务器访问的选择问题：可以通过DNS来解决，也可以通过在应用服务器集群前增加负载均衡设备来解决。

 图2-6 应用服务器集群

2.2.4.1 引入负载均衡设备

 图2-7 引入负载均衡设备的结构

2.2.4.2 解决应用服务器变为集群后的Session问题

    在会话开始时，分配一个唯一的会话标识（SessionId），通过Cookie把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉Web服务器请求是属于哪个会话的。在Web服务器上，各个会话有独立的存储，保存不同会话的信息。如果遇到禁用Cookie的情况，一般的做法就是把这个会话标识放到URL的参数中。

 图2-8 Session

    会话数据是需要保存在各台单机上的：

 图2-9 负载均衡、应用集群与Session

Session问题的几种解决方案

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

 图2-10 Session Sticky方式

    在负载均衡器上做了“手脚”。同时也带来了如下几个问题：

    1.1、如果有一台Web服务器宕机或者重启，那么这台机器上的会话数据会丢失；

    1.2、负载均衡器需要进行应用层（第7层）的解析，这个开销比第4层的交换要大。负载均衡器变为了一个有状态的节点；

    1.3、这种做法内存消耗会更大，容灾方面会更麻烦。

2．Session Replication：在每个服务器中存放一套Session数据

 图2-11 SessionReplication方式

    Web服务器之间则增加了会话数据的同步（Session复制）。这个方案本身也有问题，而且在一些场景下，问题非常严重。

    2.1、同步Session数据造成了网络带宽的开销；

    2.2、每台Web服务器都要保存所有的Session数据；

    2.3、这个方案不适合集群机器数多的场景。

3．Session数据集中存储：Web服务器之间没有了Session数据复制，并且Session数据也不是保存在本机了，而是放在了另一个集中存储的地方。

 图2-12 集中存储Session方式

    存在的问题：

    3.1、读写Session数据引入了网络操作

    3.2、如果集中存储Session的机器或者集群有问题

4．Cookie Based：Session数据放在Cookie中

 图2-13 CookieBased的方式

    存在的不足：

    4.1、Cookie长度的限制

    4.2、安全问题

    4.3、带宽消耗

    4.4、性能影响

2.2.4.3 Session问题小结

    对于大型网站来说，Session Sticky和Session数据集中存储是比较好的方案，而这两个方案又各有优劣，需要在具体的场景中做出选择和权衡。

2.2.5 数据读压力变大后，应用读写分离

2.2.5.1 采用数据库作为读库

    大型网站读多写少，增加一个读库

 图2-14 加入读库后的架构

    增加一个读库对结构的影响：写操作要走主库，事务中的读也要走主库，不同业务选择也会有差异。广义的读写分离可以扩展到更多的场景，实际上是增加了读“源”。

同时也带来两个问题：

    1、数据复制问题。

    2、应用对于数据源的选择问题。

    数据库系统方面的支持：

    1、一般都提供了数据复制的功能

    2、数据复制时延

    3、不同的数据库系统有不同的支持

    3.1、MySQL支持Master（主库）+Slave（备库）的结构，提供了数据复制的机制镜像方式的复制semi-sync

    3.2、Oracle，之前接触的主要是Data Guard方案。Oracle 10g以前物理备库是不可读的，逻辑备库可以提供读服务

2.2.5.2 增加搜索引擎（其实是一个读库）

 图2-15 引入搜索引擎的结构

    搜索集群（Search Cluster）的使用方式和读库的使用方式是一样的，把搜索引擎当成一个读库。

2.2.5.3 加速数据读取的利器——缓存

不管是数据缓存还是页面缓存，都需要考虑缓存命中率的问题。

1．数据缓存

    大型系统中的数据缓存主要用于分担数据库的读的压力，从目的上看，类似于我们前面提到的分库和搜索引擎。特点如下：

    1.1、缓存系统一般是用来保存和查询键值（Key-Value）对的

    1.2、“热”数据

    1.3、通过应用完成的

    1.4、最近不被访问的数据就被清除

    1.5、在数据库的数据发生变化后，主动把数据放入缓存系统中

    1.6、根据数据库记录的变化去更新缓存的代码要能够理解业务逻辑

 图2-16 加入缓存后的结构

2．页面缓存

    ESI就是针对这种情况的一个规范：可以采用ESI或者类似的思路来做，也可以把页面缓存与页面渲染放在一起处理

    对于ESI的处理是在Apache中进行

 图2-17 Apache中的ESI模块

    这样的做法更高效，它把渲染与缓存的工作结合在了一起，而且这种做法只是看起来没有前一种方式分工清晰而已

 图2-18 JBoss中的ESI功能

2.2.6 弥补关系型数据库的不足，引入分布式存储系统

    常见的分布式存储系统有分布式文件系统、分布式Key-Value系统和分布式数据库。文件系统是大家所熟知的，分布式文件系统就是在分布式环境中由多个节点组成的功能与单机文件系统一样的文件系统，它是弱格式的，内容的格式需要使用者自己来组织；而分布式Key-Value系统相对分布式文件系统会更加格式化一些；分布式数据库则是最格式化的方式。

 图2-19 引入分布式存储系统的结构

2.2.7 读写分离后，数据库又遇到瓶颈

    数据垂直拆分和水平拆分

2.2.7.1 专库专用，数据垂直拆分

    垂直拆分的意思是把数据库中不同的业务数据拆分到不同的数据库中

 图2-20 数据库垂直拆分后的结构

    如何处理原来单机中跨业务的事务。一种办法是使用分布式事务，其性能要明显低于之前的单机事务；而另一种办法就是去掉事务或者不去追求强事务支持，则原来在单库中可以使用的表关联的查询也就需要改变实现了。可以根据不同业务的特点进行更多优化。

2.2.7.2 垂直拆分后的单机遇到瓶颈，数据水平拆分

    数据水平拆分就是把同一个表的数据拆到两个数据库中。读写分离解决的是读压力大的问题，水平拆分是把同一个表拆到不同的数据库中。我们可以进一步把用户表拆分到两个数据库中，它们拥有结构一模一样的用户表，而且每个库中的用户表都只涵盖了一部分的用户，两个数据库的用户合在一起就相当于没有拆分之前的用户表。

 图2-21 数据水平拆分后的结构

2.2.8 数据库问题解决后，应用面对的新挑战

2.2.8.1 拆分应用

    第一种方式，根据业务的特性把应用拆开两个应用

 图2-22 根据功能拆分应用

    第二种方式，根据功能拆分成三个系统

 图2-23 按功能拆分后的结构

2.2.8.2 走服务化的路

    处于最上端的是Web系统，处于中间的是一些服务中心，处于下层的则是业务的数据库。

 图2-24 服务化结构

    首先，业务功能之间的访问不仅是单机内部的方法调用了，还引入了远程的服务调用。其次，共享的代码不再是散落在不同的应用中了，这些实现被放在了各个服务中心。第三，数据库的连接也发生了一些变化，我们把与数据库的交互工作放到了服务中心，连接数据库的任务交给相应的业务服务中心了，这样可以降低数据库的连接数。第四，通过服务化，无论是前端Web应用还是服务中心，都可以是由固定小团队来维护的系统，这样能够更好地保持稳定性，并能更好地控制系统本身的发展。

2.2.9 初识消息中间件

    消息中间件：面向消息的系统（消息中间件）是在分布式系统中完成消息的发送和接收的基础软件。优点：异步和解耦。

 图2-25 消息中间件

2.2.10 总结

    我们通过一张图来看看经过演进之后，我们的网站变成什么样子了

 图2-26 整体结构图

    后面关于Java中间件的实践部分（第3章）会继续讲解一些更细节的内容。