CSE：阿里在线应用如何演进成Serverless架构

Cloud Service Engine，简称CSE，是中间件部门研发的面向通用Serverless计算的中间件产品，目标是具有AWS Lambda的各类优点，同时能够解决AWS Lambda的关键技术缺陷。

AWS Lambda若是用于核心业务，可能会有如下缺陷：（仅表明我的观点）

• 要求用户以Function为单位开发，全新的开发框架，云厂商强绑定。社区主流技术栈迁移成本高。
• Function启动速度要足够快，毫秒级或者秒级，这个限制对适用场景有很强的约束。
• Function之间的调用经过API Gateway，响应时间更长。

CSE目前在集团内测中，本文非完整产品介绍，Serverless话题涉及范围极广，几乎包含了代码管理，测试，发布，运维，扩容等与应用生命周期关联的全部环节。本文主要回答我的在探索这个方向时的思考以及中间件部门正在作的解决方案，目标是尽量让开发者少改代码，甚至不改代码，就能具有AWS Lambda的技术优点。

我认为的Serverless是什么？

AWS对Serverless的定义

以上观点来自AWS官网 连接

AWS 定义的Serverless包含了哪些功能项

我的的补充观点

我的对Serverless的观点仅在AWS上补充，AWS的整个方案很是完善，可是没有解决存量应用如何迁移到Serverless架构，仅仅针对新开发的应用，建议用户用FaaS方式开发，才有机会变成Serverless架构。

要将Serverless架构大规模推广，必需要能有针对存量业务的解决方案。

Serverless在云计算中的位置是什么？

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

基于以上现状，应用的开发维护方式相比传统IDC模式的开发维护差异还不是很大，而AWS Lambda提供了一种全新的方式，只须要用户写业务代码，提交到云上，全部和机器容量，可用性，机器为单位的运维工做所有交给了云平台，这种模式极大的放大了云的弹性价值，真正作到了按需付费。

本文试图提供一种更规模化的解决方案，像AWS Lambda同样，能继续放大云的弹性价值，而且是能够兼容存量应用。

现存在线业务演变成Serverless架构的关键挑战是什么？

当前的在线应用程序具备如下特色

• 资源分配速度 = 分钟级
• 应用程序启动速度 = 10分钟+

基于以上客观条件，一般作法是提早预约好机器数量来应对任意时刻的流量峰值，假设上述技术参数变为毫秒级，就有机会将应用程序架构演变成下图所示方式。

上图中Service A在调用Service B时，若是B的容量充足，调用成功，若是B容量不足，这时候多是线程池满，可能直接触发限流阀值，A会收到一个错误码，A会直接调用资源总控系统，资源总控系统负责新分配一个Service B实例，这个分配的速度很是快，耗时几十毫秒，同时把B的服务地址直接返回给A，A将以前未完成的请求发送到新建立的Service B。

以上过程对于开发者彻底透明，具有了如下价值：

• 价值一：无需管理服务器，意味着无需容量评估，容量评估这件事情对于应用负责人一直是一个极难解的问题，由于咱们很难预测将来的峰值是什么。
• 价值二：持续扩展，以前的作法是每一个应用程序独占必定数量的资源，若是变成Serverless模式，意味着全部应用程序共享资源池，也意味着每一个应用程序几乎能够无限扩展。

• 价值三：按照请求计费，由于每一个实例的启动时间甚至比FaaS的函数启动时间还快，就能够像FaaS同样来核算成本，成本只与如下因素有关

  • 请求数量（QPS）
  • 每次请求CPU执行时间，例如100ms
  • 每一个实例的内存规格

综上所述：为了作到以上描述的分布式架构，关键技术点在于应用启动速度，这里的应用启动速度是指应用能够正常处理流量为止。

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

应用在启动过程当中一般会初始化多个组件，如各类中间件，各类数据结构，以及网络调用外部服务，在阿里内部普遍推广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一个进程

pid_t fork2(pid_t pid);

L2的单个SNAPSHOT能够建立多个进程，一对多关系。

自研两种方案对比

• 方案二：会存在UUID问题，如开发者但愿应用每一个实例启动都赋值一个UUID给一个静态变量，而经过fork会致使每一个实例的这个静态变量都相同，与开发者预期不符。
  优点是整个方案更易实现，语言无关，成本效果更优。

适合FaaS、盒马NBF这类场景或者开发者本身定义开发框架，能避免UUID这种状况的 场景使用。

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

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

与AWS Lambda方案对比

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

CSE经过将一个应用的多个实例启动后，共享相同的指令数据，抽取出不一样的指令数据，每次启动实例只须要加载多实例的差别部分。所以能够透明兼容社区主流技术栈，如Spring Boot，PHP/Java/Python/NodeJS等。

CSE的成本优点

理论模型

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

量化分析

Serverless的成本优点是能够和CPU Share&离在线混部等调度技术的成本优点作叠加，能给最终用户一个更优的整体成本。

CSE的代码样例

HSF demo

package com.test.pandora.hsf;

import com.alibaba.boot.hsf.annotation.HSFProvider;

@HSFProvider(serviceInterface = HelloWorldService.class)
public class HelloWorldServiceImpl implements HelloWorldService {
    @Override
    public String sayHello(String name) {
        return "hello : " + name;
    }
}

Spring Boot demo

package com.example.java.gettingstarted;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class HelloworldApplication {
  @RequestMapping("/")
  public String home() {
    return "Hello World!";
  }


  @RequestMapping("/health")
  public String healthy() {
    // Message body required though ignored
    return "Still surviving.";
  }

  public static void main(String[] args) {
    SpringApplication.run(HelloworldApplication.class, args);
  }
}

CSE的成功案例

• 盒马p0级服务，文描在双十二场景验证中，机器数量从11台到2台（2~10台之间波动）。

3.8女王节的最新数据，盒马导购域的P0级服务流量峰值从4000+瞬间飙到12万，CSE瞬间弹性扩容，从2台-->5台-->10台，流量峰值回落后又缩容到2台。

• 盒马p0级服务，天气在双十二场景验证中，机器数量从4台到2台（2~10台之间波动）。
• 1688的buyer-tools应用，以前固定4台机器，serverless化完成后，机器数量变成1台（1~4台之间波动）。预发可实现0 ~ 1台实例之间波动。

CSE的约束和限制

• 高脉冲型流量业务消耗的成本会更高。
• 应用尽量避免后台活动线程的CPU消耗。
• 应用尽量无状态。
• 应用尽量使用短链接，长连接要能支持断线毫秒级重连能力。

原文连接 本文为云栖社区原创内容，未经容许不得转载。