突增流量应对和弹性可伸缩架构设计

Published: 20 Jan 2019 Category: arch

零、写在前面

弹性可伸缩架构设计,首先要分析瓶颈,然后再进行拆分,再用集群化管理。需兼顾可用性、一致性、分区容错性。

一、微博|腾讯|京东 应对突增流量举措

如何向流量暴击说不:揭秘微博|腾讯|京东高可用之道

二、弹性可伸缩架构设计

可伸缩性架构指的是:不改变网站的软硬件设计,只通过改变部署的服务器数量就可以扩大或缩小网站的服务处理能力。

大型网站都是从小型网站(一台廉价的 PC 服务器)开启自己的大型系统演化之路的。在这一过程中,最重要的技术手段就是使用服务器集群,通过不断地向集群中添加服务器来增强整个集群的处理能力。只要在技术上能够向集群中加入的服务器数量与集群的处理能力成线性关系,那么就可以利用这一手段不断提升自己的网站规模,这就是系统的伸缩性架构。

演化过程从总体上来说是渐进式的,网站的规模和服务器的规模总是在不断地扩大,即总是在 “伸”。但也有可能因为运营的需要(促销活动),在某个短时间内,网站的访问量和交易规模突然爆发式增长,然后又回归正常状态。这就需要网站的技术架构具有极好的伸缩性——在活动期间向服务器集群中加入更多的服务器以满足用户的访问,活动结束后再将这些服务器下线,以节约成本。

2.1 设计伸缩性架构

伸缩性架构分为两种:

  • 根据功能进行物理分离 - 不同服务器部署不同的服务。
  • 单一功能通过集群实现 - 集群内的多台服务器部署相同的服务,提供相同的功能。

根据功能进行物理分离可以分为两种情况:纵向分离与横向分离。

纵向分离(分层后分离):是将业务流程上的不同层进行分离部署。(单一网站分为:数据库层、缓存层、基础技术服务、可复用的业务服务、网站具体产品等。)

横向分离(业务分割后的分离):把不同的业务模块分离部署。(网站前台、卖家后台、买家后台、交易论坛)

单一功能集群部署,需要同时考虑可用性、性能以及关联服务集群的影响。

2.2 应用服务器集群

把应用服务器设计为无状态模式,这样通过负载均衡服务器,就可以把用户请求转发到不同的应用服务器上。

负载均衡服务器能够感知或配置集群的服务器数量,这样就可以向新上线的服务器分发请求,并停止已下线的服务器,这样就实现了应用服务器集群的伸缩性。

实现负载均衡的基础技术有:

  • HTTP 重定向:类似黄页查询,查到后再访问真实地址。缺点:两次请求;重定向服务器处理能力成为瓶颈;302会被SEO认为作弊。
  • DNS域名解析:DNS解析请求时,用负载均衡算法计算出一个不同的 IP 地址并返回。DNS服务器不需要自行管理。缺点:DNS解析不是实时生效;不能自行管理和优化。实践中,会使用 DNS 域名解析作为第一级的负载均衡手段
  • 反向代理:优点是集成了两种功能(反向代理、负载均衡),部署简单。缺点是反向代理服务器是所有请求和响应的中转站,所以它的性能可能会成为瓶颈。
  • IP 负载均衡:用户请求到达负载均衡服务器之后,负载均衡服务器会在操作系统内核进程中获取网络数据包,根据负载均衡算法计算得出一台 Web 服务器,然后把目的的 IP 地址修改为这台 Web 服务器。Web 服务器处理后,返回响应。负载均衡服务器再把数据包的源地址修改为自身的 IP 地址,发送回浏览器。缺点也是受制于负载均衡服务器的网卡带宽。
  • 数据链路层的负载均衡:数据链路层的负载均衡指的是,在通信协议的数据链路层修改 mac 地址。respond可以不通过负载均衡服务器直接打到用户机器。数据链路层的负载均衡是目前大型网站使用最广的一种负载均衡手段。在 Linux 平台推荐使用 LVS(Linux Virtual Server)。

负载均衡算法:

  • 轮询: 所有请求依次分发到每一台应用服务器,即每台服务器处理的请求数是相同的,这适合所有服务器硬件都相同的场景。
  • 加权轮询: 根据服务器的硬件性能,在轮询的基础上,按照配置的权重进行请求分发,高性能的服务器会被分配更多的请求。
  • 随机: 把请求随机分配到各个服务器。这种方案简单实用,因为好的随机数本身就很均衡。如果服务器的配置不同,也可以使用加权随机。
  • 最少连接: 记录每一台服务器正在处理的请求数(连接数),把新到的请求分发到最少连接的服务器上。这个算法最符合 “负载均衡” 原本定义 !也可以使用加权最少连接。
  • 源地址散列: 根据请求来源的 IP 地址进行 Hash 计算,算出应用服务器。这样来自同一个 IP 地址的请求总会在同一台服务器上进行处理,因此可以实现会话黏滞。
  • 目标地址散列(Destination Hashing):调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

2.3 分布式缓存集群

