阿里搜索秒即弹性调度
目前阿里巴巴搜索的分布式服务一般都是基于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服务方面的预热能否发生质变
借助于集团的存储计算分离,也许能支持部分有状态服务
posted on 2018-06-28 22:43 sichenzhao 阅读(272) 评论(0) 编辑 收藏 举报