背景
目前阿里巴巴搜索的分布式服务一般都是基于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调度
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
Decision
Decision的改进主要是站在决策服务的角度，把服务框架化，能够让算法同学比较容易地参与进来。Decision的主要挑战还是在算法上。在基于Carbon的决策系统中，决策的参照还只是单个服务(Role)的数据。而在基于Fiber的系统中，Decision在决策某个服务扩缩容情况时，还需要参考其他服务的负载情况。例如，在资源紧缺的情况下，Decision需要优先保障高优先级的服务A，那么就需要牺牲低优先级的服务的可服务性，调配资源过来。
应用及成果
今年双11 基于Fiber的弹性调度主要在TPP上应用。双11当天过了0点高峰后全天开启，扩缩容次数超过万次，调度的Role上百个。
TPP单机房所有Role (主要用作TPP场景的物理隔离) 都在一个Fiber调度器中调度。TPP对Fiber中的app data应用得比较轻量，仅仅是一个集群标识，用于某个从Buffer中拿出来的Slot被分配到某个Role时，可以正确地将该Slot同步到名字服务中。Fiber中除掉app data的调度外，最主要的是解决了Slot Buffer的问题。但影响扩容速度的还有很大一部分取决于服务的预热，尤其是TPP这种Java应用。
Fiber目前并没有解决服务预热的问题。所以预热的控制完全交给了TPP自己。目前TPP针对容量大的Role(通常也是优先级高的业务)，会定时对Buffer中的Slot做预热，以保障这些Role拿到的Slot可以尽可能快地对外服务。而其他Role则是在Slot交给Role时进行预热。
在整个链路中，总结下来，为了提高扩容的响应速度，除了Fiber的实现外，还包括：
TPP管控系统中对Buffer Slot的预热
TPP Glaucus启动中对预热的支持，以及服务的稳定性，避免新Slot接流量时出现毛刺
为了Decision获得快速的决策效果，metric系统Kmonitor也做了不少优化，将metric的实时性提高到了5s精度
Decision 中的算法部分为了贴合TPP各种复杂的场景，例如突增流量，做了不少贴近TPP特点的优化。
算法部分在Decision框架中，由Kmon Watch驱动以5s一次的频率进行决策 (metric精度是5s)
双11当天Decision决策出的扩缩容中，扩容速度整体上可以达到20秒：
metric的实时性5秒
分配到进程运行的Slot消耗5秒
预热时间分两种情况
在Buffer中被预热：Slot拿出来后到可提供服务消耗10s
未在Buffer预热：预热时间50s (跟踪样本)
未来
基于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服务方面的预热能否发生质变
借助于集团的存储计算分离，也许能支持部分有状态服务
网友评论