详解Serverless服务，它会颠覆你对云的理解|雷锋网公开课

Serverless无服务器架构是一个新的事物，从出现到现在也不过两年，目前也没有一个公认的权威定义。从2014年亚马逊正式发布Serverless服务Lambda，经过近两年的发酵，Google、微软与阿里也在2016年相继推出了自己的相关服务。

业界认为，Serverless代表了新的软件设计范式，可能也颠覆了我们一般对云的理解。本次硬创公开课，雷锋网就邀请到了Strikingly创始团队成员及首席架构师龚凌晖，来讲讲Serverless服务到底是什么，它的发展状况又是怎么样的。

龚凌晖，Strikingly创始团队成员，第一个工程师。毕业于复旦大学计算机学院，在加入Strikingly之前，曾在MorganStanley的EnterpriseInfrastructure部门任职。2013年加入Strikingly之后，做过产品，搞过运维自动化，研究过WebAnalytics和SEO，玩过数据分析，目前在团队中负责后端开发，系统运维以及数据分析等部门的项目研发和团队管理。

以下是雷锋网整理的公开课主要内容，更完整内容可观看上面雷锋网公开课的视频：

我们从2014年开始使用AWS。2014年，亚马逊发布了Serverless服务，当时它还是一个颠覆性的想法，少有人使用。我们也是在去年初才把Serverless引入到系统中。

早期的互联网应用依赖传统IDC做系统架构，要有专业的运维人员管理计算资源，还要对系统负载做严格的评估和预测，这样才有时间购买新服务器。后来虚拟化技术提高了灵活性，计算资源拥有者可以把资源打包，按使用时间计费，这也就诞生了IaaS服务。

IaaS对系统的可拓展性和成本控制都有很大作用，但对刚起步的公司来讲，虚拟化仍不够，所以云平台在虚拟化的基础上作了进一步抽象，让开发者只关注应用逻辑，而不用管服务器配置和应用部署，这也就是PaaS。

不过虽然简化了系统的复杂性和开发应用的迭代速度，PaaS依然要调整计算资源的数量来适应系统变化，那如果计算资源可随系统的变化自动伸缩呢？这也就是Serverless诞生的原因。

Serverless不是没有服务器，它与传统去计算服务形态的区别主要包括：

更细粒度的计算资源分配；

基本无需预先计划计算资源；

按需使用，按使用量付费。

不过这些可能也是云计算的特别，而真正的区别就像上图中的比喻，从自行打井水到筒装水再到按需随时使用的自来水，Serverless就像是水龙头，它把服务的灵活性做到了极致，本质是最细粒度的云平台服务形态。

最前沿的Serverless厂商无疑是亚马逊AWS，它从2006年开始提供云计算服务，这种领先也一直延续。微软Azure与阿里云也相继推出Serverless服务。

为什么AWS要开发Serverless？其实用户对云的方便与灵活有越来越高的要求，所以Serverless是一个必定出现的趋势，即使不是AWS，其它厂商也会提出来。下图是AWS Serverless服务发布的时间表。

可能其中最出名的是Lambda，但Serverless包括了方方面面，比如S3就是一个很典型的Serverless服务，按照存储的数据量和访问量收费。

有一个值得关注的点是，2014年AWS发布了Lambda，但Serverless是在近两年后才逐渐引起关注。这是因为2014年容器技术才刚成为关注点，而Serverless太过于前卫，所有的云厂商都没想明白怎么样去发展它，而且生态也不成熟，在落实到工程中仍有很多问题。

AWS用了一年多时间推动Serverless，同时相关的工具也得到了发展，让部分用户尝到了甜头，这也引起了其它厂商的跟进，纷纷在2016年推出服务。其它厂商追赶的时候，AWS也把Lambda拓展到了其它服务，比如物联网和海量数据运输。

