专访阿里云 Serverless 负责人：无服务器不会让后端失业

Love The Way You Lie 2022-12-26 04:57 71阅读 0赞

**来源|**[**阿里巴巴云原生**][Link 1]

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 帮助世纪联华顺利渡过了大促][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 计算的极致弹性能很好的满足突发任务对算力的需求。

![1.jpg][]

*  **基于事件驱动架构的在线应用和离线数据处理**

典型的 Serverless 计算服务通过事件驱动的方式广泛的与云端各种类型服务集成，用户无需管理服务器等基础设施和编写集成多个服务的胶水代码，轻松构建松耦合、分布式的事件驱动架构的应用。

以阿里云函数计算为例，通过 API 网关和函数计算的集成，用户可以快速实现 API 后端服务。通过对象存储和函数计算的事件集成，函数能实时响应对象创建、删除等事件，实现以对象存储为中心的大规模数据处理。通过消息中间件和函数计算的事件集成，用户能快速实现海量消息的处理。通过和阿里云 EventBridge 的集成，无论是一方云服务，还是三方的 SaaS 服务，或者是用户自建的系统，所有的事件都可以快速便捷的被函数计算处理。

*  **运维自动化**

通过定时触发器，用户能够用函数快速实现定时任务，而无须管理执行任务的底层服务器。通过云监控触发器，用户可以接收 ECS 重启/宕机，OSS 对象存储流控等 IaaS 层服务的运维事件，并自动触发函数处理。  
**具体案例请参考**: [http://case-study.functioncompute.com/case-study.html][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 倍速增长。

![2.png][]

当前学术界/工业界在 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 并没有压缩后端开发者的技术发展空间。下图是要构建一个弹性高可用的后端系统需要考虑的因素，只有蓝色虚线的框才是平台负责，其他大量内容仍然需要后端开发者设计和实现：

![3.png][]

Serverless 计算只是解决了基础设施管理等最基础、对用户最没有差异化的脏活累活。正如当前已经几乎没有开发者会基于汇编语言构建应用，Serverless 也是如此，期望在 cloud programming 时代，为用户提供高级语言的编程体验。

Serverless Devs 开源项目：

*  **Github 地址**：[https://github.com/serverless-devs][https_github.com_serverless-devs]
 *  **Gitee 地址**：[https://gitee.com/organizations/serverless-devs/projects][https_gitee.com_organizations_serverless-devs_projects]
 *  **Serverless Devs 官网**：[https://www.serverless-devs.com][https_www.serverless-devs.com]

### **嘉宾简介** ###

![4.jpg][]

[Link 1]: https://mp.weixin.qq.com/s/PUUhhOBZeax8ZKtgQQLn9w
[Serverless Devs]: http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495273&idx=1&sn=3d1da60be1d24a80d3b231fdec83685f&chksm=fae6e5a6cd916cb0d3c2e5c63f3c105b467a092857d5705a2082afb4a7f4d0c9766bd8a1b39e&scene=21#wechat_redirect
[FC]: http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496385&idx=1&sn=3481cb8ca14068197154143006dd564c&chksm=fae6f90ecd9170180d21b15099a6a1b9fa5e030f21c062a0516a93b8ea8b531b27d4e3430b4d&scene=21#wechat_redirect
[1.jpg]: /images/20221120/ca8f2f9d65ca4d14b55bd76c53e72112.png
[http_case-study.functioncompute.com_case-study.html]: http://case-study.functioncompute.com/case-study.html
[Serverless Framework]: https://www.serverless.com/
[2.png]: /images/20221120/06bc498dcb9541429c7ca57a7c495c6b.png
[3.png]: https://img-blog.csdnimg.cn/img_convert/cc63ce146c69e2f9fccf057426179385.png
[https_github.com_serverless-devs]: https://github.com/serverless-devs
[https_gitee.com_organizations_serverless-devs_projects]: https://gitee.com/organizations/serverless-devs/projects
[https_www.serverless-devs.com]: https://www.serverless-devs.com
[4.jpg]: https://img-blog.csdnimg.cn/img_convert/b99153de471d5ba1de1682889e9b3c49.jpg