统统透透看无服务器计算：由来、场景和问题

1、 无服务器（Serverless）计算是什么

云计算涌现出不少改变传统IT架构和运维方式的新技术，好比虚拟机、容器、微服务，不管这些技术应用在哪些场景，下降成本、提高效率是云服务永恒的主题。过去十年来，咱们已经把应用和环境中不少通用的部分变成了服务。Serverless的出现，带来了跨越式变革。Serverless把主机管理、操做系统管理、资源分配、扩容，甚至是应用逻辑的所有组件都外包出去，把它们看做某种形式的商品——厂商提供服务，咱们掏钱购买。过去是“构建一个框架运行在一台服务器上，对多个事件进行响应”，Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”，作到当访问时，调入相关资源开始运行，运行完成后，卸载全部开销，真正作到按需按次计费。这是云计算向纵深发展的一种天然而然的过程。
Serverless是一种构建和管理基于微服务架构的完整流程，容许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不一样之处在于，彻底由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程当中）计算容器内。构建无服务器应用程序意味着开发者能够专一在产品代码上，而无须管理和操做云端或本地的服务器或运行时。Serverless真正作到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。
国内外的各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出Serverless产品，Serverless也从概念、愿景逐步走向落地，在各企业、公司应用开来。

2、 理解Serverless技术---FaaS和BaaS
Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 彻底被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。
Serverless涵盖了不少技术，分为两类：FaaS和BaaS。
1）Function-as-a-Service (FaaS)
• 小段代码，按需执⾏，按需扩展，无需管理任何基础实施相关的部分。
• 事件驱动型计算。函数被事件触发或者被HTTP请求调用。
2）Backend-as-a-Service (BaaS)
• 第三方基于API的服务，实现应用开发中的基础功能模块。
• 这些API像服务同样，自动扩展，无需管理。

1.Faas
FaaS意在无须自行管理服务器系统或本身的服务器应用程序，便可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其余现代化架构最大的差别。
FaaS能够取代一些服务处理服务器（多是物理计算机，但绝对须要运行某种应用程序），这样不只不须要自行供应服务器，也不须要全时运行应用程序。
FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。例如AWS Lambda的函数能够经过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也能够执行任何捆绑有所需部署构件的进程，所以可使用任何语言，只要能编译为Unix进程便可。FaaS函数在架构方面确实存在必定的局限，尤为是在状态和执行时间方面。
在迁往FaaS的过程当中，惟一须要修改的代码是“主方法/启动”代码，其中可能须要删除顶级消息处理程序的相关代码（“消息监听器接口”的实现），但这可能只须要更改方法签名便可。在FaaS的世界中，代码的其他全部部分（例如向数据库执行写入的代码）无须任何变化。
相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其余事情都可由供应商完成。目前这种方式一般意味着须要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。
FaaS中的函数能够经过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件能够包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。一般你的函数须要经过参数指定本身须要绑定到的事件源。
大部分供应商还容许函数做为对传入Http请求的响应来触发，一般这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。

2.Baas
BaaS（Backend as a Service，后端即服务）是指咱们再也不编写或管理全部服务端组件，可使用领域通用的远程组件（而不是进程内的库）来提供服务。理解BaaS，须要搞清楚它与PaaS的区别。
首先BaaS并不是PaaS，它们的区别在于：PaaS须要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台须要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS能够是公共云服务商提供的，也能够是第三方厂商提供的。其次从功能上讲，BaaS能够看做PaaS的一个子集，即提供第三方依赖组件的部分。

BaaS服务还容许咱们依赖其余人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。不少应用都要本身编写实现注册、登陆、密码管理等逻辑的代码，而对于不一样的应用这些代码每每大同小异。彻底能够把这些重复性的工做提取出来，再作成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队不再用本身编写或者管理实现这些功能的代码。

3、 无服务器（Serverless）计算如何工做？
与使用虚拟机或一些底层的技术来部署和管理应用程序相比，无服务器计算提供了一种更高级别的抽象。由于它们有不一样的抽象和“触发器”的集合。
拿计算来说，这种抽象有一个特定函数和抽象的触发器，它一般是一个事件。以数据库为例，这种抽象也许是一个表，而触发器至关于表的查询或搜索，或者经过在表中作一些事情而生成的事件。
好比一款手机游戏，容许用户在不一样的平台上为全球顶级玩家使用高分数表。当请求此信息时，请求从应用程序到API接口。API接口或许会触发AWS的Lambda函数，或者无服务器函数，这些函数再从数据库表中获取到数据流，返回包含前五名分数的必定格式的数据。
一旦构建完成，应用程序的功能就能够在基于移动和基于 Web 的游戏版本中重用。
这跟设置服务器不一样，不是必需要有Amazon EC2实例或服务器，而后等待请求。环境由事件触发，而响应事件所需的逻辑只在响应时执行。这意味着，运行函数的资源只有在函数运行时被建立，产生一种很是高效的方法来构建应用程序。

4、 无服务器（Serverless）适用于哪些场景？

