CSE:Serverless 在阿里巴巴 双11 场景的落地
云计算时代,Serverless 作为云原生重要技术组成部分,一开始便承载了太多的使命 —— 承诺了云计算时代最典型并极具挑战的多维度服务指标: 无服务运维、极速弹性伸缩、按量付费等。 这些极具挑战并富有吸引力的服务指标带给了行业极大的想象空间,但任何技术红利的普及并不是一蹴而就,或者像宣称的那样美好。Serverless 在阿里巴巴落地的时候,同时面临了两类诉求不同的用户:
第一类是积极拥抱 Serverless 愿意将其代码修改成 FaaS 形态的用户,这类用户以 BFF(Backend For Frontend)层为典型,这类用户的代码天生具备良好的轻量、无状态等特性。
第二类则是存量应用,存量应用作为目前商业系统的核心组成部分,是最需要享受 Serverless 服务红利,但也是最难享受到这些服务红利的群体, 面对 Serverless 严格的无状态要求,以及客户对系统稳定性、业务正确性的担忧,存量应用的改造代码设计的难度和成本太高,因此他们希望能够在不更改代码结构的前提下享受 Serverless 红利。
Book 模式会按照应用的峰值进行部署,且业务 Owner 在进行容量评估时往往会留有余地,导致资源池利用率低。CSE 采用 Serverless 按需模式进行部署,通过快速弹缩、分时复用和高密度部署来大幅度降低成本。
假设业务单次请求的 SLA 在 50ms,如果业务启动时间能做到 50ms 以下,就可以等待请求到来时再按需进行扩容,反之则只能根据水位进行 Book。启动时间越短,扩容时机可推迟到越晚,缩容时机可提前至越早,成本越低。
但现实情况是,大多数在线业务的启动时间都在分钟级,甚至有的达到 30 分钟。在线业务一般基于HSF 和潘多拉框架进行研发,同时会依赖大量的中间件富客户端以及其它部门提供的二方包,启动过程中包含了大量的初始化工作,比如网络连接、缓存加载、配置加载等。
因在线业务的启动瓶颈在于业务自身的代码,像 AWS Lambda、函数计算等 Function 场景对 IaaS或 Runtime 框架的弹性优化手段,在在线业务的场景下基本没有用武之地。在无法侵入业务代码的前提下,如何将业务启动时间从分钟级优化至秒级甚至毫秒级是 CSE 研发阶段重点攻坚的方向。
Zizz 方案基于一个核心和一个假设:
核心是热备(Standby):既然应用的冷启动时间如此长且很难优化,那么提前启动一批实例进行Standby,在流量峰值临时进行上线接流,在流量低谷时进行离线处理(服务发现层面的离线);
假设是离线的实例功耗非常低:如果热备的实例需要占据全部的物理资源,那么与 Book 模式并没有本质的区别。但理论上,处于离线状态的实例没有前端流量的驱动,应该仅存在少量的后台任务在运行。所以对于 Standby 的实例,可以将其换入一个低功耗的状态,将 CPU 和内存的规格降至很低,以极低的成本进行 Standby,为分时复用和高密度部署带来更高的灵活性。
基于这两点,CSE Zizz 研发了几种核心技术:
一种基于弹性堆的低功耗技术;
基于内核态和用户态的 Swap 能力的内存弹性技术;
基于 Inplace Update 的实例规格动态升降配技术。
在嵌入式领域, 低功耗运行模式被广泛接受, 包括 OS 设计和应用设计。 针对 OS 在设计阶段都会考虑到系统低功耗运行的情况,而对于应用,也会在设计和开发阶段考虑到低功耗运行的情况,通常应用会注册系统低功耗运行事件,在应用收到系统的低功耗运行事件之后,会进行一系列逻辑处理使自己进入低功耗运行状态。 基于这样的启发,在未来云计算环境下,应用的运行模式应该也需要支持类似的设计,这也是在 CSE Zizz 方案中引入应用低功耗运行时的概念,从而使整个 Zizz 方案更好地适配Serverless 场景需求。 Zizz 低功耗运行时核心技术主要包括下面三个部分。
CPU 低功耗
按照 Zizz 架构设计,进入低功耗模式,我们会对实例的资源配置进行降级; 针对 CPU 资源,我们维护一个低功耗 CPU Pool(CPU Set),CPU Pool 初始值是 1C,会随着加入这个 CPU Pool 中低功耗实例的数量,增加其 CPU Core 的数量,这样同一个 Node 上的多个低功耗实例争抢一个 CPUPool 中的资源。从 CPU 资源利用角度,多个低功耗实例构成了一个分时复用 CPU 资源的低功耗Serverless 场景。
内存低功耗
经过探索和论证,我们认为 Linux Swap 技术能够完成这样的使命。Linux Swap 向系统提供了一种透明的与进程运行时无关的内存扩展能力:根据系统当前内存压力,将系统的匿名内存按照 LRU 访问活跃度从低到高依次换出到外部低速存储介质,从而达到扩展系统可用内存的目的;在具体换出过程中,系统会根据 Swap 子系统的其它设置,根据当前内存 Anonymous 和 Filecache 的占比,将不活跃的 Anonymous 内存 Page 换出到外部低速存储设备上;从系统内存的角度来看,Swap 是一个扩展低速内存 Pool;从成本的角度,Swap 提供了一种低成本的进程运行时上下文; 面向未来,