大型网站的演进过程

大型网站系统与JAVA中间件实践笔记

第二章——大型网站及其架构演进过程

大型网站的定义

怎么才算的上是一个大型网站呢？访问量与数据量缺一不可。

大型网站的演进过程

假设我们公司对企业提供Web服务，最初，我们的架构是这样的。应用与提供业务服务，应用与数据库部署在同一台服务器上。

应用服务与数据库拆分

将应用做集群

使用两台服务器提供服务。那么两台服务器，用户要如何访问呢？这里有两种做法。一种是使用dns解析返回不同的ip访问，一种是使用负载均衡。这里详情说一下负载均衡。
引用负载均衡后，整体架构是这样的。

这时，出现了Session问题，那么什么是Session问题呢？

Session问题

先要介绍什么是Session。众所周知，Http协议是无状态的。也就是说，多个Http协议互相不认识彼此，在现实中就是用户第一次向网站发请求，处理完回来后，再发送下一个请求，网站并不能知道这次请求与上次请求是同一个用户所发的。在很多场景下，服务器端需要保存用户的相关信息，这就引入了Session。

Session是用户在第一次访问网站后，服务器会发给用户一个SessionId,用户下次再访问的时候，浏览器会把这个SessionId放到Cookie中一并发送给服务端，服务端拿到SessionId校验，就知道是谁发送的请求了，这就是一次“会话”。在浏览器禁Cookie的时候，通常是通过url把SessionId带到服务端的。

知道了什么是Session后，为何在集群服务器下，会有Session问题呢？原因是，集群服务器与客户端之间要有一个负载均衡的设备（可为硬件也可为软件）
假设现架构有服务器A，服务器B，Nginx。用户第一次发起请求到Nginx,Nginx转发到服务器A，服务器A生成Session存储到本机，返回用户。用户再次访问，Nginx转发到服务器B，此时服务器B并不认识用户，故又生成了SessionId返回给用户。这样就出现了Session问题。
针对这个问题，有三种解决方案：

1. Session Sticky（Session黏贴）
   Session黏贴通过Nginx负载均衡来解决Session问题。由Nginx通过一些算法来决定用户访问哪个服务器，每次用户进于Nginx，Nginx所转发的服务器都是相同的。这样就会避免Session问题。不过这会引出几个问题。
   服务器节点宕机，该节点的Session数据丢失。
   Nginx属于网络层，网络层要进行应用层的解析，会有一定的开销。
   Nginx从无状态变成了有状态，内存消耗会变大。
2. Session Replication(Session 复制)
   Session复制通过各服务器之间的共享Session来解决Session问题。提供服务的服务器集群每有一个新的Session生成，就会同步给其它服务器，这样Nginx不管转发到哪个服务器，都能获取到对应的Session
   它的缺点是：
   一、集群服务器多时，Session同步需要消耗网络带宽，只要Session数据有变化，就要同步到其它服务器。
   二、每台服务器都保存所有的用户Session，如果用户量大的话，会造成不必要的数据占用。
3. Session共享
   Session共享是将用户的Session数据放到统一的地方存储、管理。通常使用Redis。这样做的相比前两种更为简单也普遍
   它的缺点是：
   一、Redis服务有问题会影响应用
   二、也会造成网络带宽的开销

读写分离

随着数据量和访问量的增大，我们需要加一个读库，分担一下数据库读的压力
读写分离后带来了两个问题
a. 数据复制问题
b. 数据源选择问题
各大数据库厂商都支持数据复制，例如Mysql支持Master-Slave。
一些场景下即使是读操作也不能走读库，例如一些对实时性要求较高的场景、事务的读也要走主库。

数据缓存

如果应用频繁的访问数据库，势必会对数据库造成一定的压力。可以把一些经常被访问的结果放到缓存中，这类数据被称为“热”数据。应用要拿热数据的时候，直接从缓存中拿，不需要再访问数据库，减少数据库压力。这里涉及到一个缓存的更新策略：当缓存里的数据对应数据库中的数据被更新时，缓存也需要被更新，否则应用会一直拿到旧的数据。

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

分布式存储系统分为三类：分布式文件系统、分布式key-value系统和分布式数据库。分布式存储系统与读写分离的“读”源还不太相同，分布式存储系统更加强调代替了主库

数据量大，引入数据库拆分

访问量与数据库大的情况，即使使用读写分离、缓存这些解决方式，但数据库的压力还是会大，这种情况，数据库就需要合理的拆分了。
一、垂直拆分
垂直拆分即把不同的业务数据表分到不同的库中。用户表分到用户的库，交易表分到交易的库。
这样在访问相应数据库的时候，就要访问不同的数据源。这样做带来的好处各自去各自的库里查，但也有不好的地方。事务操作没法保证
二、水平拆分
如果遇到一张表的数据量过大，查询起来很费劲。这里要考虑把这个表水平拆分到不同的数据库中，即每个库都有这张表，其表结构也一致，其每个库中每个表存储的数据加起来等于之前一张表存储的数据。
我们来分析一下水平拆分带来的影响
首先，sql从此 有了路由，哪些请求要查哪个库的表，是需要区分开来的。另外，主键的处理也会不同，例如之前使用的自增主键，水平拆分后就不能使用自增主键了。

应用服务化

上面介绍了数据库层面的拆分在分布式中，服务层也要做相应的拆分。
图中最上面一层是业务层，业务层只关心业务逻辑，业务层去调用中间的服务层，由服务层和数据库打交道。服务层提供一些通过的业务请求，可找小团队进行管理维护。业务层使用消息中间件来做远程调用。