首页 文章详情

从函数计算到 Serverless 架构

Serverless | 74 2022-08-03 22:25 0 0 0
UniSMS (合一短信)

作者 | 秋雨陈(本文选自“Serverless 函数计算征集令”征文)


前言


随着 Serverless 架构不断发展,各云厂商和开源社区都已经布局 Serverless 领域,一方面表现在云厂商推出传统服务/业务的 Serverless 化版本,或者 Serverless 计算平台;另一方面表现在开源社区中 Serverless 项目逐渐丰富起来,无论是平台类还是工具类的开源项目、或者是框架类的开源项目,都如雨后春笋般快速成长。

任何技术,在这样繁荣发展背后,都会快速升级和迭代,Serverless 架构也不例外,从阿里云的 FaaS 产品发展过程中,不难看出 Serverless 架构在提效和降本的道路上不断的场景化,特色化;在产品形态上也不断的趋于完整化,统一化,虽然距离 “大道至简” 还有一定的距离,但是也只是时间的问题了。

从思想到产品升级


Serverless 架构在不断发展,无论是产品形态还是技术架构都可以用日新月异来描述。

Serverless 精神的更迭


最初,Serverless 架构指的是 FaaS 与 BaaS 的结合,认为开发者可以不用花费更多的精力在服务器等底层资源上,而是可以将精力放在更具价值的业务逻辑之上。这也是文章《Serverless Architectures》中所强调的观点。


但随着时间发展,大家发现,对于 Serverless 架构这样的描述过于单薄,没有凸显出 Serverless 架构为业务带来的技术红利,也没能表现出 Serverless 所交付的心智。


所以 UC 伯克利在《Cloud Programming Simplified: A Berkeley View on Serverless Computing》中对 Serverless 架构进一步的定义:对于被认为是 Serverless 架构的服务/产品还需要具备按量付费和弹性伸缩的特点,并认为, long-run 的运行模式并不符合 Serverless 精神。


云计算相关技术的发展,往往有一个特点:云厂商的驱动性非常强,因为云厂商往往会最先感知到普遍性的用户需求,并且有足够的数据支撑其做出合理的判断与创新。所以 Serverless 架构的创新很多时候也都是由厂商驱动的;在事件驱动与函数计算的发展下,厂商逐渐发现函数计算的模式 “短时运行” 没有办法满足更多用户的诉求,此时一种 long-run 模式的 Serverless 计算服务就逐渐的被孵化出来了。至此,Serverless 架构也从最初的单薄,逐渐完善,通过 “自我革新”,完成了新一轮业务能力的自我丰富与产品功能的自我完善。


随着 long-run 模式逐渐被开发者们认可,传统 Serverless 架构的定义有点 “格格不入”:既不能在模式上覆盖最新的 Serverless 产品纬度,也不能在形态上描述清 Serverless 的特性。


此时 Serverless 架构定的义,就自然而然的得以升级,例如:


  • Serverless 应该是 FaaS + BaaS + CaaS,

  • Serverless 应该是 FaaS + BaaS + Others,

  • Serverless 就是 Server + Less,即服务端免运维/低运维的形式就是真正意义上的 Serverless 架构。


至此,Serverless 架构实现了此阶段下的产品形态升级与 Serverless 精神的更迭。

从函数到更 Serverless


通过阿里云官网,不难发现其 Serverless 产品形态还是相对完整的:


  • 计算平台:从函数计算到容器镜像再到微服务形态;
  • 基础产品/服务:存储产品、数据库等产品的 Serverless 形态;

Serverless 架构的热度不断增加,各产品也需要借着热度进一步突破和创新,所以 Serverless 这个词 “被乱用” 再所难免;每个团队都有自己的特色,基于 Serverless 架构完善和更迭自身能力,也是产品发展的必经之路,就像数据库发展到云数据库,再发展到云原生数据库,再发展到 Serverless 数据库一样;
所以,Serverless 架构需要一个 “粘合剂”,将各种 Serverless 产品进行进一步的链接,使其不是 “混杂在诸多产品中的某些产品”,而是 “可以联合起来解决某个问题的具体功能”,换句话来说将不同的产品联合到一起,以应用的维度为开发者提供场景化支持,这也是 Serverless 架构从资源朝着应用,再朝着业务发展的必经之路。
推出 “应用的概念”,试图以计算平台和核心,通过 BaaS 产品的联动,让本来 “杂乱的花园”,逐渐的变得规矩,有条理起来;让本来需要开发者 “痛苦的选择”,逐渐的变成场景化推荐,流程化引导。

