文章目录

• 系统架构之伸缩性
• • 系统架构的伸缩性设计
  • • 不同功能进行物理分离实现伸缩
    • • 纵向分离
      • 横向分离
    • 单一功能通过集群规模实现伸缩
  • 应用服务器集群的伸缩性设计
  • • HTTP 重定向负载均衡
    • DNS 域名解析负载均衡
    • 反向代理服务器
    • IP 负载均衡
    • 数据链路层负载均衡
    • 负载均衡算法
    • • 轮询（Round Robin, RR）
      • 加权轮询（Weighted Round Robin，WRR）
      • 随机（Random）
      • 最少连接（Least Connections）
      • 源地址散列（Source Hashing）
  • 分布式缓存集群的伸缩性设计
  • • 分布式缓存的一致性 Hash 算法
  • 数据存储服务器集群的伸缩性设计
  • • 关系数据库集群的伸缩性设计
    • NoSQ L数据库的伸缩性设计

系统架构之伸缩性

所谓系统的伸缩性是指不需要改变系统的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小系统的服务处理能力

系统架构的伸缩性设计

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

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

纵向分离

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

横向分离

业务分割后分离，将不同的业务模块分离部署，实现伸缩性

横向分离的粒度可以非常小，甚至可以一个关键网页部署一个独立服务

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

当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车

集群伸缩性又可分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群由于对数据状态管理的不同，技术实现也有非常大的区别。而数据服务器集群也可分为缓存数据服务器和存储数据服务器集群，这两种集群的伸缩性设计也不大相同

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

负载均衡是网站必不可少的基础技术手段，不但可以实现网站的伸缩性，同时还改善网站的可用性，可谓网站的杀手锏之意。

具体的技术实现多种多样，从硬件到软件，从商业到开源

HTTP 重定向负载均衡

这种方案的有点是比较简单。缺点是浏览器需要两次请求服务器才能一次访问，性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群伸缩规模有限；使用 HTTP302 响应码重定向，有可能是搜索引擎判断 SEO 作弊，降低搜索排名。因此时间中此种方案不多见

DNS 域名解析负载均衡

DNS 域名解析负载均衡的有点是将负载的工作交给 DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多 DNS 还支持基于地理位置的域名解析，就近原则，改善性能

缺点：

• DNS 多级解析，如果下线服务，容易导致用户访问失败
• 无法对 DNS 进行管理，控制权在服务商那里

实时上，大型系统总是部分使用 DNS 域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供Web 服务的物理服务器，而是同样提供负载均衡的内部服务器，这组内部负载均衡服务器再进行负载均衡，将请求分发到真是的 Web 服务器上

反向代理服务器

优点是部署简单（HTTP 应用层）；缺点是返现代理服务器是所有请求和响应的中转站，其性能可能成为瓶颈

IP 负载均衡

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

IP 负载均衡在内核进程完成数据分发，较反向代理负载均衡有更好的处理性能。但是由于所有请求响应都需要经过负载均衡服务器，集群的最大响应数据吞吐量不得不受限制于负载均衡服务器网卡带宽。对于提供下载服务或者视频服务等需要传输大量数据的系统而言，难以满足需求

数据链路层负载均衡

顾名思义，数据链路层负载均衡是指在通信协议的数据链路层修改 mac 地址进行负载均衡，又称作直接路由方式（DR）

使用链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在 Linux 平台上最好的链路层负载均衡开源产品是 LVS （Linux Virtual Server）

负载均衡算法

负载均衡服务器的实现可以分成两个部分：

• 根据负载均衡算法和 We b服务器列表计算得到集群中一台 Web 服务器地址
• 将请求数据发送到该地址对应的 Web 服务器上

轮询（Round Robin, RR）

所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适用于所有服务器硬件都相同的场景

加权轮询（Weighted Round Robin，WRR）

根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器能分配更多请求

随机（Random）

请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。即使应用服务器硬件配置不同，也可以实用加权随机算法

最少连接（Least Connections）

记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡的算法。同样，最少连接算法也可以实现加权最少连接

源地址散列（Source Hashing）

根据请求来源的 IP 地址进行 Hash 计算，得到应用服务器，这样来自同一个 IP 地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话黏滞

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

分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存任何数据，而已下线的缓存服务器还缓存这系统的许多热点数据

必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后，应使整个缓存服务器集群中已经缓存的数据竟可能还被访问到，这是分布式缓存伸缩性设计的最主要目标

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

计算机的任何问题都可以通过增加一个虚拟层来解决

通常使用二叉查找树实现，Hash 查找过程实际上实在二叉查找树中查找不小于查找树的最小值。这个二叉树的最右边叶子结点和最左端的叶子结点相连接，构成环

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

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

目前在线业务中比较成熟的智齿数据分片的分布式关系型数据库产品主要有开源的Amoeba和Cobar

NoSQ L数据库的伸缩性设计

HBase

ZooKeeper -> HMaster -> HRegionServer -> HRegion

高手定律：这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了

救世主定律：遇到问题，分析问题，最后总能解决问题

ref: [大型网站技术架构]