当突发事件来临时，当绝佳idea闪现时，如何快速搞定开发和部署，使之变身为产品？快，则应万变！Serverless 是当今炙手可热的技术，被认为是云计算发展的未来方向，如何利用Serverless Framework 实现快速上云？本文是王俊杰老师在「云加社区沙龙online」的分享整理，详细阐述了Serverless上云的基本思路、框架原理、组件架构等，带大家揭开Serverless的神秘面纱。

点击此链接，查看完整直播回放~

一、Serverless上云基本概念

感谢云加社区组织这次“技术应变力”的线上专题活动，并邀请我来进行分享，我将从Serverless的角度来进行解读。Serverless是最近非常热门的词，中文翻译为“无服务器”。有人认为既然是无服务器，就意味着不再需要运维，完全是按需付费的模式...... 其实这些理解都比较片面，描述的都只是Serverless的某个方面。

从2014~2020年，这几年Serverless关键词的谷歌搜索指数与日攀升，现在已经成为了非常火爆的技术名词。其实早在2006年就有人提出Pay as you go的概念，需要多少就买多少，但直到2012年，Serverless首次被提出。2014~2016年，大型云厂商纷纷发布函数计算相关的产品支撑这样一个无服务器技术。

腾讯也加入进来，2017年推出SCF云函数的FaaS平台，并基于此FaaS平台，在2018年发布了微信小程序云开发的Serverless产品，在2019年腾讯云重磅推出——Serverless Framework。

1. 算力、算法、数据

那到底什么是Serverless呢？谈到 Serverless ，很多人都自然而然想到FaaS+BaaS，那FaaS又是什么？当我们回答这个问题的时候，我们先回顾几个计算机领域内的基础概念。

在计算机应用技术发展过程当中主要三个影响因素是：算力、算法、数据 。比如 AlphaGo战胜了人类，就是算力、算法、数据三个因素上都有了提升的表现。算法是从目标到求解的过程，往往是一个数学模型或者计算方法。

而说到 云计算，主要解决的还是算力问题，算力的发展主要是两个方面：

第一是让计算的能力更强，让CPU或者GPU运行更快。从CPU的天梯图可以看到历代CPU都在不断的刷新着计算速度的极限。

第二是算力的另一个发展的方向，如何更加合理的分配算力。传统计算机，从单任务实时操作系统到多任务分时操作系统，是解决算力的分配问题，云计算诞生的初衷和解决的问题，依然是算力分配的问题。建立一个Cloud，一个超级规模的计算机集群，按需提供给不同的客户使用，更加合理的分配计算资源。

最早的时候没有云计算的“裸金属”时代，需要大家自己建机房，是非常非常麻烦的事情，不要觉得准备一间房子，买一些机器安装就可以了。包括水、电、消防这些东西都是需要考虑进来的。

云计算提供了虚拟化的解决方案，在IaaS时代需要投入的成本就低了一些，可以直接购买和运维虚拟机。然后是PaaS时代，可以不关注机器直接使用平台服务，现在已经到了FaaS时代。随着云计算的发展，需要投入的人力和资金成本开始变得越来越少了，根本原因就是云厂商已经帮客户搞定了越来越多东西。

2. Serverless 与 FaaS

刚才讲到了云计算让算力的分配的更加合理，更加合理的表现之一，就是算力的分配颗粒度，越来越小。

IaaS时代，计算资源分配的粒度还是虚拟机，解决裸金属和虚拟化的问题，在这之上的操作系统、应用平台都需要自己搭建和运维。到了PaaS时代，减少了对于操作系统和应用平台/环境的关注，用户只需要关注应用层实现，因此分配资源的粒度变成了应用。

到了Serverless 和 FaaS 的时代，计算资源分配的粒度进一步变小，是以一个个函数Funcition（业务逻辑执行）为粒度进行分配的。

说到头来， FaaS 就是一个以业务代码的执行为粒度的“算力”的分配粒度 。它不是以代码为粒度，不是以虚拟机为粒度，也不是以容器为粒度，而是以函数为粒度。

那么 Serverless 和 FaaS 又有什么关系呢？这里引用伯克利的学术观点：Serverless computing 就是FaaS+BaaS。

这不是一个定义，但是却是实现Serverless一个具体方法。Serverless真正的含义又是什么呢？在这篇论文最核心的摘要部分，对Serverless的概念做了一个说明。翻译成中文就是： 无服务器云计算，它几乎封装了所有底层资源管理和系统运维工作，使开发者更容易使用云基础设施 。

它提供了一个方式，极大简化了基于云服务的编程，犹如汇编语言到高级语言编的转换。