产品与功能体验


本次活动是阿里云 Serverless 函数计算评测,所以本文仅对函数计算与其相关产品进行体验,包括函数计算本身(包括三个主要模块:基础模块服务与函数和上层封装模块应用、任务),Serverless 工作流以及开源项目 Serverless Devs。

阿里云函数计算


服务与函数


函数与服务的功能如下图所示:



函数计算产品形态为两层结构:服务、函数。


  • 服务:一种逻辑关系,表示的是一系列函数以及部分公共配置的集合;即带有特定属性的函数集合;
  • 函数:一种确切的资源或业务逻辑;由代码,触发器以及相关的配置组成;

函数计算的两层概念为开发带来了一定的便利:
  • 业务划分更清晰:可以让开发者更清晰的将同类型业务/功能划分在一个服务下,不仅让页面更清晰,也会让管理(包括资源分配,权限划分,账单等)更便利;
  • 让环境划分更简单:通过服务将业务进行归类之后,有助于基于服务进行环境的划分。通过服务进行不同环境的划分,相比针对函数进行环境的划分会更便利和更容易被接受;

函数计算的上手流程相对简单,通过函数计算文档,可以看到整体流程 : 


即,开发者只需要完成代码的开发和部署,即可实现业务的弹性伸缩和按量付费能力的加持,这也符合 CNCF 在白皮书中对 Serverless 架构流程定义的规范。通过阿里云函数计算控制台可以快速进行这个流程的体验,点击 “服务及函数” 选项,就可以看到服务列表:
此时可以根据需要,创建服务和函数:
完成之后,可以在线编辑代码与在线测试:
至此,完成了函数计算上手,在整个过程中,有几个明显的感觉:
1.从零上手流程还是比较顺利的,只要多关注标注信息,有一些研发经验,是可以快速的创建服务与函数的;
2.阿里云函数计算功能相对来说是全面的,包括单实例多并发,预留,版本&灰度,可观测性等,可以满足绝大部分的应用场景,即便某些框架因 Serverless 架构丧失了部分特性,也可以通过产品侧所提供的能力解决;
3.可观测性相对来说很完整,从 trace、log、metrics 等几个方面入手,可以满足开发者在可观测上大部分需求,另外值得好评的是控制台页面的实时日志功能,对开发调试很有帮助;日志搜索功能有待加强,例如若想快速找出日志前后文还需要进一步依赖日志服务等;
4.WebIDE 很强大,通过计算资源的分配可以在线进行代码编写和项目构建,但是 WebIDE 的环境和函数计算的环境依旧是不通的,不仔细研读和体验,会被误会在 WebIDE 中的调试即是在函数环境下的调试;
5.阿里云函数计算所特有的 HTTP 函数,可以轻松地将 Web 应用迁移部署到 Serverless 架构,但是 HTTP 函数和时间触发器没办法一同配置;
6.阿里云函数计算的环境变量没有 Secret 能力;环境变量往往涉及到敏感信息,能否加密输出是安全性的一种表现;
7.阿里云函数计算有很多代码目录是被限制读写的,但是并不是所有运行时都会被限制读写,这种不对齐会让开发者产生比较大的疑惑,尽管其他厂商也多是这样设计的,但是却没人说这样设计的原因;
8.阿里云函数计算从服务到函数,再到可观测、自定义域名等模块,拥有较多功能/配置,目前在使用过程中难以快速找到部分功能。例如经常会找不到预留实例的配置入口等。

任务


除服务与函数,函数计算还有一个模块:任务。



在任务页面的描述汇总,不难看出它实际上是函数的一种变形:



通过创建任务的过程,以及创建任务结束页面:



同样可以验证刚刚的想法:任务的本质依旧是函数计算,只不过:


  • 弱化了服务的概念,可以通过简单配置,完成任务创建;
  • 本质是函数异步任务的另一种表达,将异步任务抽象成一个可以让开发者快速的创建和发布任务的功能;

