从函数计算到 Serverless 架构
Serverless
共 7033字，需浏览 15分钟
· 2022-08-03
作者 | 秋雨陈（本文选自“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 架构多产品逐渐 “一起战斗” 的表现，即开发者对应用进行管理，而不再是对代码和资源进行分别的管理。通过应用模块，开发者可以
1.迅速体验 Serverless 架构；便于学习和调研 Serverless 架构；
2.可以进行资源联动，并以应用纬度对资源进行管理，对权限进行划分，对业务进行运维；
值得注意的是，应用功能默认有一套标准的 GitOps 配置，通过基于代码仓库进行应用部署之后可以发现应用本身是基于 Serverless Devs 开发者工具实现的，这也充分的将线上平台与线下工具进行联动，在一定程度上可以进一步保证开发者使用体验的一致性。另外，在体验应用模块之后，会产生一些想法：
1.作为产品联动入口，应用模块需要牵扯其他资源投入，如何保证应用模块的资源可以逐渐的 “自运营” 将会成为应用模块能否成功的关键点之一（所谓自运营指的是不需要某固定团队主动提升应用数量、质量，而是可以由更多参与者自发的去做这项工作）；
2.应用模块在一定程度上应该属于 Serverless 而不仅仅是函数计算，否则过小的 Scope 会限制该模块的持续发展与生态演进；
3.作为拥有标准 GitOps 配置的应用，目前 CI/CD 能力过于单薄；
4.功能不完善，创建后的使用体验有待加强。例如，部署后的 “如何应用” 的引导、可观测要如何去做 ......
Serverless 工作流
Serverless 工作流在一定程度上可以认为是任务模块的一种升级表现。即单纯的任务模块是基于函数计算的，是异步的，Serverless 工作流在此基础上增加了编排能力：
通过 Serverless 工作流加持的任务将会：
具有服务的编排能力；
支持长时间运行流程；
可进行流程状态管理；
Serverless Devs
工具安装与配置 项目初始化 项目开发与部署
s config命令进行密钥信息配置：
s init命令，进行案例代码的初始化：
Serverless Devs 开发者工具针对阿里云 Serverless 架构来说，其最大的意义和价值，应该就在于：
下一代 Serverless 探索
用户体验相关
进一步 “统一”
天下大同也许是不可能的，但是技术发展的结局，趋于同质化却是一种趋势。
Serverless 架构同样如此，在云原生技术日益发展的今天，Serverless 架构已经不再是单纯的某个产品或者某种形态，它已逐渐的发展成为一种思想。
基于 Serverless 架构所传递的精神，已经有越来越多的 Serverless 产品出现，尽管如今，他们依旧是 “单打独斗” 的多，但随着时间的发展，这些产品注定会以一种 ”粘合剂“ 为核心，统一的，一致的为开发者提供服务。
从加法到减法
虽然 Serverless 架构并没有确切的定义，但他所要传达的心智却一定不是更复杂。
所以在未来的发展过程中，Serverless 架构的发展方向之一，就是做减法，减掉那些 “看似合理，却又没有道理的能力”。例如，为什么要透露出各种实例类型（弹性实例、GPU实例、性能实例、按量实例等）？为什么需要配置预留，需要配置弹性策略？
也许，很多为什么现在看来是合情合理，但是站在另一个维度上，他可能就是不合理的，所以做减法，不仅仅是一种勇气，更是一种对技术的挑战，对产品抽象能力的挑战。
功能探索
云开发模式
Serverless 架构的下一站是什么？这是一个很多人思考的问题。
函数计算仅仅是一个计算平台，可以单打，但也不能独斗，想要更容易被接受，资源的聚合、联动是必不可少的。尽管函数计算的应用模块，在一定程度上正在联动更多资源，但是这也仅仅是管理层面的，开发者所接触 Serverless 架构后，开发也是非常重要的一环节，那么云开发模式就值得考虑。
低代码模式
Serverless 架构在一定程度上是可以让很多功能模块化的，而模块化的进一步发展，就可能是低代码模式。
基于 Serverless 架构的低代码有望将 Serverless 思想应用到产品建设思想上，模块化的快速部署、更新，平稳发布与下线也都是符合 Serverless 思想的。
总结
作者：秋雨陈 原文阅读： https://developer.aliyun.com/article/984858
RECRUITMEN
1分钟 Serverless 极速抽盲盒
点击上方卡片了解活动详情！
立即部署你的专属盲盒平台！
评论