这一句比喻是点睛之笔。大家都知道学计算机技术绕不开汇编语言，你需要内存结构是什么样子，操作文件和内存都需要接触内存地址这些概念。对于高级语言说白了，不需要你关注计算机的底层到底是什么，只需关注自身的业务，比如它们会把你的业务抽象成不同的模块，抽象成一个个对象和类......

把这一套搬到云计算层面上来，Serverless同样也不需要你去了解云的底层是怎么一回事，只要把精力完全专注于你的业务就可以了，这就是Serverless的内涵，它的本质是对底层资源的封装和操作。

3. 原型到产品的衍变步骤

什么是专注于业务逻辑？这里举个例子说明，当你有一个很好的 idea 想做产品的时候，实际上是有一个鸿沟的。

从一个idea或是一个原型，怎么才能做到是一个真正的产品呢？一般我们认为 原型到产品，中间有三步要走：

第一步是业务逻辑 ，包括业务流程、界面、交互、数据存储等。主要就是做各种功能和流程，但是把这些功能做完了，就得到了一个原型，还不能称之为产品。

第二步是产品化 。速度快不快？性能是不是可用？可靠性怎么样？会不会经常卡死？可扩展性怎么样？是否支持水平扩容？这里面还有很多需要考虑的技术维度。

第三步：产品上线的运维 。资源的负载情况如何？错误率有没有监控？系统的日志如何切分和流转？有突发情况需要扩容时怎么办？针对业务的运营工作也是必须的。

第一部分是大部分工程师每天在做的事情，业务功能、流程逻辑，展现、交互、数据，利用现有各种各样的前端的、后端的框架，加上工程师的创造力，能把这块支撑的很好。

第二部分主要是架构工作。业务功能背后的架构相对就要复杂很多，很多系统性问题都需要在架构的层面考虑和解决。比如说服务业务架构是否足够健壮？模块间的依赖是否合理？是不是可方便调试的？日志和异常是否统一处理，出错了如何快速定位问题？代码和模块是不是可以复用？新人来了以后能不能快速接手？系统的性能、安全性、扩展性、可理解性、可靠性都是需要在架构层面上解决。

第三部分运维工作同样也是一项复杂的工作。就拿扩容来说就是一件麻烦的事情，扩容最大的难题是是不知道什么时候该扩容，除非能准确的对未来的容量进行估计，才会从容很多。

但是一个产品的用户增长曲线，往往是难以准确估算的，尤其是你的idea特别好，在短时间内迅速火起来的时候。比如2019年出现了某款非常火爆的应用，能够给视频实现AI换脸的功能。一经上线迅速在大江南北实现全网火爆 —— 但当天晚上就打不开了，因为容量的问题。另外，在互联网+的大背景下，现在很多传统行业应用都想要上云。

上云这两个字说起来简单，但是实际上云会涉及到云计算方面各个层面的技术储配，一些新的开发、部署和运维方式。整个上云过程中需要很多的知识和经验，时间成本也不小。根据上面的分析，我们知道从一个idea到线上产品，这条路其实很长。

4. 从Demo到产品的全栈技术层次

另一个方面，不管是前端开发，还是后端开发，都想做全栈开发的工程师。

最早的时候只有Web工程师的角色，后来到了Web2.0时代，越来越多的很多展现和交互工作前移到前端来做，后端更多的负责数据处理和业务流程，分工也随之出现。

但带来的问题就是分工和协作的开销，因此大家都希望能有一类工程师可以把整个活儿都干了。这就是全栈工程师，但是这条路，走的却没有想象中的那样顺畅。原因就在于对全栈full-stack的理解，网上对于全栈的解读大多如下图所示：能搞定前端，能搞定后端，能搞定解数据库，就可以成为一名全栈开发工程师了，但事实真的如此吗？实际一个全栈工程师远远不是这样！

这个理解是建立在业务功能实现层面的，好像有了前端+后端+数据库，基本业务就能做出来了。而实际上真实情况往往与之相差甚远！

真正能够支撑业务的full-stack架构，至少分为四层：

第一层，是核心业务逻辑，业务流程、前端展现、后端功能、API、数据等。

第二层，是业务架构，具体包括应用框架、技术架构、数据库等。

第三层：是业务运维包括日志、监控告警、扩展性、负载均衡等。

第四层：是底层架构，包括计算资源、系统及网络安全、灾备等。

越往上层，对业务价值的驱动力更高，因为聚焦业务逻辑；而越往底层，往往技术难度越大，对于人员的技术能力要求越高。继续分析，我们就可以的发现：