Google云平台在2008年发布AppEngine就进入云服务，目前它的Serverless服务CloudFunctions还处于试用阶段。微软Azure云与阿里云也在2016年发布了AzureFunctions和FunctionCompute，都是试用。

接下来介绍几个典型的Serverless服务，以及如何构建实用的解决方案。

下图把AWS的服务分成三类。一是基于EC2直接构建服务。第二类是托管服务，不需要对底层的虚拟机进行管理，只需配置资源大小，它会自动分配资源。托管服务在各云厂商之间的差异较大，也是竞争所在。第三类是Serverless服务，完全由AWS托管，甚至不用预先分配计算资源，也不用考虑实现弹性伸缩，只需要用就可以了。

有代表性的Serverless服务有下列一些。

这是基于事件驱动的Serverless服务。它一不需要管理服务器和抽象的计算资源；二由事件驱动，可自动扩展计算能力；三是实现成本控制，按使用量收，计时可精确到4秒。

如何用Lambda呢？一是把现有的代码包装成Lambda函数；二是选择计算单元的大小，AWS提供了单一唯独的指标，只需要选择运行时所需要的内存大小，就可自动适配GPU，I/O等；三是代码打包上传到AWS；四是指定事件触发方式，如来自API的请求和SNS的消息，它有与其它服务交互的能力。

Lambda使用中要注意的是：

它是一个无状态的计算模型，因此要避免运行过程中安装代码依赖；

二是它的实现机制有一个流量预测算法，但它无法在没有流量的情况下进行预测，因此在一段时间没有执行后，再启动时会有延时，因此要视情况避免冷启动；

三是内置了版本和别名机制，需要合理利用；

四是正确编译平台相关代码。

它是AWS内部分布式NoSQL数据库服务。它的主要特性如下：由AWS完全托管，不需要任何设置就可以获得快速稳定的读写性，存储空间也会随着数据量增长而增长。它也支持Lambda，这样同时支持精细到每一项数据的访问控制。

它是AWS兼容第三方接口的关系型数据库服务，目前还在预览阶段。它的出现是因为，传统数据库解决方案不是为云平台设计的，需要用云的思维重新定义。

AWS引入了SOA理念，重新打造数据库引擎，把传统数据组件分解成一个个的独立模块，再通过自己云平台中已经有的服务来实现这些服务模块。这使得用户不用担心数据库升级，容量扩展这些令人头疼的问题。

如上图，整个数据库服务被分成数据层和控制层，控制层由DynamoDB来存储元数据，Route53提供服务发现，SWF负责SOA中的工作协调。数据层则使用了可靠性强的S3来实现数据的高可用存储。

AWS通过共享存储也实现了读写分离和高可用性，可以满足大部分用户对数据库的要求。Aurora的价格几乎接近开源数据库的价格，只是约高端商业数据库价格的十分之一。

下图是Aurora（蓝色）与MySQL（绿与红）数据库在读写上的性能对比。

总体来说，从经济成本，管理成本和实际效用上，都超越了传统数据库。

典型的web应用通常分为动态与静态资源。在设计中，可以用S3作为静态资源的存储，同时用CloudFront的CDN加速服务。动态这一块DynamoDB作为网站数据存储，通过APIGateway和Lambda实现前端的静态页面调度。整个架构中都用的是Serverless服务。

还可以设计更复杂的架构，如下图：

静态部分还是S3与CloudFront，但加入了高级功能。动态部分加入IAM支持，同时在APIGateway这一层加入流量控制，认证等。还可以加入防火墙服务WAF。

不过Serverless架构中的组件过多，如果API有数十甚至上百个节点，Lambda函数也会这么多，手动管理会十分不方便。因此亚马逊也推出了相应的方案SAM。如下图：

AWSCloudFormation是亚马逊专门用来配置和管理计算资源的服务，SAM是它的一个子集，可以用它打包整个架构设计，自动把所有东西同时打包配置好，做到自动化。

