网络技术

找论坛
独角的犀牛
Lv4 太平洋舰队中尉
太平洋舰队中尉 贡献552,距离下一级还需148贡献
楼主
2019-05-27 15:59 0 0 只看楼主
电梯直达 
Serverless 话题涉及范围极广,几乎包含了代码管理、测试、发布、运维和扩容等与应用生命周期关联的所有环节。AWS Lambda 是 Serverless 领域的标志性产品,但如果将其应用于核心业务,可能会遇到以下难题:(仅代表作者个人观点)首度揭秘:

  • 要求用户以 Function 为单位进行开发,全新的开发框架,云厂商强绑定,社区主流技术栈迁移成本高;
  • Function 启动速度要足够快,毫秒级或者秒级,这个限制对适用场景有很强的约束;
  • Function 之间的调用通过 API Gateway,响应时间更长。
本文将介绍阿里云中间件团队在探索 Serverless 过程中的思考以及正在做的事,目的是尽可能让开发者少改代码,甚至不改代码,就能具备 AWS Lambda 的技术优势。

Cloud Service Engine 云服务引擎(以下简称CSE),是阿里云中间件团队开发的面向通用 Serverless 计算的中间件产品,目的是具备 AWS Lambda 的各种优势,同时可以解决用户在使用 AWS Lambda 时遇到的难题。
什么是 Serverless
AWS 对 Serverless 定义是:
评论
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 架构的挑战**
存量在线应用程序具有以下特点

  • 资源分配速度 = 分钟级
  • 应用程序启动速度 = 10分钟+
基于以上客观条件,通常做法是提前预定好机器数量来应对任意时刻的流量峰值,假设上述技术参数变为毫秒级,就有机会将应用程序架构演变成下图所示方式。
评论
上图中,Service A 在调用 Service B 时,如果 B 的容量充足,则调用成功;如果 B 的容量不足,这时候如果线程池满,则直接触发限流阀值,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 可以创建多个进程,一对多关系。

两种自研方案的对比
[hr]

  • 方案一:不存在 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
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 demopackage 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@RestControllerpublic 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 的生产实践评论
某电商业务 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台实例之间波动。

本文为云栖社区原创内容,未经允许不得转载。

您需要登录后才可以发帖 登录 | 立即注册

其他登录方式:

常用表情
太平洋电脑网论坛帖子仅代表作者本人意见,不代表网站立场。请勿轻信特价、汇款、中奖等信息,
请勿轻易透露个人资料,因此产生的一切后果,PConline不承担任何责任
回复 发新帖 找论坛 反馈 回顶部