• 第一层：全栈工程师们想做的东西
• 第二层到第四层：Serverless可以解决的问题

在Serverless的赋能下，工程师依旧只需要关注核心的业务逻辑，而底层的技术架构、计算资源、稳定性、系统运维工作，则可以完全由Serverless进行支撑。

5. Serverless的内涵与优势

在Serverless的架构下，只要关注业务核心的逻辑。业务逻辑原来该怎么做现在还怎么做，原来用的语言框架、数据库等在 Serverless 下仍可继续使用。对于核心业务逻辑的下层建筑，包括计算资源和存储资源的分配和管理问题，Serverless 帮你打包解决了。

除此之外，Serverless在计费方面是有优势的。Serverless遵循按需使用的计费模式，用多少就会计费多少，不会有闲置的资源浪费。

下图所示的是Serverless的计费模型，左边图中的黄色区域是用虚拟机支付产生的费用，是一个矩形，绿色曲线围成的阴影部分则是 Serverless的费用，两个图形相减就是费用相差的部分。

值得一提的是，腾讯云发布了国内甚至全球首发的1毫秒计费粒度的Serverless服务，1毫秒计费粒度意味着什么呢？

这里可以举一个例子：假设我们购买了100元的手机流量套餐，获得100G的手机流量，看似是1元对应1G的流量。但其实不是这样的，因为实际上你使用了1G也要收费100元，而1毫秒计费就是每1G只要1块钱。Serverless服务计费也是这样，如果按行业通用100毫秒计费，而你的程序只运行了几毫秒，也需要按照100毫秒计费。腾讯云Serverless按1毫秒计费，基本上实现了真正的程序用了多少，就产生多少费用。

在实际计算中，Web服务下，每一个请求处理时间很短，远远到不了100毫秒，所以用WebService为例， 使用腾讯云Serverless服务大概可以节省70%的费用！ 另外， 现在腾讯云 Serverless 有很大的免费试用名额放出，现在的免费试用额度足够每天3万PV的站点所需要资源的开销。

二、Serverless与技术应变力

今天分享的主题是“技术应变力”，对于工程师、架构师、CTO他们到底意味着什么？

对于工程师来讲，技术应变力就是职业发展。从这个角度上讲，“技术应变力” 可以理解为“技术迁移能力”。原来做了A，是不是只能做A？你的技术能力是否能从A迁移到B、C、D？Serverless 是当下最时髦的新技术之一，很多工程师都在快速补足 Serverless 方面的技术栈。如果把Serverless技术栈写在简历上，当前的时间点一定会让面试官认为你是一个非常喜欢新技术的工程师。

对于架构师和技术leader来讲，“技术应变力”意味着什么呢？设想，如果老板问一个技术leader，你的团队有没有技术应变力，这是什么意思？“技术应变力” 对技术leader来讲，指的就是团队工作能力的应变性。原来做产品A，现在要求做产品B，你能不能用现在的团队，用现在的技术架构，把产品B很快的做出来？Serverless 很大程度上帮助技术团队提升这一种能力。Serverless帮助技术团队解决底层所有资源分配。技术团队不需要再管这些，只要把精力放在核心业务逻辑上，在提高了生产效率的共识，增加了应变性。

如果对公司老板或者CTO来说，“技术应变力” 又意味者什么呢？在这一层次考虑的话结论又不相同，对于老板或者CTO来说，“技术应变力” 往往意味着更优的技术投入成本结构。

Serverless在成本控制方面，除了前文提到的按需付费节省算力资源成本，更重要的是它能改变公司的技术投入的成本结构。而这种更优的技术投入成本结构，可以一定程度上降低公司在技术方面过度的投资，以公司快速的应对市场变化时，可以最小的沉默成本完成业务转型或者变革应对。

说的再明白一点，从会计的角度，Serverless 让公司对于技术投入的成本，一定程度上从固定成本变成了可变成本。

怎么理解可变成本呢？举个例子：如果市场部做一个产品广告，假设买了一个电视广告或者地铁广告，一年花费XXXX万，这个成本就是固定成本。我们无法将广告的效果和获客做一个完全的对应，即使一个客户没有带来，或者带来了很多个客户，投放广告的费用是固定不变的。而按效果付费（CPA）广告，就是一种可变成本，可以把广告费用分摊到每一次的销售环节中，理解为获得一个客户，支付一次广告费用。这就是销售环节涉及到的可变成本，公司的技术投入的可变成本结构也同样如此。

