首次揭秘:阿里巴巴中间件在 Serverless 技术领域的探索

本文涉及的产品
Serverless 应用引擎 SAE,800核*时 1600GiB*时
函数计算FC,每月免费额度15元,12个月
简介: 在线应用不改代码也能迁移到 Serverless 架构,本文将揭秘阿里巴巴成千上万的在线应用如何演进到 Serverless 架构。

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 官网)

_Serverless_1


AWS 无服务器平台提供的功能:(摘自 AWS 官网)

_Serverless_2


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分钟+

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

上图中,Service A 在调用 Service B 时,如果 B 的容量充足,则调用成功;如果 B 的容量不足,这时候如果线程池满,则直接触发限流阀值,A 会收到一个错误码,然后直接调用资源总控系统,资源总控系统负责新分配一个 Service B 实例,这个分配的速度非常快,耗时几十毫秒,同时把 B 的服务地址直接返回给 A,A 会将之前未完成的请求发送到新创建的 Service B。


以上过程对于开发者完全透明,具备了以下价值:

  • 价值一:无需管理服务器,即无需容量评估;容量评估这件事情对于应用负责人一直是一个极难解的问题,因为我们很难预测未来的峰值是什么。
  • 价值二:持续扩展;之前的做法是每个应用程序独占一定数量的资源,如果变成Serverless 模式,所有应用程序可以共享资源池,每个应用程序几乎可以无限扩展。
  • 价值三:按照请求计费;因为每个实例的启动时间甚至比 FaaS 的函数启动时间还快,就可以像 FaaS 一样来核算成本,成本只与以下因素有关

    • 请求数量(QPS)
    • 每次请求CPU执行时间,例如100ms
    • 每个实例的内存规格


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


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


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

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

_Serverless_3
_Serverless_4
_Serverless_6
_Serverless_8
_Serverless_5


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 问题,但是每种语言的 VM 要单独定制,成本效果相比方案二略差。
  • 方案二:会存在 UUID 问题,若开发者希望应用的每个实例启动时,都赋值一个 UUID 给一个静态变量,但通过 fork 会导致每个实例的这个静态变量都相同,这与开发者预期不符。方案二的优势是更易实现、和语言无关、成本效果更优,适合 FaaS、NBF 这类场景或者开发者自己定义的开发框架,能避免 UUID 的问题。


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


和 AWS Lambda 相比

_Serverless_9


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


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


CSE 的成本优势

理论模型:

_Serverless_10


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

量化分析:

_Serverless_11
_Serverless_12
_Serverless_14
_Serverless_13


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 的生产实践

_Serverless_15


某电商业务 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台实例之间波动。



本文作者:
王小瑞,花名:誓嘉,阿里巴巴资深技术专家,Apache RocketMQ 创始人&Chair,近期负责推动阿里巴巴在线业务向 Serverless 架构的演进,以及消息中间件产品线的云计算方向,是阿里巴巴中间件创新项目实验室&消息中间件团队负责人。

中间件团队社招:
中间件创新项目实验室&消息中间件团队正在招聘中间件分布式系统研发专家,杭州/北京/深圳,P7/P8/P9,简历直达 shijia.wxr#taobao.com ,详情请点这里

