阿里搜索秒即弹性调度

目前阿里巴巴搜索的分布式服务一般都是基于Hippo+Carbon来调度的，包括部署、扩缩容、名字服务注册。如下图：

其中：


Hippo：一层调度（资源调度），解决机器资源分配问题，将一个物理机分成很多资源，根据应用单机不同的资源需求动态创建不同规格的容器(Docker)。一个容器被视作一个Slot。
Carbon：二层调度（业务调度），基于各种服务状态决策单机服务是否正常，以决策是否需要自动做机器迁移。同时实现服务的各种运维操作。

Drogo：业务管控系统，管理由多个二层调度管理的多个业务集群，并封装成用户操作的UI及API，作为用户及三方服务对接的入口。

Hippo + Carbon 的组合，可以简单理解为Yarn + Slider，或者Cloud Provider + Kubernetes。

这个架构提供了轻量容器的管理、异常机器的自动替换、应用的一键部署，包揽了用户日常的所有运维操作，达到了自动化、自助化的运维效果。但是对于服务容量来说，它不是弹性的。弹性的服务调度，主要解决服务容量自动化扩缩问题。

弹性调度

在目标服务流量上涨时，服务各种指标(例如CPU)上涨，导致服务质量下降。弹性调度自动发现这种情况，并做出扩容请求。相反，在服务流量较低时，弹性调度能够自动缩容，让服务始终保持在一个健康且不浪费的容量状态。

弹性调度在实现上包含以下部分：

指标的透出：无论是服务主动汇报还是被动收集，需要有metric系统持有服务的实时指标。
决策：决策系统是整个弹性调度的大脑，决策算法需要的数据(如metrics)需要各个系统透出，并决策出扩缩容的目标，然后提交给“执行”系统
执行：执行系统真正地去完成决策目标，例如扩缩容，也可能是动态改变单容器资源

对应到搜索中无数据服务的弹性调度，如图：

原有方案：基于carbon调度

无论是基于什么调度器来调度应用服务，流程上目前是相差无几的。2017年双11 SP服务是基于Carbon来调度的。整体的结构如下图：

上图中：


一个服务就是一个Role，服务下有多个instance，本质上是一个Hippo Slot
一个Slot由动态创建的容器、容器中的包(镜像)、进程构成
Drogo 引导用户将服务的部署plan提交给Carbon
Carbon 对服务做稳定性调度，确保服务的instance健康可服务；一个Carbon可以调度若干个Role
Hippo 提供Slot的管理，提供拉起Slot的能力 (拉包、启动进程及守护)
Carbon 向Hippo请求及归还Slot
Decision 是让整个服务动态化(动态扩缩容)的决策大脑，决策的依据是服务instance的各种指标(主要还是CPU)，决策的结果提交给Drogo
Kmonitor 收集服务各个Slot的各种指标，并提供统一的数据查询
在整个系统中主要有两个问题：


Decision决策扩容时，扩容速度达不到秒级
Decision的决策在面临复杂业务服务时，不够智能

第一个问题中，扩容的速度受很多方面的影响，需要针对每个问题进行优化：

新的方案：基于fiber调度

Fiber是一个同Carbon相同角色的调度器。Fiber服务本身只能解弹性调度执行的问题。基于Fiber，我们优化了整个系统的各个部分。

Fiber

在Fiber调度中，我们整个系统演化成下图：

在Fiber中增加了一个Slot Buffer，用作调度过程中向Hippo申请分配及归还Slot的一个中间缓冲。前面提到一个Slot从无到有是有代价的，而Slot Buffer的提出，则是让Slot提前准备好，Role的扩容请求只是在Fiber进程内改变下Slot的数据结构归属关系。但是Buffer本质上还是存在浪费资源的嫌疑，占用了整个Hippo集群的公共资源。因此，在Fiber中我们预期的使用方式：

若干个Role共用同一个Buffer，整个系统的调度是努力在多个服务(Role)间取得资源的最高性价比使用。这也是Decision需要升级的地方。
共用同一个Buffer意味着多个服务具有相同的服务启动Plan，服务之间的差异性(一般就是业务数据)需要调度器与应用之间确定一个新的交互协议，也就是服务需要由调度器驱动来热加载业务数据。
针对第二点，Fiber调度器中相应发生了些变化：


Slot的构成，在进程之上增加了app data，称为业务数据。进程最好能支持热加载业务数据(热加载更快)。举个例子，一个支持servlet的web容器(如tomat)是一个进程，各个servlet的包就是业务数据，希望在tomcat中可以热加载不同的servlet。这样就可以省掉tomcat的启动时间。
Fiber需要在某个Slot从Buffer中重新分配给新的Role时，及时通知更新hot plan。为了实现的容错性，我们实现为类似Carbon中设置Slot启动Plan一样的目标式方式，自然地也需要支持rolling、甚至最小可用度保证等功能。
总结下来可以看出，在Carbon中某个服务的启动/更新是Carbon与Hippo协作的结果；而在Fiber中，还包括了Fiber与服务之间的协作。理想中Fiber的使用方式，举个tomcat加载web .war包的例子：


buffer中提前准备好了很多已经运行的tomcat进程，整体上就是很多Slot
业务方A需要部署服务A，提供了自己开发的业务.war包，提交到Fiber中
Fiber从Buffer拿出指定数量的Slot，并通知这些Slot上的tomcat进程热加载用户的.war包
Decision发现服务A负载较高，发出扩容请求
Fiber从Buffer拿出更多Slot，并热加载.war包
Buffer容量不足，从Hippo集群补充冷Slot，并准备好Slot (拉包、启动容器、启动tomcat)
Decision发现服务A负载过低，发出缩容请求

Fiber归还Slot到Buffer，Buffer过大则归还部分Slot回Hippo

未来

基于Fiber的弹性调度，在2017年的双11与TPP合作上，更多的是一次大胆的尝试，离我们理想中的秒级弹性调度还有很大差距。在未来我们还有很多需要突破的地方，例如：


Fiber 对app data的管理形成闭环，从部署到名字服务同步，到物理Role的迁移等有自己的体系，而不是部分依赖于Role的管理
Fiber 中对Buffer的管理能够适应更多的需求，例如Buffer Slot的健康、Buffer的资源分级
进一步地能否降低Buffer的大小依赖，让其只是一个Slot缓冲带(较小的size)，而不是Slot池
Drogo对Fiber的接入及运维包装，让应用接入更容易；在servless方向做尝试
Decision 在算法模型方面能够更统一地处理相似服务的决策，摒除掉各种特殊情况的处理
SP不存在预热问题，配合运维系统的完善迁移上来实现<10s级的扩容调度
TPP在Java服务方面的预热能否发生质变
借助于集团的存储计算分离，也许能支持部分有状态服务