分布式缓存集群中的服务器,它们所缓存的数据并不相同,所以缓存的访问请求,必须先找出需要的缓存数据所在的服务器,才能处理请求。

一致性 Hash 算法: 一致性 Hash 算法通过一致性 Hash 环的数据结构来实现 KEY 到缓存服务器的 Hash 映射.

先构造一个长度为 0 ~ 2 的 32 次方的整数环(一致性 Hash 环),根据节点名称的 Hash 值,把缓存服务器节点放置在这个 Hash 环上。然后根据需要缓存数据的 KEY 值计算出 Hash 值(范围在 0 ~ 2 的 32 次方),最后再在 Hash 环上顺时针查找距离这个 KEY 的 Hash 值最近的缓存服务器节点,完成 KEY 到服务器的 Hash 映射查找。

当缓存服务器需要扩容时,只需要将新加入的节点名称(比如 Node 3)的 Hash 值放入环中,因为 KEY 是顺时针查找距离最近的节点,所以新加入的节点只会影响整个环中的一小段。

一致性 Hash 环通常使用二叉查找树实现,树最右边的叶子节点和最左边的叶子节点是相连接,构成环。Hash 查找的过程是在树中查找不小于查找数的最小数值。

一致性 Hash 环有一个缺陷:比如上例,新加入的节点 NODE 3 只影响了原来的节点 NODE 1。这意味着 NODE 0 和 NODE 2 缓存的数据量和负载量是 NODE 1 和 NODE 3 的两倍。如果这 4 台服务器性能相同,那么我们自然希望这些服务器缓存的数据量和负载量分布是均衡的。

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

我们把每一台物理缓存服务器虚拟为一组虚拟缓存服务器,这样就可以将虚拟服务器的 Hash 值放置在环上咯。KEY 会先在环上找出虚拟服务器节点,然后再得到物理服务器的信息。

这样新加入的缓存服务器,会较为均匀地影响原来集群中已经存在的服务器.

2.4 数据存储服务器集群

数据存储服务器必须保证数据的可靠存储,任何情况下都必须保证数据的可用性和正确性。

2.4.1 关系数据库集群

目前,主流的关系型数据库都支持数据复制功能,我们可以利用这个功能对数据库进行简单伸缩。

rds

写操作都在主服务器上进行,然后再由主服务器把数据同步到集群中的其他从服务器。

也可以使用数据分库,即把不同的业务数据表部署在不同的数据库集群上。使用这种方式的不足是:跨库的表不能进行关联查询。

在实际应用中,还会对一些数据量很大的单表进行分片,即把一张表拆开,分别存储在多个数据库中。

目前比较成熟的支持数据分片的分布式关系数据库有开源的 Amoeba 和 Cobar。

Cobar 是分布式关系数据库的访问代理,部署于应用服务器和数据库服务器之间。应用通过 JDBC 访问 Cobar 集群,Cobar 服务器依据 SQL 和分库规则来分解 SQL,然后把请求分发到 MySQL 集群中的不同数据库实例(每个实例都部署为主从结构,保证数据高可用)上执行。

Cobar

数据迁移:Cobar 服务器可以看作是无状态的应用服务器,所以可以直接使用负载均衡手段实现集群伸缩。而 MySQL 服务器中存储着数据,所以我们要做数据迁移(把集群中原有的服务器中的数据迁移到新的服务器),才能保证扩容后数据一致负载均衡。

可以利用一致性 Hash 算法进行数据迁移,尽量使得要迁移的数据最少。因为迁移数据需要遍历数据库中的每一条记录进行路由计算,所以这会对数据库造成一定的压力。而且还要解决迁移过程中的数据一致性、可访问性、可用性等问题。

实践中,Cobar 服务器利用 MySQL 的数据同步功能进行数据迁移。迁移是以 Schema 为单位。

在 Cobar 集群初始化时,为每一个 MySQL 实例创建多个 Schema。Schema 的个数依据业务远景的集群规模来估算,如果未来集群的最大规模为 1000 台数据库服务器,那么总的初始 Schema 数>= 1000。在扩容的时候,从每个服务器中,迁移一部分 Schema 到新服务器。因为迁移是以 Schema 为单位,所以可以利用 MySQL 同步机制。

但 Cobar 只能在单一数据库实例上处理查询请求,因此无法执行跨库关联操作,当然更不能进行跨库事务处理咯。这是分布式数据库的通病。

面对海量的业务数据存储压力,我们还是得使用分布式数据库呀,怎么办?我们可以避免事务或者利用事务补偿机制来代替数据库事务,也可以通过分解数据访问逻辑来避免数据表关联操作。

2.4.2 NoSQL 数据库

NoSQL 指的是非关系的、分布式数据库设计模式。它更关注高可用与可伸缩性。

目前应用最广泛的是 Apache HBase。HBase 依赖可分裂的 HRegion 和可伸缩的分布式文件系统 HDFS。

REF

如何向流量暴击说不:揭秘微博|腾讯|京东高可用之道
说说大型网站可伸缩性架构的设计原理