相关实践学习
基于函数计算一键部署掌上游戏机
本场景介绍如何使用阿里云计算服务命令快速搭建一个掌上游戏机。
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
相关文章
|
1月前
|
人工智能 运维 Cloud Native
云原生技术实践营 · 深圳站——Serverless + AI 专场邀您参会!
云原生技术实践营深圳站聚焦Serverless+AI,6月21日探索技术结合新思路,助力降低GPU成本,简化开发运维。限额80人,报名审核制,活动涵盖Serverless趋势、AIGC应用、AI算力优化等议题,还有实操体验与现场抽奖。
云原生技术实践营 · 深圳站——Serverless + AI 专场邀您参会!
|
3天前
|
运维 Kubernetes Cloud Native
云原生技术的未来演进:探索服务网格和无服务器架构的融合
随着企业数字化转型的不断深入,云原生技术已成为推动现代软件开发的关键力量。本文深入探讨了服务网格和无服务器架构这两大云原生技术趋势,分析了它们各自的优势以及未来可能的融合点。通过对比分析和案例研究,我们揭示了这两种技术如何互补并共同推进云原生生态系统的发展,同时指出了实践中面临的挑战和潜在的解决方案。 【7月更文挑战第22天】
|
1月前
|
人工智能 Cloud Native Serverless
云原生技术实践营 · 深圳站:Serverless + AI 专场开启报名!
“云原生技术实践营 · 深圳站 ——Serverless + AI 应用开发专场”是一场以 Serverless 为主题的技术活动,通过一个下午的时间增进对 Serverless 技术的理解,快速上手,活动受众以关注 Serverless 技术的开发者、企业决策人、云原生领域创业者为主,活动形式为演讲、动手实操。
|
1月前
|
人工智能 运维 Cloud Native
活动回顾丨云原生技术实践营 Serverless + AI 专场 (深圳站) 回顾 & PPT 下载
云原生技术实践营 Serverless + AI 专场 (深圳站) 回顾。
|
1月前
|
运维 Cloud Native 开发者
云原生技术演进:从微服务到无服务器计算
【6月更文挑战第22天】 云原生技术如同一场持续的演化之旅,它不断重塑着应用的开发与部署方式。本文将探讨云原生技术如何从微服务架构演变至无服务器计算,以及这一转变对开发者和运维人员带来的深远影响。通过分析容器化、持续集成/持续部署(CI/CD)、微服务治理等关键概念,我们将揭示云原生技术如何在提高应用的可伸缩性、灵活性和可靠性的同时,也提出了新的挑战和机遇。
|
2月前
|
人工智能 Serverless 异构计算
上海站丨飞天技术沙龙 Serverless + AI 专场开启报名!
"飞天技术沙龙——Serverless 技术实践营"将于2024年5月31日举行,聚焦Serverless在AI中的应用。活动包括演讲、实操,探讨Serverless演进趋势、AI应用开发及降低成本等议题。限额80人,报名审核制,现场还有大奖和证书待您领取。扫描链接<https://summit.aliyun.com/Serverless2024shanghai>报名。
上海站丨飞天技术沙龙 Serverless + AI 专场开启报名!
|
1月前
|
人工智能 Serverless 开发者
活动回顾丨飞天技术沙龙 Serverless + AI 专场(上海站)回顾 & PPT 下载
活动回顾丨飞天技术沙龙 Serverless + AI 专场(上海站)回顾 & PPT 下载。
活动回顾丨飞天技术沙龙 Serverless + AI 专场(上海站)回顾 & PPT 下载
|
1月前
|
芯片
汉化FC(红白机)游戏需要用到哪些技术?
这篇文章介绍了FC(红白机)游戏文本汉化的基本流程和技术知识。主要步骤包括分析游戏ROM、寻找文本字符串、学习游戏代码、修改文本、修改ROM头信息、重新映射、测试和修正。文章还提供了汉化实例,详细讲解了如何使用各种工具,如VirtuaNES Debugger、NO$NES、6502 Simulator等进行ROM分析和修改。此外,文章还介绍了如何使用汇编语言编写自定义程序以实现大字体汉化和在游戏画面切换时恢复原来的VROM。整个过程需要对6502汇编语言、NES硬件架构和ROM结构有一定的理解和编程经验。
|
1月前
|
资源调度 运维 Cloud Native
云原生架构技术之无服务器技术
当这些BaaS云服务日趋完善时,无服务器技术(Serverless)因为屏蔽了服务器的各种运维复杂度,让开发人员可以将更多精力用于业务逻辑设计与实现,而逐渐成为云原生主流技术之一。
47 5
|
1月前
|
存储 NoSQL 机器人
Knative 实战:基于 Knative Serverless 技术实现天气服务-下篇
Knative 实战:基于 Knative Serverless 技术实现天气服务-下篇

热门文章

最新文章

相关产品

  • 函数计算