共计 5201 个字符，预计需要花费 14 分钟才能阅读完成。
本篇内容主要讲解“Serverless 是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“Serverless 是什么”吧!
要说目前软件架构中热度十二分的话题，当属 Serverless。
通常我们会将其翻译为“无服务器架构”。
尽管成天被称为“无服务器”，但该架构与传统架构不同，显然并不是真的不需要服务器。
而是选择将服务器等基础设施的管理“隐藏”起来，计算资源作为服务而不是作为服务器的概念出现。
兼具事件触发、短暂以及完全被第三方管理等多重属性，其中开发者只需关注业务逻辑即可。
那一年，也就是 2012，TA 首次出现在技术人的视野之中。
就在崭露头角之后的短短两年，号称云计算“3A 巨头”之一的 AWS，就于当年年底正式推出了 Lambda 产品，标志着 Serverless 的商业化进程隆重被开启。
当时的 Lambda 曾被大家如此描述：这是一种计算服务，可以根据时间来运行用户的代码，无需关心底层的计算资源。
从 2012 年到 2014 年，Lambda 着实不算早到。
但就像云计算 PaaS 初出茅庐时的说法一样：用户只管业务就好，底层 IaaS 就交给我们吧！
Serverless 与 PaaS 带给人们的理念是如此惊人的相似。
随后的两年时间内，Google Cloud Function 和微软 Azure Function 在技术圈子的成功，也就顺理成章将 Serverless 推进了热化阶段。
从架构变迁聚焦 Serverless 内涵
对于众多开发者而言，显然仅仅知道“Serverless 被定义为无服务器架构”的概念完全不够，如何将 Serverless 的理解更具象化一些？
恐怕还是要从软件应用架构演进的角度说起。
或许你可能了解，在十几年前，单体应用作为最主流的应用架构形式被广泛认可。
依靠一台服务器外加一个数据库，就能让服务可用性达到峰值状态。
但随着服务器老化性能下降甚至自身损坏的情况，再加上企业业务量的逐渐扩大，单体架构再也不是“一招鲜吃遍天”。
哪怕在流量入口加入负载均衡器，让单体应用可以部署在多台服务器上来增加弹性，也不能完全解决由代码无物理边界所带来的大量冲突。
至此，单体应用架构第一次有机会进化成微服务架构，而此时的架构师们也就不得不直面分布式带来的新挑战。
例如那些年的缓存服务 Redis、状态协调服务 ZooKeeper、消息服务 Kafka 等。
我们可以简单理解为，将一个大系统划分为多个业务模块，其中的业务模块又需要分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互，这件事儿似乎没那么简单。
当然除了分布式环境的特殊性以外，微服务架构也给运维带来了不小改变。
具体实践中，由于微服务可以部署在不同的服务器上，也可以部署在相同的服务器却不同的容器上，包括应用分发标准、生命周期标准以及自动化弹性等能力在内的重要性也就一一凸显出来。
转眼到了众所周知的云原生时代，业务直接上云不说，还能提供标准化的应用托管服务，包括版本管理、发布、上线后的观测、自愈等，价值红利得到进一步彰显。
而此时 Serverless 也正迎着这波技术红利闯入了大众的视线，得到关注。
可以看出，在架构的演进中，无论是研发还是运维人员都逐渐将着眼点从机器向平台系统转移，而不是单纯用人去管理，这或许是对于 Serverless 原理最朴素的阐释。
总结一下，Serverless 的出现其实是将主机管理、操作系统管理、资源分配等，甚至是应用逻辑全部组件都集成为服务。
如果将其放在当下的云计算场景中，就不能单纯狭义理解为“不用关心服务器”那么简单，毕竟上云的资源除了服务器之外，还涉及基础计算、存储资源、网络资源等诸多，也包括数据库、缓存以及消息队列等更上层的范畴。
Serverless 架构类同 FaaS，又做何解？
提及 Serverless，很多人的第一反应都是 FaaS+BaaS。
的确，这是 Serverless 的一种实现形式，也是一种比较主流的理解。
所谓“FaaS+BaaS”，其实就是函数即服务与后端即服务的结合体。
具体来说，BaaS（Backend as a Service）可以被解释为“后端即服务”。
一般是 API 调用后端或别人已经实现好的程序逻辑，通常用来管理数据。
例如，亚马逊 RDS 可以替代自己部署的 MySQL，当然其中还有各种其它数据库、中间件的作用。
FaaS（Functions as a Service）则是函数即服务，作为无服务器计算的一种形式，当前使用最广泛的当属 AWS 的 Lambada。
经过长期实践我们认为，Serverless 架构可以提供一种更加“代码碎片化”的软件架构范式，而所谓的“函数”（Function），则是提供相比微服务更加细小的程序单元。
进一步来说，究竟该如何理解“函数即服务”的概念？
大致上是开发者先将函数定义封装在容器中，通过调用函数来实现调用后端存储等服务。
本质上，FaaS 是一种事件驱动的由消息触发的服务。
与传统的服务器端软件的不同，经应用程序部署到拥有操作系统的虚拟机或者容器中，一般需要长时间驻留在操作系统中运行。
而 FaaS 则可以直接将程序部署上到平台上，当有事件到来时触发执行，执行完了就可以消灭。
更重要的一点，FaaS 产品不需要对特定框架或库进行编码。
还是以 AWS Lambda 函数为例，函数可以在 Javascript、Python、Go 等，也就是任何 JVM 语言（Java，Clojure，Scala 等）或.NET 语言中实现；但与此同时，Lambda 函数还可执行与其部署工件捆绑在一起的另一个进程。
在 FaaS 环境中，用户将函数功能代码上传到 FaaS 提供商，其中对的水平扩展是完全自动弹性的。
而“函数”还可以代表客户所要执行的每个操作，即每个函数完成一个相对简单的业务逻辑，一个完整的应用由若干个函数组成，主要包括创建、读取、更新以及删除等。
目前，函数即服务（Function as a Service，FaaS）是当下 Serverless 实现的技术基础。
因为 FaaS 和 Serverless 之间关系密切，所以 FaaS 的特点也可以被认为是 Serverless 平台的特点，但如果单纯认为 Serverless 就是 FaaS，就比较狭义了。
BaaS 时代仅仅以 API 的方式提供应用依赖的后端服务；而在 FaaS 时期，用户与开发者不再关注底层，这么说 Serverless 繁荣也是合理有据的事儿。
使用 Serverless，也是一把双刃剑
据实际观察，一直以来企业使用 Serverless 通常会涉及几方面因素，其中“减少运营成本”被认为是最直观有效的原因之一。
的确，应用 Serverless 后，企业就无需再为潜在的流量高峰买进大部分时间都可能空闲的服务器机架，而是根据流量进行自动伸缩，采用按请求量来付费的灵活方式。
此外“自动按需扩展”可以发挥到极致：随时扩展到当前的使用量，消除了意外或者季节性流量高峰的困扰。
更重要的是，Serverless 不需要关心内存泄露，还具备将云数据库、云消息队列等服务囊括在内的完善配套设施，极大减少工作量。
哪怕企业中大部分的开发人员都出身软件，对修复保护以及管理并不擅长，一样可以做到专注软件开发，Serverless 绝对没问题。
基于此，一直以来国内外都有很多企业致力于提供基于 Serverless 框架的能力服务，接受程度更是水涨船高，简单盘点下，尤其是几家大型的公有云厂商。
例如里程碑式的 AWS Lambda。
作为 AWS 针对 Serverless 架构推出的 FaaS 云服务，AWS Lambda 自 2014 年上线以后就受到广泛关注，除了满足大家对 Serverless 的期望之外，更重要的是 AWS 平台的成功。
AWS Lambda 的优势可以简单总结为：
成熟度高：第一个在主流公有云平台上的 Serverless FaaS 平台，已经有数年的发展和沉淀用户基数大：AWS Lambda 有较大的用户基数，参考案例很多活跃的社区：目前开源社区有很多围绕 AWS Lambda 展开的开源项目 AWS 的整合：AWS Lambda 天然和 AWS 平台上的服务有良好集成紧随其后，Microsoft Azure 也在 2016 年推出了事件驱动的函数式云计算服务 Azure Functions。
其支持用户以多种语言进行函数开发，包括 Java、Node.js、PHP、C#、F#、Bash 及 Microsoft Windows 的 PowerShell 脚本等。
此外，Azure Functions 除了提供公有云的版本之外，还提供私有化（On-premises）部署的版本 Azure Functions Runtime。
产品功能也是可圈可点：
完整性：Azure Functions 是一个功能比较完备的 Serverless FaaS 平台整合：Azure Functions 天然与 Azure 云平台上各类服务有良好的集成平台：对于使用微软体系产品和工具构建 IT 能力的企业而言，Azure Functions 是 Serverless 转型的首选平台私有化：提供带有商业支持的私有化部署版本，可满足不同层面的用户的需求同样是在 2016 年，Google Cloud Platform 推出了 Google Cloud Functions 平台，也同时加入 Serverless 领域的竞争序列。
同为 FaaS 平台，Google Cloud Functions 与 AWS Lambda 和 Microsoft Azure 在功能上最大的区别有啥？
细数以后，可能在于 Google Cloud Functions 目前仅支持 JavaScript 作为函数开发语言，运行环境为 Node.js。
2018 年 7 月，Google 又顺势公布了开源项目 Knative，定位为 Kubernetes 的 Serverless 插件，推出后得到了 Pivotal、IBM 以及 Red Hat 的大力支持。
国外争先恐后，国内也是蜂拥而至。阿里云作为国内第一批推出 Serverless 平台的公有云厂商，其 FaaS 平台产品被称为阿里云函数计算。
如果从事件触发、支持语言以及用户体验等方面考量，该产品也有很多数据值得关注：
事件触发：阿里云函数计算可以被阿里云上的服务事件触发，例如阿里云对象存储（OSS）支持语言：阿里云函数计算目前支持的开发语言为 Node.js，并计划后续将支持 Java 及 Python 整个函数代码的部署包大小不能超过 50MB，部署包解压后的代码不能超过 250MB 用户体验：阿里云函数计算提供了基于 Web 的控制台和 SDK；用户可以通过 Web 控制台管理函数应用，也可以通过交互式的命令行来操作服务规格：一个服务下最多包含 50 个函数和 10 个触发器。在运行时，函数最长的运行时间为 300s，即 5min，一个函数的最大并发数为 100 同为国内云计算竞争的翘楚，无服务器云函数（Serverless Cloud Function，SCF）是腾讯云推出的函数式计算平台，根据官方的资料，其发布时间是 2017 年 4 月 26 日。
总结下腾讯云 Serverless 平台的特点：
函数运行时：腾讯云 SCF 目前支持 Python、Java 及 Node.js 作为函数的开发语言用户可以以压缩包的形式从本地上传代码，也可以引用腾讯云对象存储中的代码文件事件触发：目前腾讯云 SCF 支持的事件触发源有腾讯云对象存储 COS、定时器、腾讯云消息服务 CMQ，以及用户手动通过 API 及控制台触发服务规格：每个函数将在一个基于 CentOS Linux 的环境中被执行。函数执行的内存范围为 128MB 至 1536MB，单个区域支持的最大函数定义数量为 20 个，函数执行的最大时长为 300 秒，最大的并发数为 5 以上我们探讨的基本是大型公有云服务商针对 Serverless 的技术实践。
其实与公有云相比，在私有环境中构建 Serverless 平台，在技术上并没有什么太多障碍，自然也有不少领先的技术尝试，对于此我们会专门成文详细探讨。
可以发现，哪怕是拥有世界范围影响力的公有云服务商针对 Serverless 的技术探究似乎也出现了缺乏统一认知以及相应标准，无法适应所有的云平台的情况，例如支持的开发语言不同，事件触发的机制有差异等。
毕竟 Serverless 从来都不是一款产品，也不是一个工具，而是一整套能力的合集。
甚至在实践中还会出现业务轻量化困难、难以在秒级甚至毫秒级别扩容出业务实例；基础设施响应能力不足导致服务发现和日志监控系统等问题。
进而带来大量其他 web 服务器托管提供商可能会倒闭，很多 SaaS 平台受到冲击以及运维和实施人员的生存空间进一步缩小等行业现象。
但不容规避的一点，Serverless 架构的兴起使“去服务器化”真正造福了开发者，让基础设施管理出现了新契机。
到此，相信大家对“Serverless 是什么”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
