作者 | 万佳 嘉宾 | 杨皓然（不瞋）
导读：云的下一波浪潮是什么？杨皓然称“是 Serverless”。作为一名阿里老兵，他早在 2010 年即加入阿里云，曾深度参与阿里云飞天分布式系统研发和产品迭代的全过程。如今，杨皓然是阿里云 Serverless 负责人。Serverless 有哪些典型的应用场景？ Serverless 在研发效能上可以发挥怎样的作用？ Serverless 在阿里内部有哪些实践？它的发展趋势是什么？带着这些问题，InfoQ 记者近日采访了阿里云 Serverless 负责人杨皓然。
Serverless 首次出现于 2012 年，中文即“无服务器架构”。它的出现将主机管理、操作系统管理、资源分配、扩容，甚至应用逻辑的全部组件都集成为服务，开发者可以更直接地将大部分后台能力作为一个能力接口来使用。将开发过程中的能力使用改为服务使用，通过构建或使用一个微服务或微功能来响应事件。
从理念空谈到实践落地，Serverless 开始走向繁荣。
根据 O'Reilly 2019 年 12 月发布的 Serverless 使用调研报告显示，已有 40% 的受访者所在的组织采用了 Serverless，并且使用 Serverless 技术的行业也十分广泛。尤其值得关注的是，有超过 50% 的受访者在一至三年内采用 Serverless，而 15% 的受访者在三年前就已经开始使用 Serverless 。
在杨皓然看来，“Serverless 的繁荣”是必然的：
首先，从用户需求角度看，在数字化转型时代，企业面临巨大的竞争压力和不确定性，“产品 time-to-market 的能力比任何时候都重要”。
其次，从技术发展的趋势看，云的产品体系及其生态正在迅速 Serverles 化。云服务商在存储、数据库、中间件、大数据、AI 等领域提供了大量全托管、Serverless 形态的云服务。同时，API 经济也驱使开发者提供了大量 Serverless 形态的 API 后端服务。
杨皓然说，“在这样的背景下，Serverless 计算应运而生，借助云的 Serverless 产品体系的能力，屏蔽基础设施的复杂度，帮助用户以搭积木的方式构建弹性、可靠、低成本的系统或应用。”
Serverless 的优势在于，它将同质化的、负担繁重的基于服务器等基础设施的开发和运维等工作从应用开发中移除，让用户聚焦于业务创新。相比传统的开发模式，Serverless 模式基于大量成熟的云服务能力构建应用，客户的决策点更少，实施复杂度更低。
因此，对企业而言，Serverless 架构有着巨大的应用潜力。杨皓然称，“随着云产品的完善，产品的集成和被集成能力的加强，软件交付流程自动化能力的提高，我们相信在 Serverless 架构下，企业的敏捷性有 10 倍提升的潜力。”
此外，Serverless 还能帮助用户大幅度提升资源利用率，降低成本，并实现更好的可靠性。
不过，他也坦然指出：
Serverless 最大的挑战在于工具链不够成熟，产品限制较多和适用场景不够广泛。但是，这些问题会随着产品能力的提升而不断改善。在垂直领域，比如前端全栈场景，已经出现针对 Serverless 架构优化的应用框架，进一步降低用户的使用门槛，提高研发效率。
在小程序 /Web/Mobile/API 场景中，业务逻辑复杂多变，迭代上线速度要求高，并且这类在线应用资源利用率通常小于 30%，尤其是小程序等长尾应用，资源利用率更是低于 10%。Serverless 计算的免运维、按需付费的特点非常适合构建小程序 /Web/Mobile/API 后端系统，通过预留计算资源 + 实时自动伸缩，开发者能够快速构建延时稳定、能承载高频访问的在线应用。
据杨皓然介绍，在阿里内部，使用 Serverless 构建后端服务是落地最多的场景，包括前端全栈领域的 Serverless For Frontends 、机器学习算法服务、小程序平台实现等等。
典型的离线任务批处理任务系统，例如大规模音视频文件转码服务，包含计算资源管理、任务优先级调度、任务编排、任务可靠执行、任务数据可视化等一系列功能。如果从机器或容器层次开始构建，用户通常使用消息队列进行任务信息的持久化和计算资源的分配，使用 K8s 等容器编排系统实现资源的伸缩和容错，自动搭建或集成监控报警系统。
如果任务涉及多个步骤，还需要整合工作流服务实现可靠步骤执行，而通过 Serverless 计算平台，用户只需要专注于实现任务处理逻辑。同时，Serverless 计算的极致弹性能很好地满足突发任务对算力的需求。
Serverless 计算服务通过事件驱动方式广泛的与云端各种类型服务集成，用户无需管理服务器等基础设施和编写集成多个服务的“胶水代码”，轻松构建松耦合、分布式的事件驱动架构的应用。
以阿里云函数计算为例，通过 API 网关和函数计算的集成，用户可以快速实现 API 后端服务。通过对象存储和函数计算的事件集成，函数能实时响应对象创建、删除等事件，实现以对象存储为中心的大规模数据处理。通过消息中间件和函数计算的事件集成，用户能快速实现海量消息的处理。通过和阿里云 EventBridge 的集成，无论是一方云服务，还是三方的 SaaS 服务，或者是用户自建的系统，所有的事件都可以快速便捷的被函数计算处理。
通过定时触发器，用户能够用函数快速实现定时任务，而无需管理执行任务的底层服务器。通过云监控触发器，用户可以接收 ECS 重启 / 宕机、OSS 对象存储流控等 IaaS 层服务的运维事件，并自动触发函数处理。
Serverless 为用户提供了一种新的应用构建方式。基于大量成熟云服务，用户可以像搭积木一样构建弹性高可用的应用。比如，借助对象存储和函数计算的集成，用户能快速实现大规模数据的并行处理，而无需从头构建和运维底层计算和存储平台，从而大大减少了研发人员的心智负担，提高效率。
此外，Serverless 计算很好地支撑了“基础设施即代码”的模式，提供了大量配套工具，让软件交付流水线的每个环节都高度自动化，帮助开发人员能够聚焦更具创新性的工作，提高研发效能。
据杨皓然介绍，阿里目前已经在前端全栈、大规模批处理任务执行、机器学习算法服务、运维自动化等领域广泛采用 Serverless 架构，成本和研发效能收益明显。
阿里提出 SFF （ Serverless For Frontends ）架构。SFF 可以利用 Serverless 的弹性扩缩容能力，减少研发对基础设施和运维的关注。对前端开发者而言，他们只需写几个函数即可实现后端业务逻辑，推动业务快速上线。
以淘宝为例，淘宝的内容导购频道使用 SFF 架构平稳支撑双十一大促。此前，导购业务面临的问题有两个：
一是导购业务更新迭代频繁，每次更新后都需要前后端同学的共同配合，这就带来很大的沟通成本；二是导购频道承载淘宝业务核心链路流量，每次大促前都要提前预留大量计算资源，带来很大的运维代价。
淘宝使用 SFF 架构后，频道的业务逻辑由函数承接，每个业务对应独立的入口函数，函数调用下层中间件获取数据，通过数据组装与裁剪计算业务数据，并返回给前端。Serverless 弹性免运维的特性让前端工程师有能力独立负责整条业务链路，全程不需要后端工程师参与，降低了前后端的联调成本，消除了运维代价。
据悉，淘宝在使用 SFF 架构后，项目人力节省 50%，研发效能提升 40%。
杨皓然称，“阿里巴巴经济体前端委员会也在积极探索针对 Serverless 优化的新框架、新工具，增强的 Nodejs 运行时等，推动更多业务场景落地。今年，Serverless 无疑将成为前端全栈领域的热点。”
除了前端全栈领域，阿里内部还大量使用 Serverless 架构实现负载有明显波峰波谷的计算密集型应用，包括音视频处理、基于 headless chrome 的前端自动化测试等，“每天的资源用量达到数万核小时规模”。
此外，阿里云数据库自治服务（ DAS ）要完成几十万数据库实例的指标分析和预测，对资源的弹性和可靠性有极高的要求。它使用函数计算运行在线和离线的机器学习算法应用，能够轻松应对流量洪峰。而开发人员专注于算法的设计、实现和调优，大幅提高产品的迭代速度。
针对 Serverless 的发展，杨皓然认为：Serverless 近年来一直在高速发展，呈现出越来越大的影响力。同时，主流的云服务商也在不断丰富云产品体系，提高更好的开发工具、更高效的应用交付流水线、更好的可观测性和更细腻的产品间集成。
在谈到 Serverless 的发展趋势，杨皓然提到了四个方面：
任何足够复杂的技术方案都将被实现为全托管、Serverless 化的后端服务。对于任何以 API 作为功能透出方式的平台型产品或组织，例如钉钉、微信、滴滴等，Serverless 都将是其平台战略中最重要的部分。
容器在应用的可移植性和交付流程敏捷性上实现了颠覆式创新，它是现代应用构建和交付的一次重要变革。当今，全世界的开发人员都习惯将容器作为应用交付和分发的方式。围绕容器，已经有了完整的应用交付工具链。未来，容器镜像也将成为函数计算等更多 Serverless 应用的分发方式，容器庞大的工具生态和 Serverless 免运维、极致弹性结合在一起，为用户带来全新的体验。
无论是用户自己的应用，还是合作伙伴的服务；无论是 on-premise 环境，还是公有云，所有的事件都能以 Serverless 的方式处理。云服务及其生态将更紧密的连接在一起，成为用户构建弹性高可用应用的基石。
Serverless 计算平台一方面要求最高的安全性和最小的资源开销，鱼与熊掌必须兼得；另一方面要保持对原有程序执行方式的兼容，比如支持任意二进制文件，这使得适用于特定语言 VM 的方案不可行。因此 AWS Firecracker，Google gVisor 这样新的轻量虚拟化技术应运而生。以 AWS Firecracker 为例，通过对设备模型的裁剪和 kernel 加载流程的优化，实现了百毫秒的启动速度和极小的内存开销。
实现最佳性能功耗比和性能价格比的另一个重要方向是支持异构硬件。长期以来，X86 处理器的性能越来越难以提升。而在 AI 等对算力要求极高的场景，GPU 、FPGA 、TPU （ Tensor Processing Units ） 等架构的处理器的计算效率更具优势。随着异构硬件虚拟化、资源池化、异构资源调度、应用框架支持的成熟，异构硬件的算力也能通过 Serverless 的方式释放，大幅降低用户使用门槛。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.