共计 6832 个字符，预计需要花费 18 分钟才能阅读完成。
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 生态的状况。
以下为采访原文：
请简要介绍一下阿里云 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 等云原生畛域倒退，致力于构建云原生畛域的开发者工具。
目前应用阿里云 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
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 则是一个框架层的产品，二者互为贴补，毫不抵触。
咱们看到 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 的形式构建简单的云原生利用。
Serverless Devs 开源了哪些局部？抉择开源的目标是什么？
< 江昱 >：Serverless Devs 开源了两个次要局部：命令行工具与利用核心。Serverless 其实是一个开发者驱动性很强的畛域，咱们将整个我的项目开源，将整个思路凋谢，其次要目标是想要站在开发者角度，去为开发者提供开发者所须要的工具，让开发者们本人定义和建设 Serverless 工具链，咱们也心愿通过这种模式，能够和更多的开发者有交加，接触到更多的 Serverless 爱好者，和大家一起 Serverless。
如果开发者在 Serverless Devs 上部署了本人的利用，之后还能够将该利用转移到其余平台上吗？比方转移到其余云服务平台或本地服务器，转移过程是否便捷？
< 不瞋 >：多云的利用迁徙波及到很多的因素，除了计算平台的迁徙，还包含数据迁徙，配置流程迁徙等。Serverless Devs 的设计哲学是帮忙开发者用对立的形式 build、deploy、release 容器或 Serverless 利用。无论用户应用何种语言（nodejs/python/golang/java），何种平台（K8s/ 阿里云 Serverless/Google cloud run 等），研发运维的体验是统一的，因而 Serverless Devs 可能简化利用迁徙到其余平台的难度。
有一种说法是“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 成为最具创新性的畛域。
Serverless 架构与一些风行的微服务架构是什么关系？Serverless 是否会取代微服务架构？
< 不瞋 >：Serverless 和微服务架构不是对抗的，而是不同维度的概念。微服务是一种架构模式，而 FaaS 为代表的 Serverless 计算平台则是实现微服务的一种形式。微服务能够用 FaaS 实现，也能够用 SpringCloud PaaS 平台，K8s + 容器，或者 VM 实现。
判断抉择用什么来实现微服务，要从可靠性、老本、性能、工程效率、安全性、零碎迁徙难度等维度登程，不同的场景有不同的取舍。当下在微服务场景下应用 Serverless 架构，最大的挑战在于和现有微服务框架兼容，可能平滑迁徙存量利用。为了解决这类问题，阿里云 Serverless 利用引擎应运而生，兼容 SpringCloud、Dubbo 等风行微服务框架，传统利用平滑迁徙，集成 ARMS 等阿里云服务，提供开箱即用的可观测能力，同时提供定时伸缩，按指标伸缩等弹性能力，让微服务场景也能享受 Serverless 的红利。
有网友放心 Serverless 等云服务的呈现会取代很多后端工程师的工作，当前中小型公司仿佛只须要雇佣前端业务开发者即可，这种认识是否精确? 是否给一些年老的后端开发者提供一些倒退的倡议。
< 不瞋 >：这种认识是全面的。对于任何一项技术，须要思考它的源起、趋势、优劣势，特地是要本人去实际，能力得出主观的判断。Serverless 并不是新技术，阿里云第一个云服务对象存储 OSS 就是 Serverless 的存储服务，应用 OSS 并没有压缩后端开发者的技术倒退空间。下图是要构建一个弹性高可用的后端系统须要思考的因素，只有蓝色虚线的框才是平台负责，其余大量内容依然须要后端开发者设计和实现：
Serverless 计算只是解决了基础设施治理等最根底、对用户最没有差异化的脏活累活。正如以后曾经简直没有开发者会基于汇编语言构建利用，Serverless 也是如此，冀望在 cloud programming 时代，为用户提供高级语言的编程体验。
原文链接
本文为阿里云原创内容，未经容许不得转载。
