8.2　流量调度

1.背景

今天阿里巴巴的淘宝平台都运行在云平台上，在云平台中不可忽略的一个问题是为了最大程度地增加机器的利用率，会采用超配的方式，即一台物理机上创建的虚拟机CPU核数的总和会超过物理机实际的CPU核数。超配本身并不是一件坏事，淘宝平台包含了上千个大小应用，大部分都是长尾应用，即使在双十一零点，有些应用的流量也是非常低的。这些应用所在的服务器计算能力其实是有剩余的。合理的超配，可以提升机器的资源利用率。但从目前的部署结构来看，同样是核心的应用在虚拟机资源分配上并没有避免超配的现象，这就造成在业务繁忙时，这些部署在超配服务器上的应用就会出现资源争抢，这样很可能导致个别或局部的应用出现服务响应慢甚至挂起，给整个业务链路带来更大的影响。

这些因为单机或者局部问题而导致的故障，在阿里巴巴淘宝的线上环境中是普遍存在的，尤其是当我们应用机器数达到几百到几千台的时候，非常容易出现个别或者局部的机器服务状态恶化甚至服务不可用的情况。

原因是在分布式环境中，软件、硬件、网络等因素导致机器的实时服务能力是有差异的。大家可能会认为只要每台服务器的CPU和内存配置一样，这些机器的服务能力都是一样的，但实际在生产环境中，所有机器的实时服务能力都是有差异的。可能因为一次网络抖动导致这台机器实时服务能力下降，也可能因为CPU超配导致资源争抢，从而最终导致实时服务能力下降。

图8-7是我们对机器真实的服务能力分布的测试数据（纵坐标代表机器数，横坐标是对应指标的值，越密集的区间，表示分布在此区间的机器越多）。

除了机器超配之外，还有其他各种原因也会造成这些单点或局部应用出现故障：

·超卖问题带来的资源争抢问题。

·部分应用、部分机器启动的时候，容易出现个别机器负载飙高，导致这部分机器响应时间变长。

·JVM假死、VM假死等问题。

·受宿主机影响，负载飙高问题。

·JVM垃圾回收影响请求响应时间的问题。

·网络抖动导致RT抖动。

图8-7　服务器服务能力分布测试数据

对于机器数达到一定数量级的应用来说，大家往往不会太关注单台机器的服务能力，大家的关注点都是这个应用的服务能力是多少，能否抗住流量高峰。但从前面列举的种种故障来看，一旦单机、局部服务能力出现问题，带来的影响远比我们预估得要严重。

为什么上述单机、局部问题会带来这么大的影响？原因如下：

·分布式服务环境调用链路局部问题会被放大到整个链路。在今天这么大流量的情况下，任何单个系统，都无法处理如今这么复杂的业务逻辑。我们在淘宝上的任意一个请求，涉及的决不仅仅是一个系统，而是一整条链路。链路中任何一个单点出现问题，比如任意一台机器的RT变长、或者调用链路上的单点不可用，会直接导致整个调用链路RT变长或者调用链路不可用。

·单点、局部问题会被放大成面。生产环境中所有的服务调用链路其实是网状结构，我们的一个应用会有着多个上、下游应用，因而一旦单点、局部出现问题，可能导致的是下游的应用都将受到影响。1%的机器出现故障，可能导致100%的业务出现问题。

面对这种影响整体服务体系稳定性的隐患，阿里巴巴中间件团队实现了针对分布式服务系统的流量调度平台，用于屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量。对实时服务能力好的机器多分配流量；对实时服务能力差的机器减少流量分配；对实时服务能力不可用的机器迁移流量。让因为软件或者硬件带来的单点、局部问题发生时，不会影响整体业务的稳定运行。

2.实现原理

流量调度的核心是通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响。流量调度架构如图8-8所示。

通过服务器上暴露的指标信息接口（图中Restful API），流量调度的服务器定时（目前的收集频率大概是5s一次，每次指标集合大小1KB，对应用的性能没有任何影响）调用指标信息接口，目前采集的信息包括：

图8-8　流量调度架构示意图

·系统指标信息：CPU、Load等。

·业务指标信息：HTTP响应时间、HSF服务调用响应时间、HTTP QPS、HSF QPS、Tomcat线程池使用信息、HSF线程池使用信息。

在收集到这些实时指标值后，一旦判断为故障现象，则执行对线上流量调度的执行。

目前淘宝平台后端流量基本都是HSF服务。此时，HSF服务框架（见参第3章3.3节）中的ConfigServer就充当了“引路人”的角色。正如前文所描述的，服务的提供者和服务调用者在自身应用启动时会将服务的发布和订阅信息上传到ConfigServer中，因而，在进行流量调度时，只要ConfigServer推送给服务消费者的服务提供者列表带上服务调用的权重信息，服务消费者在选择服务提供者进行服务调用的时候，就能按照权重信息选择每次调用的服务提供者，从而就能控制所有服务提供者被服务请求的流量大小。这样当发现某些服务提供者出现服务响应慢或系统资源负载飙高时，实时降低对该服务器的服务路由权重（甚至直接降为0），最终达到通过自动化的流量调度来隔离故障。

图8-9　流量调度保障业务稳定效果图

3.调度效果

在流量调度平台上线后，对于生产环境中因为局部问题带来问题扩散的现象得到很大的改观。以cybertron启动时服务器负载飙高问题的例子说明调度效果。

当cybertron发布的时候，经常有机器的负载飙高5、60，使得HSF的响应时间比其他机器高出好几倍。流量调度通过迁移个别这种发布负载飙高机器的流量，等到机器的负载降低到正常范围内后，再自动恢复机器流量。（如图8-9所示，深色曲线表示当前机器，浅色曲线表示同机房、同分组机器均值。）

cyberton一台机器在15：44分的样子进行发布，发布完成后，负载直接飙高到70，直接导致hsf rt飙高到500ms，正常机器10ms左右。此时流量调度探测到异常，迁移掉这台机器的所有流量。

目前流量调度平台已经完成了覆盖天猫、淘宝、无线、手淘、聚划算、航旅等事业部超过300多个应用的接入，实现了对交易核心链路应用的全部覆盖，每天平均自动处理上百台问题机器。限流降级平台重点解决应用在整体上的可用性，流量调度平台很好地弥补了应用局部可用性带来的问题和隐患，为淘宝平台整体平台的稳定运行保驾护航。