以下是视频内容精华整理，主要包括以下三部分：
一、云原生时代业务架构的变革：从单体迈向Serverless
二、Serverless在互联网行业的实践精析
三、案例：函数计算如何助力石墨文档效率&性能双提升
一、云原生时代业务架构的变革：从单体迈向Serverless
分享嘉宾：阿里云Serverless计算负责人杨皓然。
（一）产业趋势
如今，各个行业的企业都在进行数字化转型， 尤其是新零售、传媒、交通等行业。数字化的商业形态已经成为主流，逐渐替代了传统的商业形态。另外一些行业，如工业、制造业等，虽然没有直接进行数字化转型，但是也开始利用很多数字化技术，来进行生产力的优化。
企业的数字化转型，主要面临如下四个环节：
从云服务商的角度来看云的演进趋势：在Cloud 1.0时代，基础设施的云化是其主题，主要是云托管模式，云上云下的应用保持兼容，传统的应用可以直接迁移到云上，这种方式的核心价值在于资源的弹性和成本的低廉；当基础设施为我们提供了海量算力的时候，怎么帮助用户更好利用算力，加速企业创新的速度，就成为云的核心能力，如果仍在服务器上构建基础应用，那么研发成本依然很高，管理难度也很大，因此有了Cloud 2.0，也就是云原生时代，云服务商提供了丰富的托管服务，助力企业数字化转型和创新，用户可以像搭积木一样基于各种云服务来构建应用，大大降低了研发成本。云托管和云原生应用两者的差异具体如下图所示。
（二）云原生应用要素
云原生应用有三个非常关键的要素：
微服务架构
应用容器化和Serverless化
敏捷的软件交付流程
（1）微服务架构
单体架构和微服务架构各有各的特点，其主要特点对比如下图所示。总的来说单体架构上手快，但是维护难，微服务架构部署较难但是独立性和敏捷性更好，更适合云原生应用。
（2）应用容器化和Serverless化
容器是当前最流行的代码封装方式，借助k8s及其生态的能力，大大降低了整个基础设施的管理难度，而且容器在程序的支撑性方面提供非常出色的灵活性和可移植性，越来越多的用户开始使用容器来封装整个应用。Serverless计算是另外一种形态，做了大量的端对端整合和云服务的集成，大大提高了研发效率，但是对传统应用的兼容性没有容器那么灵活，但是也带来了很大的整洁性，用户只需要专注于业务逻辑的编码，聚焦于业务逻辑的创新即可。
（3）敏捷的应用交付流程
敏捷的应用交付流程是非常重要的一个要素，主要是要做到以下四点：
流程自动化
专注于功能开发
快速发现问题
快速发布上线
（三）Serverless计算
（1）阿里云函数计算
Serverless是一个新的概念，但是其内涵早就已经存在。我们可以了解到阿里云或者AWS的第一个云服务都是对象存储，对象储存实际上就是一个存储领域的Serverless服务；另外，Serverless指的是一个产品体系，而不是一个单个产品。当前业界云服务商推出的新功能或者新产品绝大多数都是Serverless形态的，比如阿里云的Serverless产品体系如下图所示，包括了计算、存储、API、分析和中间件等，可以看出，目前云的产品体系正在Serverless化。
阿里云的Serverless计算平台——函数计算有四个特点：
和云端无缝集成：通过事件驱动的方式将云端的各种服务与函数计算无缝集成，用户只需要关注函数的开发，事件的触发等等均由服务商来完成；
实时弹性伸缩：由系统自动完成函数计算的弹性伸缩，且速度非常快，用户可以将这种能力用在在线应用上；
次秒级计量：次秒级的计量方式提供了一种完全的按需计量方式，资源利用率能达到百分之百；
高可用：函数计算平台做了大量工作帮助用户构建高可用的应用。
那么，阿里云函数计算是如何做到以上四点呢？下图是阿里云函数计算产品的能力大图，从中我们可以看出，首先函数计算产品是建立在阿里巴巴的基础设施服务之上的产品，然后对在其之上的计算层进行了大量优化，接着在应用层开发了大量能力和工具，基于以上的产品能力，为用户提供了多种场景下完整的解决方案，才有了整个优秀的函数计算产品。函数计算是阿里云的一个非常基础的云产品，阿里云的其他许多产品和功能均是建立在函数计算的基础上。目前阿里云函数计算已经在全球19个区域提供服务。
（2）Serverless如何帮助用户简化云原生应用高可用设计、实施的复杂度
从下图我们可以看出，云原生应用的高可用是一个系统的工程，包括众多方面，完整的高可用体系构建需要很多的时间和精力，那么Serverless计算是如何帮助用户简化云原生应用高可用设计、实施的复杂度的呢？
下图是高可用建设更加细化的介绍图，从中我们可以看出，高可用体系建设要考虑的点包括基础设施层、运行时层、数据层以及应用层，且每一层都有大量的工作要做才可以实现高可用。函数计算主要是从容错、弹性、流控、监控四方面做了大量工作来实现高可用，下图中蓝色虚线框所对应的功能均有平台来实现，用户是不需要考虑的，蓝色实线框虽然平台做了一些工作来简化用户的工作难度，但是仍需要用户来进行关注，而橘红色的实线框代表需要用户去负责的部分功能。结合平台提供的功能和用户的部分精力投入，可以极大地减轻用户进行高可用体系建设的难度。
函数计算在多方面做了优化来帮助用户建设高可用体系。下图展示了函数计算在可用区容灾方面方面的能力，从图中可知函数计算做了相应的负载均衡，使得容灾能力大大提升。
下图展示的是函数计算对事件的异步处理，其处理流水线主要包括事件队列、事件分发、事件消费三个环节，在每一个环节上都可以进行水平伸缩，其中一个比较关键的点是事件的分发需要匹配下游的消费能力；另外可以通过为不同函数指定不同数量的计算资源，用户能方便的动态调整不同类型事件的消费速度；此外，还可以自定义错误重试逻辑，并且有背压反馈和流控，不会短时间产生大量请求时压垮下一个服务。
在函数计算的可观测性上面，提供了日志收集和查询功能，除了默认的简单日志查询功能外，我们还提供了高级日志查询，用户可以更方便地进行日志地分析；在指标收集和可视化方面，函数计算提供了丰富地指标收集能力，并且提供了如下图所示的标准指标视图、概览信息等视图，可以更方便用户进行运维工作。
下图是应用交付的一个示意图，从中我们可以看出整个流程包括了很多环节。在整个应用的交付过程中，只有每个环节都做好，才能够建设一个敏捷的应用交付流程，其核心是自动化，只有做到了自动化，才能提升整个流水线的效率和敏捷度。
下图展示了自动化应用交付流水线的每个环节具体的任务。其中需要注意的是要做到基础设施即代码，如此我们才能进行模板定义和自动化设置应用运行环境，进而实现自动化的持续集成等等。
做到了应用的自动化交付之后，对整个研发效率的帮助是非常高的。在Serverless应用上，我们提供了如下图所示的工具来帮助用户实现基础设施即代码。Serverless的模型有一个很好的能力，就是同一份模板可以传入不同的参数，进而生成不同环境的定义，然后通过自动化地管理这些环境。
对于应用本身不同服务版本的交付和灰度发布，函数计算提供了服务版本和服务别名来提供相应的服务，这样子整个应用的灰度发布流程就可以简化成一些API的操作，大大提升了业务的效率。如下图所示，通过Serverless计算平台提供的这些能力，整个软件应用的应用交付流水线自动化程度得到了大幅度的提高。
函数计算还有一个很有用的功能——对存量应用的兼容性。通过Custom runtime我们能够适配很多的流行框架，兼容传统应用，使其能够很容易的适配到Serverless平台上面，由控制台提供应用的创建、部署、关联资源管理、监控等一系列服务。
除了函数计算，我们还可以用Serverless工作流来对不同的应用环节、不同的函数进行编排，通过描述性的语言去定义工作流，由其可靠的执行每一个步骤，这样子就大幅度降低了用户对于复杂任务的编排难度。
（四）应用场景案例
函数计算有几个典型的应用场景，第一个就是Web/API后端服务，已经包括石墨文档、微博、世纪华联在内的多个成功应用案例。
函数计算的另外一个应用场景就是大规模的数据并行处理，比如往OSS上面上传大量的图片、音频、文本等数据，可以触发函数做自定义的处理，比如转码、截帧等等。这方面的成功案例包括虎扑、分众传媒、百家互联等等。
函数计算还有一个应用场景就是数据实时流式处理，比如说不同的设备产生的消息、日志发送到消息队列等管道类似的服务中，就可以触发函数来进行流式处理，如下图所示。
最后一个应用场景就是运维的自动化，通过定时触发、云监控事件触发，流程编排等方式调用函数完成运维任务，大大降低运维成本和难度，典型的成功案例有图森未来等。
Serverless计算在业界获得了越来越多的认可和应用，欢迎大家来关注和使用Serverless产品和技术。
二、Serverless在互联网行业的实践精析
分享嘉宾：阿里云互联网团队解决方案架构师丁建。
（一）Serverless简介
对于Serverless的定义，目前在业界并没有一个统一的答案。下图是目前两个相对来说比较权威的定义。一个是Mike Roberts在文章所提到的，一类是使用第三方的后端服务（BaaS），另一类是把代码运行在托管的短时运行的容器中（FaaS），BaaS和FaaS单独使用或者一起使用都可以认为是Serverless架构，目前通常说的Serverless指的是FaaS方向，本文介绍的Serverless无特别说明情况下指的也是FaaS方向。CNCF对Serverless的定义更加明确，指的是不需要服务管理的情况下构造和运行程序。
目前Serverless计算已经被认为是云计算的未来，甚至是整个软件开发的未来。下图是Serverless架构和传统的Serverful架构的对比，可以看出Serverless架构在云时代更有优势。
如下图所示，Serverless2012年首次提出，2016年引爆行业，目前进入了稳定发展的阶段。这段时间内，Serverless在业内广泛应用和发展，有了众多产品出现。
Serverless与K8S都有很强的编排调度能力，那么有什么区别呢？简单来说，针对多变的、不规则的负载，用Serverless比较合适，因为其有超强的、天然的弹性能力；K8S有比较成熟的应用部署的相关方案，比较适合对延迟要求比较低的业务，因为其响应延迟比较小，而Serverless存在冷启动带来的延迟问题。当然，这些并非一直不变的，产品也会随着需求的改变而调整自身特性。
Serverless和普通的PaaS对比如下图所示，当然，AWS云架构战略副总裁对两者差别的定义过于苛刻，目前还达不到其要求。简单做个比喻，Serverless就像水龙头，随时打开即用，不用时关闭即可；PaaS就像是饮水机，需要提前规划用水量。那么显然，在按需按量供应方面，Serverless会做得更好。
为什么我们要了解Serverless呢？相关报告显示，2019年已经有超过40%的相关企业落地了Serverless，且在剩下未采用Serverless的相关企业中有超过一半的企业计划在三年内落地Serverless计算技术。面对时代的高速发展，我们每个人都要去了解相关技术的发展，拥抱变化，以至于不被时代所抛弃。
（二）开源Serverless
下图是CNCF关于Serverless生态的全景图，包括平台层、框架层以及工具层，其中包括了众多大家熟悉的厂家，比如华为、AWS、阿里云等。
下图是当前Serverless开源框架的对比图，从图中来看目前热度最高的是OpenFaaS，其次是OpenWhisk，但是从稳定性等几个方面考虑，综合来说目前成熟度最高的是OpenWhisk。目前Serverless框架支持的公有云包括目前主流的各大云服务商，比如AWS、阿里云等等。
Serverless开源框架众多，公有云上也有很多的Serverless产品，那么到底应该如何选择呢？在OReilly的调研报告中显示大家之所以用Serverless的原因中排名前三的分别是：1）减少运营成本；2）根据请求自动伸缩；3）不需要操心服务器的维护。结合以上三点原因，当前我们推荐大家更多的使用公有云的产品，当然将来如果开源serverless的解决方案能和公有云的弹性结合起来，框架更加成熟之后，大家也可以尝试自建的方式。
（三）阿里云Serverless
前面提到过Serverless分为BaaS和FaaS两个方面，阿里云Serverless在BaaS方面提供了包括下图所示在内的众多场景和应用，对于BaaS方面来说，相当于是买服务，而不是买服务器。
如下图所示，在FaaS方面，阿里云提供了ECI、Kubenetes、应用、函数“四大金刚”能力，使得用户可以不再关心Server，只关注于业务开发。目前，阿里云在Serverless方向是各大公有云服务商中产品线最齐全、能力最强的厂家。
下图是ECI、SAE、ECS和函数计算几款产品使用成本的对比分析。从中可以看出，如果我们想要更精确的控制成本，做到成本最优，使用ECS就会比较困难，而其他三款产品有着更细的计费粒度，弹性更大，而且Serverless计算不需要做资源预留，能够更加有效的进行资源利用。
下图是阿里云几款Serverless产品在计费模式、启动速度、计费周期、售卖规格、特点以及适合场景方面的全面对比，大家可以依据自己的业务需求选择最适合自己的产品。
（四）实践案例
以下是几个Serverless产品的实践案例。
（1）某客户Presto on ECI方案
（2）某客户使用ASK应对突发流量弹性
以上两个案例分别是基于ECI和ASK的解决方案，但是底层都是基于ECI来解决的，ECI典型用户场景如下图所示。目前ECI可以基于ASK来实现常规资源和弹性资源的混度，或者实现纯弹性资源的拉起，而且也可以通过API的方式来编排到自己的业务系统，并且ECI是按秒级计费，成本方面也会比较低。
（3）某企业基于SAE一键启停开发测试环境
（4）基于SAE的高效弹性、低门槛微服务架构转型
上面是两个案例都是基于SAE来落地的，SAE实现了Serverless架构与微服务架构的完美结合，可以用在微服务应用、Web应用、多语言应用等场景，是面向应用的Serverless PaaS平台。SAE产品的核心优势如下图所示。
三、案例：函数计算如何助力石墨文档效率&性能双提升
分享嘉宾：石墨文档资深工程师万明。
石墨文档资深工程师万明从一个数字、两个好处、三个阶段三点介绍了函数计算如何助力石墨文档效率&性能双提升。
（一）一个数次
石墨文档当前有30多个函数，主要是用来处理一些CPU密集型的操作，比如修改文档表格和幻灯片、进行表格的公式计算等等。目前，石墨文档每月执行函数计算的次数达到了30亿次！
（二）两个好处
函数计算给石墨文档带来了两个明显的好处：效率提升和性能提升。
对于效率上的提升主要有以下四点：
简单：通过SDK调用函数计算即可；
省心：阿里云有专门的运维团队负责相关任务，无需考虑扩容、监控等问题，只需要专注于业务逻辑的开发；
省事：无需购买ECS、LB等组件，无需运维介入，甚至重启服务环节都可以省掉，大大缩短了上线周期和维护成本；
强大：可以用事件驱动的方式去触发和响应用户请求，有着多样的触发器，除此之外还有丰富的文档和示例供用户学习和参考。
性能上的提升主要是以下两点：
快：响应任务通常是毫秒级，并且本身可以做到毫秒级的伸缩，快速实现底层扩容来应对底层的压力；
稳定：响应平滑，波动比较小，高可用。
（三）三个阶段
伴随着业务的发展，石墨文档的技术也一直在更新。一开始，石墨文档使用的是Node.js，后来换成了Golang和Java，技术更新的每个阶段中，石墨文档对函数计算的使用姿势也在不断变化。
（1）Node.js 单线程时代
最初，石墨文档的后端是用Node.js实现的，因为石墨是多人协作平台，服务器每天要进行大量的文档改动，还有表格中的公式也需要实时进行计算，有大量CPU密集型操作，而且Node.js是单线程，所以我们想要使用分布式计算平台，但是单独搞分布式计算集群有点麻烦，使用函数计算比较符合，于是进行了小部分测试。经过一段时间的观察，发现函数计算无论是在稳定性还是性能方面都比较优秀。这个过程中有一个小插曲，就是我们发现函数计算有6M的体积限制，于是用OSS进行暂存和中转，如下图所示，过程中的延迟在可以接受范围内。
（2）Golang协程时代
随着业务的发展，石墨的调用次数越来越多，需要在成本和性能之间协调。同时，我们的微服务也在使用Golang开发，Golang的协程非常优秀，于是我们尝试在Golang的协程中处理文档改动，把原来函数计算处理的一些服务用Golang重写，使用Golang的协程，但是带来了负载不均衡的结果。最后，针对具体情况，决定小改动使用协程本地计算，大改动使用函数计算，在成本和性能之间取了最优。
（3）花样时代：另类玩法
随着对函数计算的了解，我们开发出了其他的用法， 比如每日数据邮件和报警机器人。
每日数据邮件是给产品经理和Boss发送每日数据邮件的服务，包含了日活、新增用户数等信息，使用了函数计算中的定时触发器来完成，每天中午十二点自动执行。该功能执行的时候大概包括调用内部接口获取数据、使用puppeteer来初始化实例并绘制图表、将图表转为图片、发送邮件。使用了函数计算之后，每日数据邮件不需要单独的脚本，大大降低了成本，且具有较高的稳定性。
报警机器人主要提供了两个函数，一个定时触发，一个被动触发。定时触发的函数每隔几分钟便会用日志服务的接口去获取最近几分钟内状态码异常的请求，然后发送到后端钉钉机器人（需要提供手机号）由机器人艾特相应的小伙伴，被艾特的小伙伴可以在消息中进行相关的设置，并且函数会修改自身的环境变量来实现持久化配置。整个报警机器人没有用到任何数据库，简单、持久且稳定。
关键词：Serverless、高可用、函数计算、云原生、SAE、ECI、ASK