要说目前软件架构中热度十二分的话题，当属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的优势可以简单总结为：
紧随其后，Microsoft Azure也在2016年推出了事件驱动的函数式云计算服务Azure Functions。
其支持用户以多种语言进行函数开发，包括Java、Node.js、php、C#、F#、Bash及Microsoft windows的PowerShell脚本等。
此外，Azure Functions除了提供公有云的版本之外，还提供私有化（On-premises）部署的版本Azure Functions Runtime。
产品功能也是可圈可点：
同样是在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平台产品被称为阿里云函数计算。
如果从事件触发、支持语言以及用户体验等方面考量，该产品也有很多数据值得关注：
同为国内云计算竞争的翘楚，无服务器云函数（Serverless Cloud Function，SCF）是腾讯云推出的函数式计算平台，根据官方的资料，其发布时间是2017年4月26日。
总结下腾讯云Serverless平台的特点：
以上我们探讨的基本是大型公有云服务商针对Serverless的技术实践。
其实与公有云相比，在私有环境中构建Serverless平台，在技术上并没有什么太多障碍，自然也有不少领先的技术尝试，对于此我们会专门成文详细探讨。
可以发现，哪怕是拥有世界范围影响力的公有云服务商针对Serverless的技术探究似乎也出现了缺乏统一认知以及相应标准，无法适应所有的云平台的情况，例如支持的开发语言不同，事件触发的机制有差异等。
毕竟Serverless从来都不是一款产品，也不是一个工具，而是一整套能力的合集。
甚至在实践中还会出现业务轻量化困难、难以在秒级甚至毫秒级别扩容出业务实例；基础设施响应能力不足导致服务发现和日志监控系统等问题。
进而带来大量其他web服务器托管提供商可能会倒闭，很多SaaS平台受到冲击以及运维和实施人员的生存空间进一步缩小等行业现象。
但不容规避的一点，Serverless 架构的兴起使“去服务器化”真正造福了开发者，让基础设施管理出现了新契机。
随着技术上对去中心化以及轻量虚拟化的需求越发强烈，这种“全云化”的模式似乎预示着真正的云时代正在到来，不是吗？
京公网安备 11010802035086号