大型网站技术架构（六）网站的伸缩性架构

桃扇骨 2022-10-02 08:49 173阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

网站系统的伸缩性架构最重要的技术手段就是使用服务器集群功能，通过不断地向集群中添加服务器来增强整个集群的处理能力。“伸”即网站的规模和服务器的规模总是在不断扩大。

## 1、网站架构的伸缩性设计 ##

网站的伸缩性设计可以分成两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的 功能；后者是集群内的多台服务器部署相同的服务，提供相关的功能。

## 1.1 不同功能进行物理分离实现伸缩 ##

![30184146_0RAe.jpg][]

纵向分离：即分层后分离，将业务处理流程上的不同部分分离部署，实现系统伸缩性。

![30184146_JkCa.jpg][]  
横向分离：即分割业务后分离，将不同的业务模块分离部署，实现系统伸缩性。

![30184146_uDr8.jpg][]

### 1.2 单一功能通过你集群规模实现伸缩 ###

当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。  
集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。数据服务器集群也可分为缓存数据服务器集群和存储数据服务器集群。

![30184146_eW77.jpg][]

## 2、 应用服务器集群的伸缩性设计 ##

所谓应用服务器的伸缩性即：HTTP请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求 ，停止向已下线的服务器分发请求。这个HTTP请求分发装置被称为负载均衡服务器。  
负载均衡是网站必不可少的基础技术手段，不但可以实现网站的伸缩性，同时还改善网站的可用性，可谓网站的杀手锏之一。具体的技术实现也多种多样，从硬件实现到软件实现， 从商业产品到开源，应有尽有，但实现负载均衡的**基础技术**不外以下几种。

### 2.1 HTTP重定向负载均衡 ###

![30184146_jRqO.jpg][]

HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的服务器地址，并将真实的服务器地址写入HTTP重定向响应中（响应状态吗302）返回给浏览器，然后浏览器再自动请求真实的服务器。

这种负载均衡方案的优点是比较简单，缺点是浏览器需要每次请求两次服务器才能拿完成一次访问，性能较差；使用HTTP302响应吗重定向，可能是搜索引擎判断为SEO作弊，降低搜索排名。重定向服务器自身的处理能力有可能成为瓶颈。因此这种方案在实际使用中并不见多。

### 2.2 DNS域名解析负载均衡 ###

![30184146_ap4K.jpg][]

利用DNS处理域名解析请求的同时进行负载均衡是另一种常用的方案。在DNS服务器中配置多个A记录，如：[www.mysite.com][] IN A 114.100.80.1、[www.mysite.com][] IN A 114.100.80.2、[www.mysite.com][] IN A 114.100.80.3.

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。

DNS域名解析负载均衡的优点是将负载均衡工作交给DNS，省略掉了网络管理的麻烦，缺点就是DNS可能缓存A记录，不受网站控制。

事实上，大型网站总是部分使用DNS域名解析，作为第一级负载均衡手段，然后再在内部做第二级负载均衡。

### 2.3 反向代理负载均衡 ###

前面我们已经讲过，反向代理可以缓存资源，改善网站性能，事实上，反向代理业可以做负载均衡，如图所示。

![30184146_haHT.jpg][]

由于反向代理服务器转发请求在HTTP协议层面，因此也叫应用层负载均衡。优点是部署简单，缺点是可能成功系统的瓶颈。

### 2.4 IP负载均衡 ###

**IP负载均衡：即在网络层通过修改请求目标地址进行负载均衡。**

![30184146_q4LZ.jpg][]

用户请求数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进行获取网络数据包，根据负载均衡算法计算得到一台真实的WEB服务器地址，然后将数据包的IP地址修改为真实的WEB服务器地址，不需要通过用户进程处理。真实的WEB服务器处理完毕后，相应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址发送给用户浏览器。

这里的关键在于真实WEB服务器相应数据包如何返回给负载均衡服务器，一种是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址改为自身的IP，即源地址转换（SNAT），另一种方案是将负载均衡服务器同时作为真实物理服务器的网关服务器，这样所有的数据都会到达负载均衡服务器。

IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。但由于所有请求响应的数据包都需要经过负载均衡服务器，因此负载均衡的网卡带宽成为系统的瓶颈。

### 2.5 数据链路层负载均衡 ###

顾名思义：数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡，如下图：

![30184146_qQkq.jpg][]

这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一样，从而达到负载均衡，这种负载均衡方式又称为**直接路由方式（DR）.**

在上图中，用户请求到达负载均衡服务器后，负载均衡服务器将请求数据的目的mac地址修改为真是WEB服务器的mac地址，并不修改数据包目标IP地址，因此数据可以正常到达目标WEB服务器，该服务器在处理完数据后可以经过网管服务器而不是负载均衡服务器直接到达用户浏览器。

使用三角传输模式的链路层负载均衡是目前大型网站所使用的最广的一种负载均衡手段。在**linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)。**

### 2.6 负载均衡算法 ###

负载均衡服务器的实现可以分成两个部分：  
1、根据负载均衡算法和WEB服务器列表计算得到集群中一台WEB服务器的地址；  
2、将请求数据发送到改地址对应的WEB服务器上。

常用的**负载均衡算法**如下几种：  
1、**轮询**：即将请求依次分发到每台应用服务器上。  
2、**加权轮询**：根据应用服务器硬件性能情况，在轮询的基础上，安装配置的权重将请求分发到每个服务器。  
3、**随机**：将请求随机分配到各个应用服务器。  
4、**最少连接**：记录每个服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上。  
5、**原地址散列**：根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址请求总在同一个服务器上处理。

## 3、分布式缓存集群的伸缩性设计 ##

