2022年9月24日，第十二届阿里云用户大会（AUG）活动在厦门举行。活动现场，阿里云资深技术专家石明伟（化名：石茹）与参会企业代表分享《未来已来——从技术升级到降本提效》。本文根据演讲内容整理。**_从技术升级到降本增效大家好，很高兴和大家分享今天的Serverless话题。在之前的讲解中看到今天有很多同学来到现场就是为了有这个机会了解Serverless。作为Serverless事件驱动生态、异步系统和Serverless工作流的研发负责人，希望通过今天的分享，能够帮助大家理解Serverless背后的技术原理，以及Serverless如何帮助企业实现技术升级、降本增效的目标。效率提升。同时，我也会分享一些最佳实践指导。当企业还处于从容器化到Serverless的过渡阶段，如何应用Serverless来升级技术，实现架构转型，达到降本增效的目的。最后分享一些Serverless在实际生产中应用的客户案例，帮助大家了解Serverless在实际生产过程中是如何使用的，解决业务痛点。企业技术升级的核心驱动力和痛点企业技术升级的核心驱动力首先，我们来了解一下企业生产过程中技术升级的三大核心驱动力：一是业务快速增长与IT能力不足的矛盾。来的动力。当一个新业务来的时候，由于业务的不可预测性，我们其实很难提前对业务进行预测和规划，在IT层面做好基础准备。企业需要在短时间内拥有配套的IT。支持业务快速增长的能力。二是提高研发效率。研发效率可以通过技术手段提升，目标也可以通过人员优化来实现。三是企业IT成本优化的需求。无论是处于较早的发展阶段，还是处于业务稳定增长阶段，为了生存或实现收支平衡，企业都会高度重视成本，在降低成本的需求驱动下，寻求技术升级实现这一目标。企业应用开发之痛《Serverless 的前世今生》这篇文章为大家打下了很好的基础，帮助大家理解为什么会出现Serverless？它要解决的核心问题是什么？回到企业发展追求的核心目标：更快地实现业务逻辑，减少环境搭建和系统对接的开发时间，把更多的时间放在业务发展上。开发完成后，需要一个运行环境来部署开发好的业务代码提供服务，以及运行过程中涉及到的相关维护工作，也就是我们通常所说的运维。我想所有研发和运维的同学都清楚每个人在整个过程中面临的痛点（也就是我们常说的DevOps）。总结起来就是企业研发效率的问题。除了研发效率，还有一个对企业来说非常重要的就是研发成本的问题。当然，这里我们只讨论企业研发中的IT成本问题。理想的模式当然是只为那些真正产生业务价值的计算付费，但通常情况下，真正产生业务价值的计算是与业务请求的生命周期一致的，在真正的业务请求到来之前，或者间歇期的请求，我们仍然需要为这些时间持有的计算资源付费，虽然这些时间计算资源对于业务是闲置的，这也是Serverless希望能够实现按请求付费来实现客户成本减量要求。为了帮助大家更好的理解pay-per-request，这里提供一个K8s或者ECS的收费模型。当你购买K8s时，你必须付费。当您创建Pod时，集群会为您分配资源。当你的请求流量不来时，你仍然需要为Pod资源付费。Serverless就是说今天你提供代码，部署到平台上，你的代码包，你的容器镜像已经部署到serverless平台上了，它实际上可能在预热或者运行，或者处于Standby状态，但是当你的请求实际上在前一个期间，或者两次请求调用之间的间隔期间，不会产生计算费用。企业业务系统研发之痛对于企业来说，我们通常所说的应用，不仅仅是简单意义上的程序，而是承载了整个企业业务能力的信息系统。当我们要搭建一个业务系统时，通常会经历几个阶段的系统架构选择，首先是技术架构的选择。很多企业的系统并不是从零开始搭建的，而是通过不断的业务积累逐步迭代演进的，但是当你面对新的业务系统，同时又要重构那些业务系统时，你应该如何选择呢？选择？什么样的架构，选择什么样的开源框架，不仅需要考虑架构的可扩展性，还需要考虑框架的后期维护、社区成熟度、技术获取门槛，以及后续业务发展的人才招募和其他因素。自建系统，尤其是在互联网环境下，分布式系统带来的运维负担和稳定性挑战会让研发团队不堪重负，技术集成难度更大，给企业自建分布式业务带来巨大挑战系统。分布式系统开发之痛一个典型的分布式系统的主要组件需要考虑负载均衡、流量控制、资源调度、系统可观察性、系统稳定性、高可用需求、服务治理等一系列问题。持续的研发投入和运维负担成为自主发展的主要痛点。Serverless函数计算助力技术升级，降低成本，提高效率。面对这一切的诉求和挑战，在讨论Serverless技术如何在产品层面满足和解决这些诉求和问题之前，我们不妨回顾一下Serverless的初衷？Serverless是云计算的前沿技术领域。“极致弹性、Serverless运维、按量付费”是它从一开始就想要实现的目标。从这个目标来看，Serverless从一开始就是从技术升级的角度来解决我们面临的成本和效率问题，也就是那句“路走对了，路不怕远”。函数计算的核心目标是“按量付费，无服务器运维，极致弹性”。这三个概念在客户的角度和技术术语之间找到了一个很好的平衡表达。企业技术升级的决策者可以直观地理解Serverless想要实现的价值。围绕这三个概念有两个核心目标要实现：效率提升目标和成本优化目标。按需支付更多是从业务角度出发，大家很容易理解就是根据请求进行按需支付。Serverless运维，从运维或者研发的角度来理解，就是不想在购买服务器上花费更多的时间；在运维方面，包括资源的弹性伸缩、健康检查等一系列运维工作，要承载这两个东西，我们必须要有基础的产品能力。最简单的是极端的灵活性，这意味着我在需要的时候使用它，不用的时候回收它。只有这样，我才能支持按量付费的逻辑。对于真正的业务价值请求计费，降低用户成本，通过弹性能力降低客户资源保留成本，其实做的越细，保留时间越短，越接近实际计算时间，从而降低成本。效率目标首先，开发方法必须简单。如果很复杂，研发人员就很难接受，也不会提高效率。另外，在简单开发的基础上，快速部署减少了研发人员参与发布扩容的时间，也就是所谓的成本效率目标。函数计算编程模式让【应用开发】更简单了解了Serverless的基本目标后，我们需要讨论一下Serverless函数计算如何实现这两个目标。首先，我们要从函数计算的编程模型来评估函数计算能够达到的目标。函数计算是一种事件驱动的全托管计算服务。使用函数计算，用户无需购买和管理服务器等基础设施，只需要编写和上传代码。函数计算为您准备计算资源，弹性可靠地运行任务，并提供日志查询、性能监控和告警功能。按照功能粒度开发独立的功能单元，快速调试，快速部署上线，节省大量资源采购和环境搭建运维工作；同时，函数计算是事件驱动的模型，这意味着用户无需关注服务产品的数据传递，省去了编写代码涉及的大量服务访问环节的逻辑；“事件驱动”+“函数粒度开发”+“无服务器运维”等多个维度特性助力函数计算支持更专注于业务逻辑开发的底层逻辑，实现真正的技术升级，提升研发效率。函数计算编程模型让【应用运行成本】更低除了开发模型带来的研发效率提升之外，我们再来看看函数计算是如何实现底层逻辑帮助客户降低成本的。按用户要求付费和用户流量模型是最理想的状态，但按用户要求付费存在巨大的技术挑战。要求函数计算实例的启动小于用户的RT要求，冷启动性能尤为重要。此时极致的Elasticity成为Serverless按量付费和业务降本的底层技术支撑。函数计算通过“极致弹性”+“按量付费”的模式，帮助Serverless函数计算实现真正的底层降本逻辑。函数计算产品开箱即用的原子化能力无论是对于云开发者还是试图升级业务的企业客户来说，serverless“按需付费、serverless运维、极致”的三大理念弹性”几乎深入人心。但是关于Serverless能做什么，怎么做，仍然是我们身边最普遍的声音。Serverless研发初期，技术团队通常更关注弹性和冷启动加速，希望通过弹性能力凸显产品的技术竞争力，确立产品在市场上的领先地位，并依托这些能力实现了无服务器的终极灵活性技术目标，以吸引开发人员和企业客户使用无服务器。现阶段，更多的是依靠技术影响力，引导大家去探索Serverless。随着我们对serverless的理解不断加深，弹性能力的提升进入深水区，相对来说，在没有本质变化的情况下，当客户需要在生产环境使用serverless时，我们会更多地考虑弹性之外的问题无服务器的其他值。届时，弹性覆盖的范围将不再局限于计算资源，还包括网络、存储等相关资源。弹性将作为系统的基本能力渗透到产品的方方面面。有必要从系统的角度考虑Serverless能做什么。能给客户带来什么，能给客户带来什么，如何让业务专注于那些必须定制的部分。在回答Serverless可以做什么以及如何做之前，让我们先了解一下Serverless是做什么的，以及它可以为我们提供哪些开箱即用的能力。函数计算——云产品的Serverless连接器作为一个计算平台，函数计算（FC）并不是一座孤岛。最大化函数计算的价值，满足企业客户基于函数计算构建业务系统的需求。联动的最大价值在于解决了云产品背后服务的连接问题。它也是无服务器函数计算事件驱动架构的基础。事件驱动的价值在于帮助用户使用更直观的理解隐藏背后的调用逻辑。这些调用不需要体现在用户的业务逻辑中。连接也意味着系统之间的依赖关系。这种依赖关系最终会通过耦合度体现出来。耦合并不表示功能依赖的强度。它更多的体现在软件架构的实现层面，是实现的结果，这是软件架构领域强调的“高内聚低耦合”的实现需求。事件驱动以事件驱动的方式满足了这种实现需求。基于这种架构，软件的内部实现不再像以往典型的单体应用或传统的微服务实现那样需要强依赖，将涉及到的多个服务依赖的客户端集成到自己的业务系统中。在基于云的开发环境中，云产品承载的服务是相对内聚的，它们各自在云原生架构的分布式系统中扮演着重要的角色。云产品之间的事件通知机制，可以帮助客户更好的实现多云产品。构建自己的云原生业务系统，否则云产品之间的watchevents开发起来非常复杂和昂贵。除了产品连接带来的开发效率之外，当用户订阅事件并提供处理逻辑时，客户已经潜在地过滤掉了不需要处理的事件请求。事件驱动意味着每个事件请求实际上都是一个有效的驱动程序。目前，函数计算通过与API网关、消息中间件MQ、对象存储OSS、表存储Tablestore、日志服务SLS、CDN、大数据Datahub、云调用等多种云产品的集成，构建了完整的事件生态。同时，还通过EventBridge接入阿里云全系列云产品的运维事件（日志审计、云监控、产品运维），帮助客户使用函数计算和众多云产品形成云-基于事件驱动架构的原生业务系统。.函数计算——高效消息生态事件驱动模型消息类产品以其异步解耦和削峰填谷的特点成为互联网分布式架构的重要组成部分。Serverless函数计算有与之完全匹配的应用场景。针对消息类产品，在架构层面专门做了生态整合和功能计算。基于EventBridge产品提供的EventStreaming通道能力，构建了一个通用的消息消费服务PollerService。基于该架构，为用户提供了RocketMQ、Kafka、RabbitMQ、MNS等多种消息。类型触发能力。消费逻辑面向服务，与业务逻辑分离由平台提供，消费逻辑与处理逻辑分离，将传统架构的消息拉取模型转变为Serverless事件驱动推送模型，可以支持函数计算承载的消息处理。实现无服务器消息处理的计算逻辑。基于此架构，可以帮助客户解决消息客户端的集成和连接问题，简化消息处理逻辑的实现，同时针对峰谷业务模型实现资源的动态扩展，降低用户成本。函数计算——开箱即用的异步任务处理能力下图展示了一个典型的异步任务处理系统的基本模型，它使用API??进行任务提交、任务调度、任务执行，最后交付执行结果。在传统的任务处理框架中，任务调度、负载均衡、流量控制策略的构建通常是基于服务网关。这也是分布式系统建设中最基础，也是最核心、最复杂、最耗费人力的重点建设。后端实现通常基于进程粒度的内存队列和运行时级别的线程池模型来完成具体的任务调度和执行。线程池通常与所选的编程语言Runtime密切相关，系统架构对于编程来说非常重要。开发语言具有很强的依赖性。Serverless异步任务处理系统的流程如下：用户通过API分发任务。请求到达无服务器服务网关后，存储在异步请求队列中。AsyncService会开始接管这些请求，然后请求调度获取后端资源。请求被分配给特定的后端资源以供执行。在这个架构图中，AsyncService负责实现传统架构中的请求分发器、负载均衡、流量控制策略和资源调度。这时候函数集群就相当于抽象的分布式线程池模型。函数计算模型下，实例交互隔离，资源具备水平扩展能力。借助函数计算的整体资源池能力，可以避免传统应用架构下单机资源受限带来的线程池容量问题和资源调度瓶颈问题。同时，任务的执行环境不会受到整体业务系统运行时间的限制，这也是Serverless异步任务系统相对于传统任务系统的优势。从Serverless任务处理系统的架构来看，其处理逻辑非常简单。分布式系统所依赖的大部分能力都是由AsyncService系统的角色透明实现的。对于用户来说，更多的是通过函数式编程。通过整体架构提供任务处理的实现逻辑，避免了对基于语言运行时的线程池的依赖。整个函数计算集群提供了一个容量“无限”的“线程池”。通过服务方式，用户只需要提交请求，其他的并发处理、流量控制、积压处理都由Serverless平台完成。当然，在实际执行过程中，还需要结合业务特点配置异步任务处理的并发度、错误重试策略和结果传递。函数计算——开箱即用的可观察能力函数提供了众多开箱即用的能力后，摆在客户面前最迫切的需求就是观察这些开箱即用的能力：面向客户开发和调试、业务逻辑优化、系统稳定性、计量计费等需求，如何揭示用户关心的一些指标和运行状态？我们需要为客户提供一个开箱即用的可观察性支持，尤其是在客户使用Serverless的初期过渡阶段，能够将系统黑盒部分的信息展示给客户是非常有必要的，从而提高产品计费的透明度。基于目前开箱即用的可观察性能力，可以一目了然地看到整个任务处理过程和消耗的计算资源。企业如何利用FC快速扩展业务系统？下面重点介绍在实际的业务系统中，企业如何利用函数计算提供的这些原子能力，快速扩展自己的业务系统，让Serverless真正成为企业实现业务系统扩展和架构升级的可靠依赖。.企业系统可以快速集成函数计算原子化能力。我们一开始就说，我们希望推动业务系统AllonServerless，让企业的整个业务系统都跑在Serverless上。但说实话，这个目标在现阶段还是很有挑战性的，我们还处于比较早的过渡阶段，希望能提供一些最佳实践建议，帮助企业利用serverless系统提供的原子化能力来实现目标在现有系统之上降本增效，将Serverless技术引入到自己的业务系统中，通过持续使用Serverless，实现Serverless能够带来的商业价值。如何快速将这些能力与现有系统集成？函数计算提供SDK、HTTPURL、各种事件驱动的访问方式，可以利用函数计算支持VPC能力，打通函数计算与客户现有系统的网络空间。同时，在业务支撑方面，功能提供多维度的Runtime能力，包括官方标准Runtime，支持自定义CustomerRuntime，以及与容器生态融合的CustomerContainer镜像部署方式，最大限度减少客户业务系统运行.无服务器平台之上的门槛。与容器生态相比，函数计算提供了非常显着的镜像预热加速能力，有助于快速启动客户的业务系统对外提供服务。StrippingTask/Job业务处理逻辑StrippingTask/Job业务处理逻辑：在一些微服务架构的业务系统中，利用serverless异步/异步任务能力来满足这些系统任务处理需求。函数计算提供HTTP、SDK、Timing、事件触发等集成方式，方便用户提交请求和执行相关任务。剥离MQ业务消息处理逻辑剥离MQ业务消息处理逻辑：企业的业务系统中通常会有很多业务子系统通过消息中间件链接起来。监听消息队列并主动拉取消息消费的逻辑被Serverless触发器所取代。消息处理的逻辑由函数计算来承担，通过事件驱动实现消息消费和消息处理的解耦，统一事件驱动提供的可靠消费能力。实现消息处理逻辑的serverless。剥离文件类处理业务逻辑剥离文件类处理业务逻辑：对于一些文件和视频处理业务，数据在文件系统和DB之间流动，使用函数计算提供的OSS触发器和DB触发器（OTS），快速完成相关数据以事件驱动的方式处理逻辑。剥离数据加工处理的业务逻辑剥离数据加工处理的业务逻辑：希望数据处理的一些业务逻辑可以利用消息产品提供的ServerlessETL能力进行处理，并通过使用快速实现根据业务需求进行函数计算Source和Target扩展。客户场景案例分析接下来分享一些实际用户serverless场景案例。算法任务下面是算法领域典型的业务场景架构：针对一些算法任务，高性能计算和一些AI相关的推理任务，广告图片的识别，以及一些智能运维的能力。通常这些部分是业务系统中相对独立的部分。使用函数计算，快速部署推理算法模型，将推理所需的图像或一组参数按请求提到函数。如果想在中间引入一层解耦逻辑，可以使用MQ，然后使用MQ事件触发任务执行。最终结果会提交给OSS，生成的文件可以进一步使用事件驱动进行处理。面向消费电子领域客户的Serverless解决方案，IOT相关视频传输，从IOT收集数据做进一步分析，最终支持客户端消费这些视频数据。下面以微博在互动娱乐行业的图片访问和处理的serverless场景为例。函数计算用于实现冷数据访问和个性化图像处理。教育行业以下是教育行业的Serverless解决方案。教育行业有一个明显的现象。编播、直播录制、直播内容审核等需求普遍存在。直播过程中需要通过剪帧的方式来回顾直播。内容的合法性。娱乐行业下面是娱乐行业，是针对视频内容动态切帧审核和切片转码的serverless解决方案。下图是南瓜电影的一个技术方案，它使用函数计算来实现这样的能力。游戏行业以下是函数计算在游戏行业的典型应用案例，涵盖了游戏行业的数据处理、战斗结算、游戏承包等场景。游戏行业的几个领先客户目前正在使用这种无服务器解决方案的组合来实现他们自己的业务系统。这些场景很有特点。以战斗结算为例，不需要在你的实例执行任务的过程中不断实时计算。通常只需要在实例即将结束时，或者在实例执行过程中执行即可。只有在作战时才需要计算，是典型的serverless应用场景。
