研发运维效率提升100%，机器成本下降50%，阿里巴巴在 Serverless 计算领域的探索

什么是 Serverless

AWS 对 Serverless 定义是（摘自 AWS 官网）：

AWS 无服务器平台提供的功能（摘自 AWS 官网）：

AWS 的整套 Serverless 方案非常完善，但是没有解决存量应用如何迁移到 Serverless 架构的问题。仅仅是针对新开发的应用，建议用户使用 FaaS 方式开发，才有机会转向 Serverless 架构。笔者认为，要将 Serverless 架构大规模推广，必须要能有针对存量业务的解决方案。

Serverless 对云计算的价值

云计算，归根结底是一种 IT 服务提供模式，不论是公共云还是专有云（以IT设备的归属不同分类），其本质都是帮助 IT 的最终使用者随时随地，并且简便快速地，获取 IT 服务，目前，IaaS、PaaS都已经做到了按需付费，PaaS 甚至做到了按请求付费，如DB，CACHE，MQ等，但是 IaaS 的付费粒度仍然是时间维度，最快按照小时付费，以分钟来交付。

因此，当下的云计算场景，应用的开发维护方式相比传统 IDC 时代的开发维护，差别还不是很大。但 AWS Lambda 提供了一种全新的开发维护方式，用户只需要写好业务代码，提交到云上，所有和机器容量、可用性、机器为单位的运维工作可以全部交给了云平台，这种模式极大的释放了云的弹性价值，真正做到了按需付费。

CSE 试图提供一种更规模化的解决方案，像 AWS Lambda 一样，能进一步释放云的弹性价值，并且可以平滑迁移存量应用。

存量在线业务实现 Serverless 架构的挑战

如何将应用启动速度提高到毫秒级？

应用在启动过程中通常会初始化多个组件，如各种中间件、数据结构，以及网络调用外部服务。在阿里内部广泛使用 SOA 和微服务的情况下，应用在启动过程中会大量加载共享业务 SDK，存在启动过程达到10分钟量级的情况，个别应用可能会更长。因此，这个启动过程必须提前完成，才有机会以“临阵磨枪”的方式去创建新实例。

方案一：应用冷启动资源压缩方案

L1 弹性能力是指在一台物理机或者大规格的 ECS 上部署同一个应用的多个实例，通过操作系统和 JVM 的优化，一个占用 4G 内存的应用，即使部署10份，仅需占用2.2G RAM。

L1 总结来看是一种高密度部署方式，由于应用已经提前启动，并且对容器进行冻结，意味着这个应用实例 CPU 占用率为0，RAM 占用相当于之前的1/20，但是具备了毫秒级弹性的能力。L1的特点是启动速度极快，但是需要消耗资源，且只能垂直弹性。

L2 是通过将应用程序启动后在 RAM 中的指令和数据结构 dump 到磁盘文件，只需要在机器之间拷贝文件即可以达到横向弹性的能力，这个时间消耗主要是数据的网络传输时间+内存拷贝时间，大约在5秒左右就可以完成。L2 的成本开销只有网络磁盘容量，开销极低，可忽略不计。

L2 的每个 SNAOSHOT 对应一个可运行的实例，例如预计一个应用需要最大启动100个实例，那么需要提前生成100个 SNAOSHOT，每个 SNAOSHOT 对应一个运行实例，需要启动时，从远程磁盘加载这个 SNAPSHOT。

此方案通过 L1 和 L2 的组合来达到加速应用启动的目的，在支持一定流量脉冲能力下，可以最大50ms内启动任意应用，平均在10ms内完成。

方案二：应用热复制启动加速方案

L1 采用通过 fork 种子进程达到快速启动的效果，操作系统团队专门为此开发了 fork2 技术，与 Linux Native fork 的关键区别在于可以指定 PID 来 fork 一个进程。

L2 的单个 SNAPSHOT 可以创建多个进程，一对多关系。

两种自研方案的对比

方案一：不存在 UUID 问题，但是每种语言的 VM 要单独定制，成本效果相比方案二略差。

方案二：会存在 UUID 问题，若开发者希望应用的每个实例启动时，都赋值一个 UUID 给一个静态变量，但通过 fork 会导致每个实例的这个静态变量都相同，这与开发者预期不符。方案二的优势是更易实现、和语言无关、成本效果更优，适合 FaaS、NBF 这类场景或者开发者自己定义的开发框架，能避免 UUID 的问题。

整体来看，方案一的适用场景更广，但是实现成本更高，方案二较适合 FaaS、NBF 这类场景。

和 AWS Lambda 相比

Lambda 为了做到快速扩缩容，要求用户的应用以 Function 为单位开发，Lambda Runtime 动态加载 Function 来快速增加实例。

CSE 则通过将一个应用的多个实例启动后，共享相同的指令数据，抽取出不同的指令数据，每次启动实例只需要加载多实例的差异部分。因此可以透明兼容社区主流技术栈，如Spring Boot，PHP/Java/Python/Node.JS 等。

CSE 的成本优势

理论模型：

Serverless 方式应用占用的实例数随时在变化，因此可以多个应用错峰使用同一台机器。

量化分析：

Serverless 的成本优势是可以和 CPU Share &离在线混部等调度技术的成本优势做叠加，能给最终用户一个更优的总体成本。

CSE 的代码样例

HSF demo：

Spring Boot demo：

CSE 的生产实践

某电商业务 A：Serverless 化后，机器数量从11台降低到2台（2~10台之间波动），某促销节，服务流量峰值从数千瞬间飙到十多万，CSE 瞬间弹性扩容，从2台-->5台-->10台，流量峰值回落后又缩容到2台。

某电商业务 B：Serverless 化后，机器数量从4台到2台（2~10台之间波动）。

某电商业务 C：之前固定4台机器，Serverless 化完成后，机器数量变成1台（1~4台之间波动），预发可实现0 - 1台实例之间波动。

本文转载自公众号：阿里巴巴中间件，点击查看原文。

Kubernetes入门与进阶实战培训

Kubernetes入门与进阶实战培训将于2019年6月14日在北京开课，3天时间带你系统掌握Kubernetes， 学习效果不好可以继续学习。 本次培训包括：Docker基础、容器技术、 Docker 镜像、数据共享与持久化、Docker三驾马车、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等，点击下方图片或者点击阅读原文了解详情。