分布式缓存服务器集群中不同服务器中缓存的数据不相同，缓存访问请求不可用在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。 这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存数据，而已下线的缓存服务器还缓存着网站的许多热点数据。  
**分布式缓存集群伸缩性设计的最主要目标即**：必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据 尽可能还被访问到。

### 3.1 memcached分布式缓存集群访问模型 ###

![30184146_PaOk.jpg][]

### 3.2 分布式缓存的一致性Hash算法 ###

一致性hash算法通过一个叫做一致性hash环的数据结构实现KEY到缓存服务器的Hash映射，如下图：

![30184146_IQPD.jpg][]

如果使用上面数据结构的话，那么当新添加一台缓存服务器时，只是影响到了其中一台缓存服务器，其他两头缓存服务器的压力并没有得到缓解，因此此方案还是存在问题。 一种替代的方案就是**增加一个虚拟层，即把每台缓存服务器虚拟为一组服务器（比如3个虚拟网元）平均放到上面的环里面**。这样当新增加缓存服务器时，把新增加的虚拟网元平均分配 到环中，这样就能缓解每台缓存服务器，达到分布式缓存集群高伸缩性。

## 4、数据存储服务器集群的伸缩性设计 ##

和缓存服务器集群的伸缩性设计不同，数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求。具体来说，又可分为关系数据库集群的伸缩性设计和NoSql数据库的伸缩性设计。

### 4.1 关系数据库集群的伸缩性设计 ###

主要的关系数据库都支持**数据复制**功能，使用这个功能可以对数据库进行简单伸缩。  
另外除了利用数据库主从**读写分离外**，也可以利用业务分隔模式使**不同业务的数据表部署在不同的数据库集群**上，即俗称的**数据分库**。但是这种方式的制约条件时跨库不能进行join操作。  
在大型网站的实际应用中，即使使用了分库和主从复制，**对一些单表数据任然很大的表还需要进行分片**，将一张表拆开分别存储在多个数据库中。  
目前支持分布式数据分片的关系数据库产品主要有开源的**Amoeba和Cobar（阿里巴巴），**下图为Cobar部署模型。

![30184146_IDua.jpg][]  
 Cobar是一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间。应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同 的数据库实例上执行（每个MySQL实例都部署为主/从结构，保证数据高可用）。  
Cobar系统组件模型如下图：

![30184146_iXmd.jpg][]

前端通信模块负责和应用程序通信，接搜到SQL请求（select \* from users where userid in (12,22,23)）后转交给SQL解析模块，SQL解析模块解析获得SQL中的路由规则查询条件（userid in （12,22,23））再转交给 SQL路由模块，SQL路由模块根据路由规则配置（userid为偶数路由至数据库A，奇数则路由至数据库B）将应用程序提交的SQL分解成两条SQL(select \* from users where userid in (12,22)；select \* from users where userid in (23))转交给SQL执行代理模块，发送至数据库A和数据库B分别执行。 数据库A和数据库B的执行结果返回至SQL执行模块，通过结果合并模块将两个返回结果集合并成一个结果集，最终返回该应用程序，完成在分布式关系数据库中的一次访问请求。

Cobar的伸缩有两点：**Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。  
Cobar服务器可以看做是无状态的应用服务器**，因此其集群伸缩可以简单实用负载均衡的手段实现。而MySQL中存储着数据，要保证集群扩容后数据一致负载均衡，必须要做数据迁移，如下图（**利用数据同步功能进行数据迁移**）。

![30184146_w90e.jpg][]

![30184146_1mQh.jpg][]

### 4.2 NoSQL数据库的伸缩设计 ###

NoSQL主要是指非关系的、分布式的数据库设计模式。一般而言，**NoSQL数据库产品都放弃了关系数据库的两大重要基础：以关系代数为基础的结构化查询语言（SQL）和事物一致性保证（ACID），而强化了高可用性和可伸缩性。目前应用最广泛的是Apache HBase**。

转载于:https://my.oschina.net/zhanghaiyang/blog/593244

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20220113/6c4382f697514eb88f2a77e76be7efb9.png
[30184146_0RAe.jpg]: /images/20220113/0c0398ff3e26444a9f78622d45231705.png
[30184146_JkCa.jpg]: /images/20220113/de15c747eb75436c94d8f2a49382979a.png
[30184146_uDr8.jpg]: /images/20220113/8b12035397a04871b26b95725f27eb12.png
[30184146_eW77.jpg]: /images/20220113/6eda13d31d894e2eafde0890d4c6f294.png
[30184146_jRqO.jpg]: /images/20220113/d66f5e5d29b641eea35d6134afbb86dd.png
[30184146_ap4K.jpg]: /images/20220113/f7aa1240b4344c218ea8423d4ceff349.png
[www.mysite.com]: http://www.mysite.com/
[30184146_haHT.jpg]: /images/20220113/62a15a4efa184b48b60e661c212c0b7d.png
[30184146_q4LZ.jpg]: /images/20220113/2052364209074b0a962c05f1ae4697a9.png
[30184146_qQkq.jpg]: /images/20220113/8bcd0b4790374bcf87320bae185f65f8.png
[30184146_PaOk.jpg]: /images/20220113/36a6594f145e421f8d10485e6a2c1358.png
[30184146_IQPD.jpg]: /images/20220113/9b7556db376949fdbf66071d82d2acdf.png
[30184146_IDua.jpg]: /images/20220113/1c9f3342c2c44028986fd0314f9de340.png
[30184146_iXmd.jpg]: /images/20220113/f61f5d41e7a84cb4ac799aa926dc6b88.png
[30184146_w90e.jpg]: /images/20220113/39f94e196ac44a868419d5a3b9ed3952.png
[30184146_1mQh.jpg]: /images/20220113/de67ff30b12d44ce83a4a1fe6920a2db.png