如果技术投资可以做到按照业务的执行次数付费，那这块成本的大小就会随着业务规模的变化而变化，非常可控。技术投入的成本结构对于公司技术升级和转型时的决策也有很大影响。如果公司前期的技术投入采用了某种因素被绑定的技术选型，例如自建机房、用物理机的方案。在公司进行技术架构升级的时候就有因为沉默成本而阻力重重。因此，公司在思考技术投入的成本结构方面，也应着重考虑 “技术应变力”因素。

三、Serverless框架原理

1. 为什么需要这样的框架？

Serverless本质是帮客户隐藏底层各种资源和管理的工作，让你聚焦业务逻辑上，但是具体的实现还是FaaS+BaaS这样的结构，FaaS就是云函数，BaaS就是各种各样的云服务。

对于一个开发者，已经习惯于在自己熟悉的IDE和框架下开发业务代码，现在被告知要使用Function把业务代码重构一遍，这本身就意味着要投入很大的成本。对于开发团队来说，研发团队需要关注底层是云服务、API、云函数、数据库、云存储各种云服务。实际上大多数对于这些云服务的管理状态是比较混乱的，难以维护。因为云服务有很多，不同的云厂商之间还没有标准，各个服务的实现风格和使用方式也不一样。

所以我们要问：要不要用一个框架来解决这个问题？我认为答案是肯定的，例如基本上现在前端后端所有的开发都要基于框架，用纯原生代码写应用的方式对团队是不友好的。框架有很多好处，包括代码重用，统一规范，专注业务逻辑，还有社区的附加价值，易于自己的代码维护，框架能帮你做很多事情，提升效率。

2. 什么样的框架适合Serverless？

那么一个理想的Serverless框架应该是什么样子？我觉得需要满足两个要求。

（1）组件化

利用组件的机制，可以以业务功能为单元，进行代码的组织和管理，这样可以在业务内部跨团队，甚至整个生态里面复用，进而达到更好的维护。不仅易于维护，也能提升效率。我们认为一个好的Serverless框架，是一个组件化的能提升效率的框架。

（2）标准化

对于开发者提供一套标准的接口和使用方式，屏蔽底层云的异构系统之间的差异。就好比前端工程师熟悉的JQuery或者Polyfill，它们不用关注浏览器的差异，直接用就完了。Serverless的框架也应该做到这点。

3. ServerlessFramework框架介绍

ServerlessFramework就是这样一个组件化、标准化的Serverless应用开发产品。它提供一套非常标准的开发者接口，包括开发、部署、调试、监控，和底层的异构云厂商完全进行隔离，你看到的是完全面向开发者的视图，原来是怎么开发的现在完全不用改变。

组件化方面，Serverless Framework按照业务的维度提供了不同的组件。例如它提供了Expres组件，如果你原来的应用是基于Express开发的，你就可以直接用该组件把原来的应用迁移到Serverless上面来。同时，这个框架提供了研发到上线的全生命周期管理和支持，包括从开发、调试，联调、测试、部署，整套DevOps的流程都被框架所支持。

这个框架也还提供了方便的命令行工具 CLI 供大家使用，时间关系，不再赘述。

四、Serverless组件架构

今天准备聊的再深入一点，聊一下 Serverless Framework 最核心的部分——组件架构 。理解了组件架构以后，就可以理解这个框架具体是怎样工作的。

Serverless Components组件是什么？其实就是npm模块！这个模块使用YAML文件进行配置，这个配置描述的就是你需要用到云厂商的哪些资源，通过描述完成对底层的云资源的使用和分配。

要强调的是，组件之间可以通过组合的关系，用简单的组件组合形成更复杂的组件。如下图所示的 Express Component组件，我们需要配置API网关、SCF云函数，还需要一些数据库，它就是以这些组件合并成的高级组件。

基础的组件，可以通过集成变成高阶的组件。那么一个全栈的应用需要哪一些组件呢？

下图示例，Full stack Appliction（全栈应用），就是以Express component做为服务端的框架，用Website component作为客户端的静态网站，完成了前端+后端的架构。

现在Serverless Framework已经支持了大多数的社区框架组件，下图列出了一些比较常用的，其实支持的组件还要更多。

五、Serverless实践

1. Serverless配置与部署

如果你需要用Serverless，只需要三步：第一步：安装Serverless CLI第二步：对YAML进行配置第三步：将Appliction部署上线

Serverless Framework是一个很有弹性的框架。所谓弹性，如果你是一个资深开发工程师，它提供很多的自定义的项目可以供你配置，比如：部署代码的地区，自定义的域名，是不是采用HTTPS服务等，都是可以通过配置实现的。相反，如果你是一个初学者，你也可以不需要改一行代码，即使用组件的默认配置，默认serverless.yml，也可以完成使用。以Express.js为例：