阿里分布式负载均衡架构介绍
以表格存储为例
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。

这个逻辑单位，也就是租户，跟表格存储里面的分区对应，后文中根据上下文不同租户和分区都会使用，概念上等同。

接下来谈谈单机系统和分布式系统负载均衡的不同。

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

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

请求能否迁移是分布式系统和单机系统负载均衡的最大不同。

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

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

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

另外一个常见做法就是业务通知运维扩容缩容，这无疑给运维带来了极大的压力，据一份统计数据，系统50%以上的故障都是人的失误导致的，这种事情做多了运维背锅几乎没法避免。

最后，负载均衡做好了，能够在全集群范围内平衡资源的使用，可以降低成本，也可以利用更多的资源改善服务水平。

上面说到了负载均衡系统的价值，那么负载均衡的终态就是能实现这些价值，比如这里列的几条具体指标：
o能够在确定时间内解决用户业务暴涨问题；
o对于那些表结构不合理的用户，比如只写尾部、量又特别大的，这时候系统也很难解决，只能尽快隔离避免影响其他用户。

负载均衡的终极目标就是跟服务SLA形成闭环，此时负载均衡就成为一个自我进化的系统，该系统的目标就是不断逼近系统SLA的极限。

从0到1
前面说了理想目标，这里就介绍一下我们不同阶段的做法。

上图看到的是最土的负载均衡，是从0到1，完全依赖人肉，且粒度是机器级别。

对那些大业务而言，为了避免别人影响他们或者他们影响别人，可以由运维手动指定几台机器给他们。

而对大多数业务而言，他们没有大到这种程度，只能跟众多中小业务一起自生自灭，如果有个小业务突然放量，那么跟这个小业务共享机器的其他业务就遭殃了，此时服务SLA几乎完全依赖运气。

对于有情怀的技术人员而言，我们显然不能容忍小用户被轻视，必须一视同仁。

从1到N
这里列出了我们新版负载均衡系统支持的主要动作，我们摒弃了业务大小的概念，以分区作为系统的调度基本单位。

大业务可以分割成多个分区，小业务可以只有一个分区，这些分区是平等的。

左上角是系统的初始状态，可以看到每个worker上都加载了同样个数的分区，这是因为系统启动初始阶段没有负载信息来辅助判断，所以此时的worker跟分区的关系可以认为是随机分配的。

随着业务的上线，可能发生如下3种情况。

第一是客户业务突然上涨，此时该客户的数据表可能只有一个分区（刚开始建表默认只有一个分区），该分区即使将某台机器资源全部吃掉也无法服务这么多请求，系统识别这种情况后会迅速将该分区分裂开来，变成两个分区，并再挑选一台机器，让他们共同服务该客户请求。

第二种情况是，某机器上不止一个分区业务上涨，但是并没有哪个分区的业务量能够吃掉一台机器的全部资源，只是繁忙分区多导致机器资源紧张而已，此时需要挑选部分业务上涨的分区移动到其他较空闲机器加载。

还有第三种情况，就是系统通过对用户访问模式的判断，认为已有的策略都无法解决当前问题，就会将该分区移动到隔离机器上，避免产生更大的影响，并报警运维处理。

目前看，线上情况第一种是主流，第三种很少，有些数据库新手可能会设计出不合理的表结构，比如以时间为pk。

挑战&方案。