由于任务往往是异步的,所以从上游经过函数的处理再传递到下游,整个链路的串联是非常重要的,这也是对云厂商服务一致性与可观测性的一种考验。

通过对任务的体验,整体感觉是比较顺畅的,通过抽象出来的产品化能力,让任务的创建流程和步骤更加精简,可以帮助 “特定的开发者快速使用”;但是也会对一些新手用户产生困扰:应用、任务、服务及函数是什么关系?任务和函数有什么区别?

应用


与任务相同的是,应用也是建立在服务与函数之上的;与任务不同的是,应用不仅仅是函数计算。可以认为,应用是函数计算中,联动其他产品的入口或者 Serverless 应用的管理平台。


通过应用创建页面,可以快速体验 Serverless 应用:



可以看到,应用与任务,服务及函数的很大区别在于,应用是场景化非常明确的一个模块,所有的创建过程和导入的过程均是在建设 “场景化” 的心智。


通过应用创建页面,可以看到目前已经有框架、音视频处理等多个场景的应用,以其中的图片压缩为例进行体验:



可以通过引导快速完成应用创建,整个流程最为精简。创建完成之后,可以得到最终的体验页面:



在体验页面中,可以体验当前应用的功能。


应用的出现,无疑是 Serverless 架构多产品逐渐 “一起战斗” 的表现,即开发者对应用进行管理,而不再是对代码和资源进行分别的管理。通过应用模块,开发者可以


1.迅速体验 Serverless 架构;便于学习和调研 Serverless 架构;


2.可以进行资源联动,并以应用纬度对资源进行管理,对权限进行划分,对业务进行运维;


值得注意的是,应用功能默认有一套标准的 GitOps 配置,通过基于代码仓库进行应用部署之后可以发现应用本身是基于 Serverless Devs 开发者工具实现的,这也充分的将线上平台与线下工具进行联动,在一定程度上可以进一步保证开发者使用体验的一致性。另外,在体验应用模块之后,会产生一些想法:


1.作为产品联动入口,应用模块需要牵扯其他资源投入,如何保证应用模块的资源可以逐渐的 “自运营” 将会成为应用模块能否成功的关键点之一(所谓自运营指的是不需要某固定团队主动提升应用数量、质量,而是可以由更多参与者自发的去做这项工作);

2.应用模块在一定程度上应该属于 Serverless 而不仅仅是函数计算,否则过小的 Scope 会限制该模块的持续发展与生态演进;

3.作为拥有标准 GitOps 配置的应用,目前 CI/CD 能力过于单薄;

4.功能不完善,创建后的使用体验有待加强。例如,部署后的 “如何应用” 的引导、可观测要如何去做 ......

Serverless 工作流


Serverless 工作流在一定程度上可以认为是任务模块的一种升级表现。即单纯的任务模块是基于函数计算的,是异步的,Serverless 工作流在此基础上增加了编排能力:

通过 Serverless 工作流加持的任务将会:

  • 具有服务的编排能力;

  • 支持长时间运行流程;

  • 可进行流程状态管理;


在体验 Serverless 工作流之后,也有一些思考:

1.与应用模块一样,如果 Serverless 工作流定义的 Scope 过小,可能只是函数计算的编排,会让这个功能丧失很大的竞争力;
2.工作流的整体体验是比较顺畅的,如果可以将功能持续优化,工作流的易用性会更高;

Serverless Devs


关于阿里云 Serverless  Devs 上手,可分为三个流程:

  • 工具安装与配置
  • 项目初始化
  • 项目开发与部署

由于 Serverless Devs 项目是发布在 Npm 的,所以在安装之前需要开发者先配置 Node.js 开发环境,再通过 npm 工具进行工具的安装。安装完成之后,可以通过 s config命令进行密钥信息配置:



可以通过s init命令,进行案例代码的初始化:


完成初始化之后,可以直接进行业务的部署:


部署完成后,可以通过浏览器打开项目,进行预览:



同样基于这三个流程,Serverless Devs 也是可以快速的与常见的流水线进行集成,目前官方提供的案例包括 Github Action,Gitee Go,Jenkins,以及云效等,但是阅读过相关文档后,不难发现,即便是其他的流水线,也是同样的操作流程。

