失眠网,内容丰富有趣,生活中的好帮手!
失眠网 > 专访阿里云 Serverless 负责人:无服务器不会让后端失业

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

时间:2021-07-05 10:31:11

相关推荐

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

来源|阿里巴巴云原生

年,云基础设施服务提供商 Iron.io 的副总裁 Ken 谈到软件开发行业的未来,首次提出了 Serverless 的概念,为云中运行的应用程序描述了一种全新的系统体系架构。此后,以 AWS 为代表的云服务厂商将 Serverless 概念逐步落地,陆续推出了基于 Serverless 的 FaaS(函数即服务)产品。经过几年的发展,Serverless 架构已被业内认为是引领云原生下一个十年的发展潮流。

据 Gartner 报告, 年全球已有 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 的技术团队核心研发人员主要包括:

寒斜:阿里云智能云原生中间件前端负责人, 年加入阿里中间件从事云产品企业控制台研发工作,目前带队负责中间件 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。

以世纪联华为例, 年的 双11,函数计算 FC 帮助世纪联华顺利渡过了大促。 年 双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-/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 已经成为学术界的研究热点,从 年开始,每年相关论文数呈 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 地址:/serverless-devsGitee 地址:/organizations/serverless-devs/projectsServerless Devs 官网:https://www.serverless-

嘉宾简介

如果觉得《专访阿里云 Serverless 负责人:无服务器不会让后端失业》对你有帮助,请点赞、收藏,并留下你的观点哦!

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。