由 dawei
要说目前软件架构中热度十二分的话题，当属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。