Serverless Devs 开发者工具针对阿里云 Serverless 架构来说,其最大的意义和价值,应该就在于:


1.更大的 Scope,留下了更大的想象空间;
2.是产品联动的基础,通过部署编排,组件化模式,让更多产品联动;
3.用户体验升级,可以帮助开发体验阿里云 Serverless 产品,并基于模板案例,快速上手;
从开发角度来看,Serverless Devs 开发者工具解决了 Serverless 领域常见的几个痛点:


1.所涉及到资源和服务比较多,难以在流水线中进行整体的编排和发布;
2.“伪命题:Serverless 不需要用户关注操作系统等内容”,但是在实际使用过程中,用户不得不关注系统,因为这会影响项目打包和构建的结果;
3.由于资源过于零散,环境过于独立,Serverless 架构调试复杂度非常高;

下一代 Serverless 探索


用户体验相关

进一步 “统一”

天下大同也许是不可能的,但是技术发展的结局,趋于同质化却是一种趋势。

Serverless 架构同样如此,在云原生技术日益发展的今天,Serverless 架构已经不再是单纯的某个产品或者某种形态,它已逐渐的发展成为一种思想。

基于 Serverless 架构所传递的精神,已经有越来越多的 Serverless 产品出现,尽管如今,他们依旧是 “单打独斗” 的多,但随着时间的发展,这些产品注定会以一种 ”粘合剂“ 为核心,统一的,一致的为开发者提供服务。

从加法到减法

虽然 Serverless 架构并没有确切的定义,但他所要传达的心智却一定不是更复杂。


所以在未来的发展过程中,Serverless 架构的发展方向之一,就是做减法,减掉那些 “看似合理,却又没有道理的能力”。例如,为什么要透露出各种实例类型(弹性实例、GPU实例、性能实例、按量实例等)?为什么需要配置预留,需要配置弹性策略?


也许,很多为什么现在看来是合情合理,但是站在另一个维度上,他可能就是不合理的,所以做减法,不仅仅是一种勇气,更是一种对技术的挑战,对产品抽象能力的挑战。

功能探索

云开发模式


Serverless 架构的下一站是什么?这是一个很多人思考的问题。


函数计算仅仅是一个计算平台,可以单打,但也不能独斗,想要更容易被接受,资源的聚合、联动是必不可少的。尽管函数计算的应用模块,在一定程度上正在联动更多资源,但是这也仅仅是管理层面的,开发者所接触 Serverless 架构后,开发也是非常重要的一环节,那么云开发模式就值得考虑。


低代码模式


Serverless 架构在一定程度上是可以让很多功能模块化的,而模块化的进一步发展,就可能是低代码模式。


基于 Serverless 架构的低代码有望将 Serverless 思想应用到产品建设思想上,模块化的快速部署、更新,平稳发布与下线也都是符合 Serverless 思想的。


总结


Serverless 架构,在未来将会像云主机,容器服务一样,成为云计算时代新的基础设施;在对基础设施的维护的基础上,为开发者提供更为场景化的服务有望成为 Serverless 架构突破自我瓶颈的突破口。
在未来,Serverless 将会是一种 “形态不统一,但是目标很统一” 的技术架构思想,开发者可以以一种更为一致性的体验,快速使用 Serverless 架构构建自己的场景化应用,当然这里的 Serverless 包括了不同形态的服务,例如数据库、网关、函数计算等。
综上所述,Serverless 架构在不断的发展,Serverless 架构的精神也在不断的更迭,从函数计算到应用,从开发、运维到全生命周期,Serverless 架构要回答的问题很多,要做的事情更多。
作者:秋雨陈
原文阅读:
https://developer.aliyun.com/article/984858










RECRUITMEN

1分钟 Serverless 极速抽盲盒




点击上方卡片了解活动详情!


1 分钟 Serverless 极速抽盲盒!使用阿里云函数计算+Serverless 应用中心部署完成 1 个场景体验,即有机会获得 1300 元隐藏款、机械键盘、天猫精灵等惊喜福利盲盒!
8.1-8.12 工作日期间每天放送,先到先得!

立即部署你的专属盲盒平台!

good-icon 0
favorite-icon 0
收藏
回复数量: 0
    暂无评论~~
    Ctrl+Enter