阿里分布式负载均衡架构介绍

阿里分布式负载均衡架构介绍

以表格存储为例

Table Store是构建在阿里云飞天系统之上的分布式NoSQL数据存储服务，支持单表千万级读写和数十P数据存储，具备99.99%的数据可用性以及11个9的数据可靠性。表格存储基于庞大的共享资源池来服务客户，通过负载均衡来协调不同客户对资源的诉求，削峰填谷带来了成本的下降，并最终让客户收益。

本次分享即对表格存储负载均衡技术做一些总结，以便探讨分布式系统中负载均衡的问题和思路。

下面会先对表格存储做简单的介绍，以便更好的讨论我们碰到的问题。然后会介绍多租户的概念，并说明单机多租户和分布式系统多租户的不同。最后重点介绍分布式系统中多租户负载均衡的核心问题。

一、表格存储概览

需求驱动

先来看看为什么要做表格存储。就像10年前谷歌BigTable论文里面描述的一样，新时代数据有一些明显的特征：

o数据量大、读写量大、增长速度很难预计。关于增长速度，比如答题，一天内访问量就可能上涨几十倍，不差钱，就看你能不能搞定。

o数据之间关系很弱。比如对邮箱应用来说，不同用户的邮件记录之间完全没有关系，无论是收发还是搜索，你都只能在自己的邮箱数据内进行。

o业务变动频繁，schema也需要跟着频繁变动。

受传统数据库约束，这三个需求都没有得到很好地解决。第一是扩展性，比如你跟DBA说业务明天要扩大10倍，估计DBA得头痛一下。他要给你准备好资源，分库分表，甚至需要业务逻辑也随之改动，很麻烦。

第二个是可用性。传统单机数据库一般是主备，有强同步、弱同步等选择，看起来给应用很多的选择权，其实选哪个你都觉得不爽，因为你想的是既要、又要、还要……

第三点是灵活性。这也很好理解，比如数据库里面有几十亿条数据，业务方跟DBA说我要加一列，看看DBA的脸色你就知道了，DBA是不喜欢这种需求的，一般来说业务方会预留一些空白字段来避开这种需求。

正因为需求真实的存在，已有的数据库没有很好的解决，所以很多新的数据库就出来了，NoSQL是其中一个思路，是传统SQL数据库的一个很好的补充，所以我认为应该解释为Not Only SQL。未来将迎来数据库百花齐放的几年，数据库将和行业更紧密的结合，拭目以待。

特性

这里以列表的方式整理了表格存储的特征，大家了解一下就好，里面唯一需要强调的是规模，因为它跟分享主题负载均衡有直接的关系。

表格存储支持单表千万读写，数十P数据量，只要运维将机器放入集群，扩容在分钟级别就可以完成。扩容完成后就面临着负载均衡的问题，因为老机器负载高、新机器负载低，负载均衡算法会去削峰填谷，让不同集群节点保持接近的利用率。

架构

这是表格存储的架构。

可以看到下面有一些基础组件是被所有角色共享的，比如Nuwa提供分布式锁服务，日志模块主要做日志的收集保存分析，而安全体系、机房管理等都是所有产品共享的。

我们要关注的主要是盘古和表格存储引擎。盘古是阿里云自研的分布式文件系统，可以类比HDFS，当然功能性能上做了很多增强。

表格存储引擎层包括master、负载均衡和若干个worker，是典型的分布式系统架构。其中master 管理表meta信息，比如表名、分区个数、压缩算法、缓存策略等，并为每个分区分配合适的worker 去加载。worker就是干活的，负责加载分区并执行请求。负载均衡依赖master和worker的统计信息来干活，细节后面会讲。

数据模型

这是表格存储的数据模型，只关注一点就可以了，就是分区机制，后面的内容会依赖这个。

几乎所有的分布式系统都有分区的概念，名字虽然各不相同（partition，shard，segment，group），意思大体一样，就是分而治之，把规模拆分成单机可以处理的水平，然后让单机承载相应的功能。

数据库类基本的分区机制有两种，一种是hash，一种是range。表格存储是按照range进行分区的，就是表按照PK排好序，然后切分成一个个的分区。

举个例子，表PK是字符串，从AA到FF，我们可以将其分成二个分区，[AA-CB)，[CB-FF)，这里的一个分区就可以理解为传统数据库的一个实例。

负载均衡关键能力

表格存储负载均衡依赖一些关键能力。首先表格存储使用分布式文件系统作为共享存储，这使得任何一个worker都可以随时访问任意数据，这也就带来了第二点提到的优势，即想将某个分区从一个worker迁移到另外的worker要比传统分库分表容易很多，只要调度上做一个简单的调整就可以，不需要搬动数据，可以非常快的完成。

这些能力对表格存储的负载均衡非常重要，当然做好也不容易，但是不是今天的重点，略过不提。

二、多租户负载均衡

背景&定义

上面我们介绍了表格存储基本概念，有了这些铺垫，下面介绍负载均衡时候会容易一些。

如图，让我们看看多租户负载均衡的一些信息。负载均衡是表格存储系统的一部分，可以按照每类资源进行细粒度的调度，允许不同类资源以合理的方式进行组合。

这里我们将租户定义为共享资源的逻辑单位，每个这样的逻辑单位都会消耗CPU、内存、网络带宽、磁盘IOPS。这个逻辑单位，也就是租户，跟表格存储里面的分区对应，后文中根据上下文不同租户和分区都会使用，概念上等同。

接下来谈谈单机系统和分布式系统负载均衡的不同。单机系统因为不可扩展，所以其负载均衡更多的是对请求优先级进行排序，如果资源用满，就拒绝一些请求。

分布式系统提供了一个额外的选项，就是通过将服务实例进行迁移来对请求进行迁移，这样就等于利用额外的资源服务用户，能够提高客户体验，迁移的过程就是分区调度的过程。请求能否迁移是分布式系统和单机系统负载均衡的最大不同。

价值&终态

这张图讲的是多租户负载均衡的好处以及我们认为负载均衡终态应该长什么样子。

全自动负载均衡能提供的好处是很明显的，首先就是保证业务平稳运行，我们系统上经常有些业务流量猛增猛降，比如某个突发事件访问量很快上涨十倍，此时负载均衡必须能在十秒级别响应并尽快解决问题，避免系统阻碍业务的发展。

如果负载均衡做的不好，就要在每台机器上为这种可能突发的业务预留资源，而且各个机器上的资源无法被共享，那么当客户众多的时候，这种预留是一个巨大的浪费。