很多数据批处理的逻辑都可以分解成Map-Reduce的合理操作。但亚马逊Lambda提供的思路是，把原始数据存在云端，然后定义filter（把输入的数据分配到多个maper上），maper（执行映射逻辑，并把映射结果存在DynamoDB），reducer（处理映射逻辑，把最终结果存在S3上）三个lambda函数。由于S3和DynamoDB的事件都能触发Lambda函数执行，整个过程可以完全自动完成并自动伸缩。另由于起点和终点都是S3，所以可以把多个Map-Reduce逻辑串联，构成更复杂的处理模型。

Kinesis是亚马逊处理流数据的品牌。下图是简化版且S3和Lambda数据流两步归集的处理系统。

第一步要用Lambda实现初步处理器StreamProcessor，它处理流数据后会把结果保存在S3上。第二是用CloudWatch定时器功能周期性触发Lambda函数，把中间结果进一步处理，把最终结果存在S3上。为了提高效率，第二步中的Lambda是一个任务分配器，可以同时触发多个具体处理数据的Lambda函数，同时对多个S3中的中间结果对象做处理。

这里有一个隐患，它来自Lambda和Kinesis集成方案的技术性区别。两者对接时，前者的并行能力会受到后者并行能力的限制。同时运行的StreamProcessor的数量不能超过Kinesis的数据流分配的数据，这会导致数据流的推积。

解决方法是，如果瓶颈在于对接Kinesis的Lambda函数，那可以缩短函数的执行时间。具体而言，Lambda函数不负责具体的数据处理，而是应该把它给更多Lambda并行处理。由于从Lambda函数触发其它Lambda函数没有并行限制，那可以做到即时处理Kinesis过来的数据。

前文已经提及它的优势，现在再来谈谈它的问题与挑战。总的来说，一些传统开发的技术和经验不适用。

首先是服务细粒度增加了开发大型应用的难度。传统web应用可以管理成百上千的API，但在Serverless中需要开发者有足够的管理能力进来应对。

其次是Serverless只能选用云厂商支持的特定的技术栈，对代码的行为有一定限制。

建立本地开发环境较为困难，调试不便。现在有人在本地用Docker模拟运行环境，这值得一试，但无法完全接近生产环境。

应用安全模型不够成熟，如何实现加密、认证、权限管理都需要时间来检验。

对开发工程师来说，Serverless是一个新的职业发展机遇。它不会完全替代现有的传统开发与部署模式，但一定会在某些领域大放异彩。它也降低了开发高并发应用的门槛，能为应用实现高可扩展与高可用性。

对运维工程师来说，可以更清楚认识到在云计算时代系统运维这个职业的危机。云计算的一个发展趋势是，云厂商把自己在架构和运维实践上的经验产品化，提供给用户，而它们的共有特征是对运维的依赖越来越小，开发工程师可以独立完成系统部署。

不过这个职业的发展方向是兼顾开发，做运维自动化。Serverless也给希望向自动化运维方向转型的工程师提供了职业发展机遇，可以利用Serverless新的运维逻辑，完成运维自动化。

对CTO和架构师来说，Serverless可以帮助理解全新的架构设计思路，把系统架构中一部分用Serverless实现，提供开发和运维效率，用低成本实现可扩展性和可用性。

对CEO与产品经理来说，理解Serverless有助于判断某个产品特性是否适合这一服务进行快速实现。

对于学生来说，学习更新的知识总没错，学习Serverless可以帮助理解新的软件设计范式，为自己的职业发展做准备

可以说，Serverless代表了全新的软件设计范式，需要用新的思路来看待云计算，它已经颠覆了对云的理解。

---

---

相关标签： Serverless无服务器、 云计算、 Strikingly、 硬创公开课、

上一篇：中邮通信Hinova12SE发布骁龙600系卖到2199

下一篇：雅柏威士忌多款单品价格大跌，泥煤顶流也不香