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