从函数计算到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 架构流程定义的规范。通过阿里云函数计算控制台可以快速进行这个流程的体验，点击＂服务及函数＂选项，就可以看到服务列表：
　　此时可以根据需要，创建服务和函数：
　　完成之后，可以在线编辑代码与在线测试：
　　至此，完成了函数计算上手，在整个过程中，有几个明显的感觉：  从零上手流程还是比较顺利的，只要多关注标注信息，有一些研发经验，是可以快速的创建服务与函数的；  函数计算功能相对来说是全面的，包括单实例多并发，预留，版本&灰度，可观测性等，可以满足绝大部分的应用场景，即便某些框架因 Serverless 架构丧失了部分特性，也可以通过产品侧所提供的能力解决；  可观测性相对来说很完整，从 trace、log、metrics 等几个方面入手，可以满足开发者在可观测上大部分需求，另外值得好评的是控制台页面的实时日志功能，对开发调试很有帮助；日志搜索功能有待加强，例如若想快速找出日志前后文还需要进一步依赖日志服务等；  WebIDE 很强大，通过计算资源的分配可以在线进行代码编写和项目构建，但是 WebIDE 的环境和函数计算的环境依旧是不通的，不仔细研读和体验，会被误会在 WebIDE 中的调试即是在函数环境下的调试；  函数计算所特有的 HTTP 函数，可以轻松地将 Web 应用迁移部署到 Serverless 架构，但是 HTTP 函数和时间触发器没办法一同配置；  函数计算的环境变量没有 Secret 能力；环境变量往往涉及到敏感信息，能否加密输出是安全性的一种表现；  函数计算有很多代码目录是被限制读写的，但是并不是所有运行时都会被限制读写，这种不对齐会让开发者产生比较大的疑惑，尽管其他厂商也多是这样设计的，但是却没人说这样设计的原因；  函数计算从服务到函数，再到可观测、自定义域名等模块，拥有较多功能/配置，目前在使用过程中难以快速找到部分功能。例如经常会找不到预留实例的配置入口等；
　　任务
　　除服务与函数，函数计算还有一个模块：任务。
　　在任务页面的描述汇总，不难看出它实际上是函数的一种变形：
　　通过创建任务的过程，以及创建任务结束页面：
　　同样可以验证刚刚的想法：任务的本质依旧是函数计算，只不过：  弱化了服务的概念，可以通过简单配置，完成任务创建；  本质是函数异步任务的另一种表达，将异步任务抽象成一个可以让开发者快速的创建和发布任务的功能；
　　由于任务往往是异步的，所以从上游经过函数的处理再传递到下游，整个链路的串联是非常重要的，这也是对云厂商服务一致性与可观测性的一种考验。
　　通过对任务的体验，整体感觉是比较顺畅的，通过抽象出来的产品化能力，让任务的创建流程和步骤更加精简，可以帮助＂特定的开发者快速使用＂；但是也会对一些新手用户产生困扰：应用、任务、服务及函数是什么关系？任务和函数有什么区别？
　　应用
　　与任务相同的是，应用也是建立在服务与函数之上的；与任务不同的是，应用不仅仅是函数计算。可以认为，应用是函数计算中，联动其他产品的入口或者 Serverless 应用的管理平台。
　　通过应用创建页面，可以快速体验 Serverless 应用：
　　可以看到，应用与任务，服务及函数的很大区别在于，应用是场景化非常明确的一个模块，所有的创建过程和导入的过程均是在建设＂场景化＂的心智。通过应用创建页面，可以看到目前已经有框架、音视频处理等多个场景的应用，以其中的图片压缩为例进行体验：
　　可以通过引导快速完成应用创建，整个流程最为精简。创建完成之后，可以得到最终的体验页面：
　　在体验页面中，可以体验当前应用的功能。
　　应用的出现，无疑是 Serverless 架构多产品逐渐＂一起战斗＂的表现，即开发者对应用进行管理，而不再是对代码和资源进行分别的管理。通过应用模块，开发者可以：  快速体验 Serverless 架构；便于学习和调研 Serverless 架构；  可以进行资源联动，并以应用纬度对资源进行管理，对权限进行划分，对业务进行运维；
　　值得注意的是，应用功能默认有一套标准的 GitOps 配置，通过基于代码仓库进行应用部署之后可以发现应用本身是基于 Serverless Devs 开发者工具实现的，这也充分的将线上平台与线下工具进行联动，在一定程度上可以进一步保证开发者使用体验的一致性。另外，在体验应用模块之后，会产生一些想法：  作为产品联动入口，应用模块需要牵扯其他资源投入，如何保证应用模块的资源可以逐渐的＂自运营＂将会成为应用模块能否成功的关键点之一（所谓自运营指的是不需要某固定团队主动提升应用数量、质量，而是可以由更多参与者自发的去做这项工作）；  应用模块在一定程度上应该属于 Serverless 而不仅仅是函数计算，否则过小的 Scope 会限制该模块的持续发展与生态演进；  作为拥有标准 GitOps 配置的应用，目前 CI/CD 能力过于单薄；  功能不完善，创建后的使用体验有待加强。例如，部署后的＂如何应用＂的引导、可观测要如何去做 ......
　　Serverless 工作流
　　Serverless 工作流在一定程度上可以认为是任务模块的一种升级表现。即单纯的任务模块是基于函数计算的，是异步的，Serverless 工作流在此基础上增加了编排能力：
　　通过 Serverless 工作流夹持的任务将会：  具有服务的编排能力；  支持长时间运行流程；  可进行流程状态管理；
　　在体验 Serverless 工作流之后，也有一些思考：  与应用模块一样，如果 Serverless 工作流定义的 Scope 过小，可能只是函数计算的编排，会让这个功能丧失很大的竞争力；  工作流的整体体验是比较顺畅的，如果可以将功能持续优化，工作流的易用性会更高；
　　Serverless Devs
　　关于阿里云 Serverless Devs 上手，可分为三个流程：  工具安装与配置  项目初始化  项目开发与部署
　　由于 Serverless Devs 项目是发布在 Npm 的，所以在安装之前需要开发者先配置 Node.js 开发环境，再通过 npm 工具进行工具的安装。安装完成之后，可以通过  s config  命令进行密钥信息配置：
　　可以通过 s init  命令，进行案例代码的初始化：
　　完成初始化之后，可以直接进行业务的部署：
　　部署完成后，可以通过浏览器打开项目，进行预览：
　　同样基于这三个流程，Serverless Devs 也是可以快速的与常见的流水线进行集成，目前官方提供的案例包括Github Action，Gitee Go，Jenkins，以及云效等，但是阅读过相关文档后，不难发现，即便是其他的流水线，也是同样的操作流程。
　　Serverless Devs 开发者工具针对阿里云 Serverless 架构来说，其最大的意义和价值，应该就在于：  更大的 Scope，留下了更大的想象空间；  是产品联动的基础，通过部署编排，组件化模式，让更多产品联动；  用户体验升级，可以帮助开发体验阿里云 Serverless 产品，并基于模板案例，快速上手；
　　从开发角度来看，Serverless Devs 开发者工具解决了 Serverless 领域常见的几个痛点：  所涉及到资源和服务比较多，难以在流水线中进行整体的编排和发布；  ＂伪命题：Serverless 不需要用户关注操作系统等内容＂，但是在实际使用过程中，用户不得不关注系统，因为这会影响项目打包和构建的结果；  由于资源过于零散，环境过于独立，Serverless 架构调试复杂度非常高；  下一代Serverless探索
　　用户体验相关
　　进一步的＂统一＂
　　天下大同也许是不可能的，但是技术发展的结局，趋于同质化却是一种趋势。
　　Serverless 架构同样如此，在云原生技术日益发展的今天，Serverless 架构已经不再是单纯的某个产品或者某种形态，他应逐渐的发展成为一种思想。
　　基于 Serverless 架构所传递的精神，已经有越来越多的 Serverless 产品出现，尽管如今，他们依旧是＂单打独斗＂的多，但随着时间的发展，这些产品注定会以一种＂粘合剂＂为核心，统一的，一致的为开发者提供服务。
　　从加法到减法
　　虽然 Serverless 架构并没有确切的定义，但他所要传达的心智却一定不是更复杂。
　　所以在未来的发展过程中，Serverless架构的发展方向之一，就是做减法，减掉那些＂看似合理，却又没有道理的能力＂。例如，为什么要透露出各种实例类型（弹性实例、GPU实例、性能实例、按量实例等）？为什么需要配置预留，需要配置弹性策略？
　　也许，很多为什么现在看来是合情合理，但是站在另一个维度上，他可能就是不合理的，所以做减法，不仅仅是一种勇气，更是一种对技术的挑战，对产品抽象能力的挑战。
　　功能探索
　　云开发模式
　　Serverless 架构的下一站是什么？这是一个很多人思考的问题。
　　函数计算仅仅是一个计算平台，可以单打，但也不能独斗，想要更容易被接受，资源的聚合、联动是必不可少的。尽管函数计算的应用模块，在一定程度上正在联动更多资源，但是这也仅仅是管理层面的，开发者所接触Serverless 架构后，开发也是非常重要的一环节，那么云开发模式就值得考虑。  低代码模式
　　Serverless 架构在一定程度上是可以让很多功能模块化的，而模块化的进一步发展，就可能是低代码模式。
　　基于 Serverless 架构的低代码有望将 Serverless 思想应用到产品建设思想上，模块化的快速部署、更新，平稳发布与下线也都是符合 Serverless 思想的。  总结
　　Serverless架构，在未来将会像云主机，容器服务一样，成为云计算时代新的基础设施；在对基础设施的维护的基础上，为开发者提供更为场景化的服务有望成为 Serverless 架构突破自我瓶颈的突破口。
　　在未来，Serverless 将会是一种＂形态不统一，但是目标很统一＂的技术架构思想，开发者可以以一种更为一致性的体验，快速使用 Serverless 架构构建自己的场景化应用，当然这里的Serverless包括了不同形态的服务，例如数据库、网关、函数计算等。
　　综上所述，Serverless 架构在不断的发展，Serverless 架构的精神也在不断的更迭，从函数计算到应用，从开发、运维到全生命周期，Serverless架构要回答的问题很多，要做的事情更多。
　　作者：秋雨陈
　　原文链接： https://click.aliyun.com/m/1000352069/
　　本文为阿里云原创内容，未经允许不得转载。