共计 2940 个字符，预计需要花费 8 分钟才能阅读完成。
作者 | aoho
起源 | Serverless 公众号
Serverless 是什么？
Serverless 架构是不是就不要服务器了？答复这个问题，咱们须要理解下 Serverless 是什么。
Serverless 架构近几年频繁呈现在一些技术架构大会的演讲题目中，很多人对于 Serverless，只是从字面意义上了解——无服务器架构，然而它真正的含意是开发者再也不必过多思考服务器的问题，当然，这并不代表齐全去除服务器，而是咱们依附第三方资源服务器后端，从 2014 年开始，通过这么多年的倒退，各大云服务商根本都提供了 Serverless 服务。比方应用 Amazon Web Services(AWS) Lambda 计算服务来执行代码。
国内 Serverless 服务的倒退绝对 AWS 要晚一点，目前也都有对 Serverless 的反对。比拟驰名的云服务商有阿里云、腾讯云。它们提供的服务也大同小异：函数计算、对象存储、API 网关等，非常容易上手。
架构是如何演进到 Serverless？
看看过来几十年间，云计算畛域的倒退演进历程。总的来说，云计算的倒退分为三个阶段：虚拟化的呈现、虚拟化在云计算中的利用以及容器化的呈现。云计算的高速倒退，则集中在近十几年。
总结来说有如下的里程碑事件：
- 通过虚拟化技术将大型物理机虚构成单个的 VM 资源。
- 将虚拟化集群搬到云计算平台上，只做简略运维。
- 把每一个 VM 依照运行空间最小化的准则切分成更细的 Docker 容器。
- 基于 Docker 容器构建不必治理任何运行环境、仅需编写外围代码的 Serverless 架构。
从裸金属机器的部署利用，到 Openstack 架构和虚拟机的划分，再到容器化部署，这其中典型的就是近些年 Docker 和 Kubernetes 的风行，进一步倒退为应用一个微服务或微性能来响应一个客户端的申请，这种形式是云计算倒退的天然过程。
这个倒退历程也是一场 IT 架构的演进，期间经验了一系列代际的技术改革，把资源切分得更细，让运行效率更高，让硬件软件维护更简略。IT 架构的演进次要有以下几个特点：
- 硬件资源应用颗粒度变小
- 资源利用率越来越高
- 运维工作逐渐缩小
- 业务更聚焦在代码层面
1. Serverless 架构的组成
Serverless 架构分为 Backend as a Service(BaaS) 和 Functions as a Service(FaaS) 两种技术，Serverless 是由开发者实现的服务端逻辑运行在无状态的计算容器中，它是由事件触发、齐全被第三方治理的。
2. 什么是 BaaS?
Baas 的英文翻译成中文的含意：后端即服务，它的利用架构由大量第三方云服务器和 API 组成，使利用中对于服务器的逻辑和状态都由服务提供方来治理。比方咱们的典型的单页利用 SPA 和挪动 APP 富客户端利用，前后端交互次要是以 RestAPI 调用为主。只须要调用服务提供方的 API 即可实现相应的性能，比方常见的身份验证、云端数据 / 文件存储、音讯推送、利用数据分析等。
3. 什么是 FaaS?
FaaS 能够被叫做：函数即服务。开发者能够间接将服务业务逻辑代码部署，运行在第三方提供的无状态计算容器中，开发者只须要编写业务代码即可，无需关注服务器，并且代码的执行是由事件触发的。其中 AWS Lambda 是目前最佳的 FaaS 实现之一。
Serverless 的利用架构是将 BaaS 和 FaaS 组合在一起的利用，用户只须要关注利用的业务逻辑代码，编写函数为粒度将其运行在 FaaS 平台上，并且和 BaaS 第三方服务整合在一起，最初就搭建了一个残缺的零碎。整个零碎过程中齐全无需关注服务器。
Serverless 架构的特点
总得来说，Serverless 架构次要有以下特点：
- 实现了细粒度的计算资源分配
- 不须要事后分配资源
- 具备真正意义上的高度扩容和弹性
- 按需应用，按需计费
因为 Serverless 利用与服务器的解耦，购买的是云服务商的资源，使得 Serverless 架构升高了运维的压力，也无需进行服务器硬件等预估和购买。
Serverless 架构使得开发人员更加专一于业务服务的实现，中间件和硬件服务器资源都托管给了云服务商。这同时升高了开发成本，按需扩大和计费，无需思考基础设施。
Serverless 架构给前端也带来了便当，大前端深刻到业务端的老本升高，开发者只须要关注业务逻辑，前端工程师轻松转为全栈工程师。
Serverless 有哪些利用场景？
利用场景与 Serverless 架构的特点密切相关，依据 Serverless 的这些通用特点，咱们演绎出上面几种典型应用场景：弹性伸缩、大数据分析、事件触发等。
1. 弹性伸缩
因为云函数事件驱动及单事件处理的个性，云函数通过主动的伸缩来反对业务的高并发。针对业务的理论事件或申请数，云函数主动弹性适合的解决实例来承载理论业务量。在没有事件或申请时，无运行实例，不占用资源。如视频直播服务，直播观众不固定，须要思考适度的并发和弹性。直播不可能 24 小时在线，有较为显著的业务拜访高峰期和低谷期。直播是事件或者公众点爆的场景，更新速度较快，版本迭代较快，须要疾速实现对新热点的技术升级。
2. 大数据分析
数据统计自身只须要很少的计算量，离线计算生成图表。在闲暇的时候对数据进行解决，或者不须要思考任何延时的状况下。
- 开发者编写代码，目前反对的语言 Java、NodeJS、Python 等语言；
- 把代码上传到函数计算上，上传的形式有通过 API 或者 SDK 上传，也能够通过控制台页面上传，还能够通过命令行工具 Fcli 上传；
- 通过 API&SDK 来触发函数计算执行，同样也能够通过云产品的事件源来触发函数计算执行；
- 函数计算在执行过程中，会依据用户请申请量动静扩容函数计算来保障申请峰值的执行，这个过程对用户是通明无感知的；
- 函数执行完结。
3. 事件触发
事件触发即云函数由事件驱动，事件的定义能够是指定的 http 申请，或者数据库的 binlog 日志、音讯推送等。通过 Serverless 架构，在管制台上配置事件源告诉，编写业务代码。业务逻辑增加到到函数计算里，业务高峰期函数计算会动静伸缩，这个过程不须要治理软硬件环境。常见的场景如视频、OSS 图片，当上传之后，通过进行后续的过滤、转换和剖析，触发一系列的后续解决，如内容不非法、容量告警等。
小结
回到咱们文章的结尾，Serverless 架构不是不要服务器了，而是依靠第三方云服务平台，服务端逻辑运行在无状态的计算容器中，其业务层面的状态则被开发者应用的数据库和存储资源所记录。
Serverless 无服务器架构有其适宜利用的场景，然而也存在局限性。总得来说，Serverless 架构还不够成熟，很多中央尚不欠缺。Serverless 依赖云服务商提供的基础设施，目前来说云服务商还做不到真正的平台高可用。Serverless 资源尽管便宜，然而构建一个生产环境的利用零碎却比较复杂。
云计算还在一直倒退，基础设施服务日趋完善，开发者将会更加专一于业务逻辑的实现。云计算将平台、中间件、运维部署的责任进行了转移，同时也升高了中小企业上云的老本。让咱们一起期待 Serverless 架构的将来。
参考：
- 阿里云文档
- https://blog.csdn.net/cc18868876837/article/details/90672971