在现阶段，Serverless主要应用在如下几个场景。首先在Web及移动端服务中，能够整合API网关和Serverles服务构建Web及移动后端，帮助开发者构建可弹性扩展、高可用的移动或 Web后端应用服务。在IoT场景下可高效的处理实时流数据，由设备产生海量的实时信息流数据，经过Serverles服务分类处理并写入后端处理。另外在实时媒体资讯内容处理场景里，用户上传的音视频到对象存储OBS，经过上传事件触发多个函数，分别完成高清转码、音频转码等功能，知足用户对实时性和并发能力的高要求。无服务器计算还适合于任何事件驱动的各类不一样的用例，这包括物联网，移动应用，基于网络的应用程序和聊天机器人等。这里简单说两个场景，方便你们思考。
场景一：应用负载有显著的波峰波谷
Serverless 应用成功与否的评判标准并非公司规模的大小，而是其业务背后的具体技术问题，好比业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具备波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显降低，由于不能进行资源复用而致使浪费。

业界广泛共识是，当自有机器的利用率小于 30%，使用 Serverless 后会有显著的效率提高。对于云服务厂商，在具有了足够多的用户以后，各类波峰波谷叠加后平稳化，聚合以后资源复用性更高。好比，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个成熟的云服务厂商，若是其平台足够大，用户足够多，是不该该有明显的波峰波谷现象的。

场景二：典型用例 - 基于事件的数据处理
视频处理的后端系统，常见功能需求以下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。
开发者须要本身写出实现逻辑，再将任务按照控制流链接起来，每一个任务的具体执行由云厂商来负责。如此，开发变得更便捷，而且构建的系统自然高可用、实时弹性伸缩，用户不须要关心机器层面问题。

5、Serverless 的问题
对于企业来讲，支持Serverless计算的平台能够节省大量时间和成本，同时能够释放员工，让开发者得以开展更有价值的工做，而不是管理基础设施。另外一方面能够提升敏捷度，更快速地推出新应用和新服务，进而提升客户满意度。可是Serverless不是完美的，它也存在一些问题，须要慎重应用在生产环境。
一、不适合长时间运行应用
Serverless 在请求到来时才运行。这意味着，当应用不运行的时候就会进入 “休眠状态”，下次当请求来临时，应用将会须要一个启动时间，即冷启动时间。若是你的应用须要一直长期不间断的运行、处理大量的请求，那么你可能就不适合采用 Serverless 架构。若是你经过 CRON 的方式或者 CloudWatch 来按期唤醒应用，又会比较消耗资源。这就须要咱们对它作优化，若是频繁调用，这个资源将会常驻内存，第一次冷启以后，就能够一直服务，直到一段时间内没有新的调用请求进来，则会转入“休眠”状态，甚至被回收，从而不消耗任何资源。
二、彻底依赖于第三方服务
当你所在的企业云环境已经有大量的基础设施的时候，Serverless 对于你来讲，并非一个好东西。当咱们采用某云服务厂商的 Serverless 架构时，咱们就和该服务供应商绑定了，那么咱们再将服务迁到别的云服务商上就没有那么容易了。

咱们须要修改一下系列的底层代码，能采起的应对方案，即是创建隔离层。这意味着，在设计应用的时候，就须要隔离 API 网关、隔离数据库层，考虑到市面上尚未成熟的 ORM 工具，让你既支持Firebase，又支持 DynamoDB等等。这些也将带给咱们一些额外的成本，可能带来的问题会比解决的问题多。

三、缺少调试和开发工具
当我使用 Serverless Framework 的时候，遇到了这样的问题：缺少调试和开发工具。后来，我发现了 serverless-offline、dynamodb-local 等一系列插件以后，问题有一些改善。然而，对于日志系统来讲，这仍然是一个艰巨的挑战。

每次你调试的时候，你须要一遍又一遍地上传代码。而每次上传的时候，你就好像是在部署服务器，并不能老是快速地定位出问题在哪。后来，找了一个相似于 log4j 这样的能够分级别记录日志的 Node.js 库 winston。它能够支持 error、warn、info、verbose、debug、silly 六个不一样级别的日志，再结合大数据进行日志分析过滤，才能快速定位问题。
四、构建复杂
Serverless 很便宜，可是这并不意味着它很简单。AWS Lambda的 CloudFormation配置是如此的复杂，而且难以阅读及编写（JSON 格式），虽然CloudFomation提供了Template模板，但想要使用它的话，须要建立一个Stack，在Stack中指定你要使用的Template,而后aws才会按照Template中的定义来建立及初始化资源。

而Serverless Framework的配置更加简单，采用的是 YAML 格式。在部署的时候，Serverless Framework 会根据咱们的配置生成 CloudFormation 配置。然而这也并不是是一个真正用于生产的配置,真实的应用场景远远比这复杂。

6、总结
云计算通过这么多年的发展，逐渐进化到用户仅需关注业务和所需的资源。好比，经过K8S这类编排工具，用户只要关注本身的计算和须要的资源（CPU、内存等）就好了，不须要操心到机器这一层。

Serverless架构让人们再也不操心运行所需的资源，只需关注本身的业务逻辑，而且为实际消耗的资源付费。能够说，随着Serverless架构的兴起，真正的云计算时代才算到来了。

任何新概念新技术的落地，本质上都是要和具体业务去结合，去真正解决具体问题。虽然Serverless不少地方不成熟，亟待完善。不过Serverless自身的优越特性，对于开发者来讲，吸引力是巨大的。相信随着技术的飞速发展，Serverless在将来还有无限可能！