来源|阿里巴巴云原生
2012 年，云基础设施服务提供商 Iron.io 的副总裁 Ken 谈到软件开发行业的未来，首次提出了 Serverless 的概念，为云中运行的应用程序描述了一种全新的系统体系架构。此后，以 AWS 为代表的云服务厂商将 Serverless 概念逐步落地，陆续推出了基于 Serverless 的 FaaS（函数即服务）产品。经过几年的发展，Serverless 架构已被业内认为是引领云原生下一个十年的发展潮流。
据 Gartner 报告，2020 年全球已有 20% 的企业采用 Serverless 技术部署，Serverless 从底层进行技术变革计算资源的形态，为企业的软件架构设计和应用服务部署引入创新的技术设计思路。
尽管如此，国内的一些企业和开发者在面对 Serverless 时依然持观望态度。一方面是相关技术在国内起步较晚，部分开发者对新技术的接受度较低；另一方面，国内的 Serverless 生态建设较为落后，市面上相关的工具链并不完善，这导致开发和部署难度大、成本高。
近日，阿里云 Serverless 技术团队宣布开源 Serverless Devs 平台，为开发者提供了一套 Serverless 工具链体系。据介绍，通过该平台，开发者可以一键体验多云 Serverless 产品，快速部署 Serverless 项目。
为了进一步了解 Serverless Devs 项目的特性，以及 Serverless、微服务等云原生技术生态在国内的发展趋势，开源中国邀请到了阿里云 Serverless 研发负责人杨皓然(不瞋)，阿里云 Serverless 产品经理、Serverless Devs 项目发起人江昱，与我们分享了 Serverless 项目的细节与国内 Serverless 生态的情况。
以下为采访原文：
1. 请简要介绍一下阿里云 Serverless Devs 项目的技术团队成员构成。
<江昱>：团队是由阿里云智能云原生中间件前端负责人带队，联合阿里云智能云原生函数计算团队的多名技术专家，以及数名社区爱好者。通过开源思路，进行项目建设，耗时 120 天。
Serverless Devs 的技术团队核心研发人员主要包括：
- 寒斜：阿里云智能云原生中间件前端负责人， 2016 年加入阿里中间件从事云产品企业控制台研发工作，目前带队负责中间件 20 多款云产品的前端研发工作，主要技术栈为大前端通用技术包括 nodejs / typescript / react / electron / reactnative 等对前端研发效能提升，前端数字化体验管理体系建设有多年的实践经验，目前专注在 Serverless 开发者工具链的建设，是云原生 Serverless Dev Tools（S） 研发负责人之一，核心贡献了 S 启动器解析内核，S/core 核心包，主导了 S/gui 桌面工具研发工作。关注前端最新技术动态，关注云原生技术对前端群体的影响，致力于向前端群体推广普及云原生理念。
- 西流：阿里云智能云原生函数计算技术专家，负责阿里云函数计算产品功能开发：runtime 开发、事件源集成以及企业级 Sereverless 解决方案落地等，目前专注在 Serverless 开发者工具链的建设，是云原生 Serverless Dev Tools 研发负责人之一，主导了 S/fc 组件的开发工作。关注 Serverless 最新技术动态以及在企业级解决方案的落地，致力于推动 Serverless 在开发者群体的流行。
- 纳海：阿里云智能云原生 PaaS 产品高级研发工程师，参与企业级分布式应用服务 EDAS、应用配置管理 ACM 和 Web 应用托管服务等多款企业级微服务产品研发，同时为 Alibaba Cloud Toolkit 和 Serverless Dev Tools 创始人之一，持续关注微服务、PaaS 和 Serverless 等云原生领域发展，致力于构建云原生领域的开发者工具。
2. 目前使用阿里云 Serverless 平台服务的具体落地场景有哪些？
<不瞋>：Serverless 作为基础研发底座，被越来越多的企业所接受，并应用于业务实践中。除了互联网企业最早“尝鲜”之外，传统企业也在探索大规模使用 Serverless。
以世纪联华为例，2019 年的 双11，函数计算 FC 帮助世纪联华顺利渡过了大促。2020 年 双11，世纪联华全面迁移到函数计算 2.0，抗住了超过去年 230% 的业务峰值，并且研发效率交付提效超过 30%，弹性资源成本减少 40% 以上。如今，阿里整个经济体都在实践 Serverless，包括淘宝、天猫、支付宝、钉钉、飞猪、闲鱼、语雀等，并将 Serverless 的应用场景扩展到前端全栈、小程序、微服务、新零售、游戏互娱等领域。具体场景如下：
- 小程序 / Web / Mobile / API 后端服务
在小程序、Web/Moible 应用、API 服务等场景中，业务逻辑复杂多变，迭代上线速度要求高，而且这类在线应用，资源利用率通常小于 30%，尤其是小程序等长尾应用，资源利用率更是低于 10%。Serverless 计算的免运维，按需付费的特点非常适合构建小程序 / Web / Mobile / API 后端系统，通过预留计算资源+实时自动伸缩，开发者能够快速构建延时稳定、能承载高频访问的在线应用。在阿里内部，使用 Serverless 构建后端服务是落地最多的场景，包括前端全栈领域的 Serverless For Frontends，机器学习算法服务，小程序平台实现等等。
- 大规模批处理任务处理
典型的离线任务批处理系统，例如大规模音视频文件转码服务，包含计算资源管理、任务优先级调度、任务编排、任务可靠执行、任务数据可视化等一系列功能。如果从机器或者容器层次开始构建，用户通常使用消息队列进行任务信息的持久化和计算资源的分配，使用 K8s 等容器编排系统实现资源的伸缩和容错，自行搭建或集成监控报警系统。如果任务涉及多个步骤，还需要整合工作流服务实现可靠步骤执行，而通过 Serverless 计算平台，用户只需要专注于实现任务处理逻辑，而且 Serverless 计算的极致弹性能很好的满足突发任务对算力的需求。
- 基于事件驱动架构的在线应用和离线数据处理
典型的 Serverless 计算服务通过事件驱动的方式广泛的与云端各种类型服务集成，用户无需管理服务器等基础设施和编写集成多个服务的胶水代码，轻松构建松耦合、分布式的事件驱动架构的应用。
以阿里云函数计算为例，通过 API 网关和函数计算的集成，用户可以快速实现 API 后端服务。通过对象存储和函数计算的事件集成，函数能实时响应对象创建、删除等事件，实现以对象存储为中心的大规模数据处理。通过消息中间件和函数计算的事件集成，用户能快速实现海量消息的处理。通过和阿里云 EventBridge 的集成，无论是一方云服务，还是三方的 SaaS 服务，或者是用户自建的系统，所有的事件都可以快速便捷的被函数计算处理。
- 运维自动化
通过定时触发器，用户能够用函数快速实现定时任务，而无须管理执行任务的底层服务器。通过云监控触发器，用户可以接收 ECS 重启/宕机，OSS 对象存储流控等 IaaS 层服务的运维事件，并自动触发函数处理。
具体案例请参考: http://case-study.functioncompute.com/case-study.html
3. Serverless Dev 项目诞生的契机和愿景是什么？Serverless Dev 与阿里云此前开源的另一个 Serverless 项目 Midway 是否有联系？
<不瞋>：首先我们在服务集团内外的用户时看到，工具链是 Serverless 被用户接受的最大障碍。这主要体现在以下几方面：
- 在开发和运维 Serverless 应用时，体验和已有工具或流程是割裂的。对于复杂业务场景的用户，他们的不同负载通常运行在虚拟机，容器或者 Serverless 等多个平台上，用户更希望使用同一套工具和流程，去构建、部署和监控基于虚拟机，容器或者 Serverless 的应用。
- 用户希望工具链能覆盖开发、测试、构建、部署、分布、监控等环节，提供闭环的研发运维体验，而不再需要跳出到各个产品的控制台，或者要使用多种工具来完成。
- 用户希望同一套工具链，能够管理阿里云，腾讯云等不同公有云 Serverless 平台，或者 on-premise 环境的应用。上述问题，导致很多场景下 Serverless 并未大幅提升研发效率。
其次从云原生发展的趋势来看，开发者在构建云原生应用时，要解决的问题的范围和复杂度在不断增加。比如在构建应用时，开发者仍然需要花大量精力来处理和业务逻辑无关的细节问题，包括资源的创建和删除，权限管理等等；对于企业级客户，除了资源管控外，还需要做到安全合规，比如怎么保证敏感数据没有被错误的赋予外部访问权限，VM 没有被禁止访问公网等等。我们相信在工具层面，将有巨大的创新空间。
因此从实际用户需求和未来趋势两个方面出发，我们希望为开发者打造一条工具链，能帮助用户完整的解决应用开发和运维环节的问题，将 dev 和 ops 真正串联起来，提升研发效率。我们希望这个工具做到良好的 “complexity scalability”，当问题简单时，能够快速上手；当问题变得复杂时，同一套工具和流程仍然能胜任。
<江昱>：虽然说 Serverless 已经发展很久了，也不是什么新鲜的概念了，但是 Serverless 的工具链还蛮匮乏的。我们不仅意识到了这个问题，也和很多用户进行过深度沟通，对用户在使用 Serverless 的时候遇到的问题也是非常关注，最终我们决定要做一个“站在开发者角度的 Serverless 工具链体系”，其目的是可以让开发者像使用手机一样使用 Serverless，可以给大家更简单、方便、快捷的上手体验、实践操作，并且可以在 Serverless 项目的全生命周期发挥作用。至于和 Midway 的联系，我觉得是非常紧密的，因为 Serverless Devs 更多是一个工具层的产品，而 Midway 则是一个框架层的产品，二者互为补助，毫不冲突。
4. 我们看到 Serverless Devs 的定位是 “首个支持主流 Serverless 服务/框架的云原生全生命周期管理”的平台，它的首创性体现在哪些方面？与业内已有的 Serverless 服务平台相比有何优势？
<不瞋>：对比 Serverless Framework 等流行的工具，Serverless Devs 有几个明显的差别：
- Serverless Devs 致力于解决 build、deploy、release、monitoring/trouble shooting 等应用开发和运维的全流程问题，为用户提供端对端的开发运维闭环体验，提升研发效率。其他工具主要是解决单个环节的问题。
- Serverless 应用不只是依赖计算类产品，还依赖存储、中间件等各种云产品，需要工具能够管理丰富的云产品。Serverless Devs 未来将支持阿里云、腾讯云、AWS、Azure 和 Google 等所有主流云厂商的云产品，以及 K8s 生态的应用。和 Serverless Framework 等工具相比，在资源管理的深度和广度上更有优势。
- Serverless Devs 开源、开放，通过基于高级语言抽象能力的组件机制，开发者能够以 simple、higher level、composable 的方式构建复杂的云原生应用。
5. Serverless Devs 开源了哪些部分？选择开源的目的是什么？
<江昱>：Serverless Devs 开源了两个主要部分：命令行工具与应用中心。Serverless 其实是一个开发者驱动性很强的领域，我们将整个项目开源，将整个思路开放，其主要目的是想要站在开发者角度，去为开发者提供开发者所需要的工具，让开发者们自己定义和建设 Serverless 工具链，我们也希望通过这种形式，可以和更多的开发者有交集，接触到更多的 Serverless 爱好者，和大家一起 Serverless。
6. 如果开发者在 Serverless Devs 上部署了自己的应用，之后还可以将该应用转移到其他平台上吗？比如转移到其他云服务平台或本地服务器，转移过程是否便捷？
<不瞋>：多云的应用迁移涉及到很多的因素，除了计算平台的迁移，还包括数据迁移，配置流程迁移等。Serverless Devs 的设计哲学是帮助开发者用统一的方式 build、deploy、release 容器或 Serverless 应用。无论用户使用何种语言（nodejs/python/golang/java），何种平台（ K8s/阿里云 Serverless/Google cloud run 等），研发运维的体验是一致的，因此 Serverless Devs 能够简化应用迁移到其他平台的难度。
7. 有一种说法是 “Serverless 会阻碍开源服务的创新”，因为目前很多流行的开源软件还不能大规模地部署在 Faas 平台上，毕竟目前主要的开源软件并不是针对 Serverless 执行环境的，特别是数据系统。未来的趋势是创造更多 Serverless 原生开源软件，还是把一些已有的主要开源软件迁移到 Serverless 架构呢？
<不瞋>："Serverless 会阻碍开源服务的创新" 这个观点来自于 UC Berkeley 的论文 《Serverless Computing: One Step Forward, Two Steps Back》，论文中的谈及的 Serverless 对开源服务创新的阻碍是指当下 Serverless 的局限性。半年后他们发表了另一篇论文：《Cloud Programming Simplified: A Berkeley View on Serverless Computing》，预言 Serverless 面临的挑战是可以解决的，会成为云计算的默认范式。当前 Serverless 已经成为学术界的研究热点，从 2017 年开始，每年相关论文数呈 2 倍速增长。
当前学术界/工业界在 Serverless 方面主要研究趋势：
- 将流行的应用框架 Serverless 化，比如 Serverless 机器学习框架。
- 拓展 Serverless 编程模型，例如 Stateful FaaS，使得 Serverless 计算能够支撑更多应用场景。
- 在云的每个层面重构，适应高度动态资源使用的 Serverless 应用。在数据中心层面，通过超快的网络架构实现计算和存储分离，将 CPU、GPU、FPGA、disk，甚至内存进行池化，从而获得更好的弹性和资源利用率；在 Serverless 计算平台层面，设计为 Serverless 模式高度优化的存储服务，高 iops、低延时、低成本，使得分布式系统能够使用 Serverless 的模式构建。
- 性能优化，例如 GPU，FPGA 等异构硬件支持，软硬协同优化等等。可以看到这些趋势将推动 Serverless 成为最具创新性的领域。
8. Serverless 架构与一些流行的微服务架构是什么关系？Serverless 是否会取代微服务架构？
<不瞋>：Serverless 和微服务架构不是对立的，而是不同维度的概念。微服务是一种架构模式，而 FaaS 为代表的 Serverless 计算平台则是实现微服务的一种方式。微服务可以用 FaaS 实现，也可以用 SpringCloud PaaS 平台， K8s + 容器，或者 VM 实现。
判断选择用什么来实现微服务，要从可靠性、成本、性能、工程效率、安全性、系统迁移难度等维度出发，不同的场景有不同的取舍。当下在微服务场景下使用 Serverless 架构，最大的挑战在于和现有微服务框架兼容，能够平滑迁移存量应用。为了解决这类问题，阿里云 Serverless 应用引擎应运而生，兼容 SpringCloud、Dubbo 等流行微服务框架，传统应用平滑迁移，集成 ARMS 等阿里云服务，提供开箱即用的可观测能力，同时提供定时伸缩，按指标伸缩等弹性能力，让微服务场景也能享受 Serverless 的红利。
9. 有网友担心 Serverless 等云服务的出现会取代很多后端工程师的工作，以后中小型公司似乎只需要雇佣前端业务开发者即可，这种看法是否准确? 能否给一些年轻的后端开发者提供一些发展的建议。
<不瞋>：这种看法是片面的。对于任何一项技术，需要思考它的源起、趋势、优劣势，特别是要自己去实践，才能得出客观的判断。Serverless 并不是新技术，阿里云第一个云服务对象存储 OSS 就是 Serverless 的存储服务，使用 OSS 并没有压缩后端开发者的技术发展空间。下图是要构建一个弹性高可用的后端系统需要考虑的因素，只有蓝色虚线的框才是平台负责，其他大量内容仍然需要后端开发者设计和实现：
Serverless 计算只是解决了基础设施管理等最基础、对用户最没有差异化的脏活累活。正如当前已经几乎没有开发者会基于汇编语言构建应用，Serverless 也是如此，期望在 cloud programming 时代，为用户提供高级语言的编程体验。
Serverless Devs 开源项目：
- Github 地址：https://github.com/serverless-devs
- Gitee 地址：https://gitee.com/organizations/serverless-devs/projects
- Serverless Devs 官网：https://www.serverless-devs.com
嘉宾简介
