许多年前，我们开发的软件还是C/S和MVC的形式，再后来有了SOA，最近几年又出现了微服务架构，更新一点的有Cloud Native应用，企业应用从单体架构，到服务化，再到更细粒度的微服务化，应用开发之初就是为了应对互联网的特有的高并发、不间断的特性，需要很高的性能和可扩展性，人们对软件开发的追求孜孜不倦，希望力求在软件开发的复杂度和效率之间达到一个平衡。
什么是Serverless和FaaS？
Serverless顾名思义，指的是一种对开发者完全不需要关注服务器的概念。但是传统的PaaS平台，开发者对服务运行的实例还是有感的，即便是没有调用，也依然需要占用资源，并对资源付费，并不是完全的 Serverless，直到 FaaS 出现。FaaS 全称 Function-as-a-Service，可以理解成给 Function 提供运行环境和调度的服务。Function 可以理解为一个代码功能块，这个功能块具体包含多少功能，无法明确给出定义，但有一个明确的指标：冷启动时间需要在毫秒数量级。因为 FaaS 的本质上是以程序的快速启动来实现正真的按需运行，按需伸缩，以及高可用。Function 配合调度系统，就可以完全做到开发者对服务运行的实例无感，这才是真的 Serverless。
AWS的lambda是目前Serverless/FaaS在工业届最成熟的产品，其文档上有一个演示，非常形象地介绍了FaaS的工作机制。
动画中通过点击鼠标模拟事件，事件越多，lambda 的实例也越多，当没有新的事件的时候，lambda 实例自动销毁。下面引用自 Amazon 官网的介绍：
通过 AWS Lambda，无需配置或管理服务器即可运行代码。您只需按消耗的计算时间付费 – 代码未运行时不产生费用。
借助 Lambda，您几乎可以为任何类型的应用程序或后端服务运行代码，而且全部无需管理。只需上传您的代码，Lambda 会处理运行和扩展高可用性代码所需的一切工作。您可以将您的代码设置为自动从其他 AWS 服务触发，或者直接从任何 Web 或移动应用程序调用。
Amazon Lambda 官网介绍了 Serverless 的3点优势：
- 无需配置或管理服务器
- 持续扩展：AWS Lambda 可通过运行代码以响应每个触发程序来自动扩展您的应用程序。您的代码将并行运行并逐个处理触发程序，按照工作负载的大小精密扩展。
- 次秒级计量：使用 AWS Lambda 时，会按代码执行时间 (以每 100 毫秒为单位) 和代码触发次数收费。代码未运行时，无需支付任何费用。
从后端技术的演进来看待FaaS
没有互联网的时候，应用程序多是单机命令行软件。当互联网出现的时候，有了将应用程序通过网络给其他人提供服务的需求。于是出现了 CGI (Common Gateway Interface)，就是把命令行软件执行的结果通过网络输出。当时的应用程序的架构比较简单，启个 web 服务器监听网络端口，然后根据请求调用 CGI 程序，同时把请求数据传递给 CGI 程序，等待程序执行后把输出结果通过网络端口返回给客户端（一般是浏览器）。这种架构下，只有 web 服务器是常驻运行的，后面的 CGI 程序都是按需运行的，运行后就释放资源。于是诞生了一批支持 CGI 协议的脚本语言，比如 perl，php，asp，一方面脚本语言可以粘结 web 服务器和应用程序，另外一方面它本身也可以包含逻辑，于是逐渐出现专门针对 web 的用脚本编写的应用。
这种方式的优势很明显，按需运算，没有调用就几乎没有资源占用。但缺点也很明显，每次调用都独立运行一个进程，如果并发量大，进程管理的资源浪费严重，随着互联网的发展出现了叫做 FastCGI 的技术。这种技术的思路是执行逻辑的进程不再是按需运行，而是常驻方式，web 服务器和 FastCGI 服务之间通过 unix socket 或者 tcp 进行交互。
同时期出现的技术还有 Java EE，提供了另外一种解决思路。Java EE 提供了一种叫做应用服务器或者 web container 的服务器软件，提供 web 服务器的功能，应用按照 Java EE 的规范暴露入口方法，然后打包成独立的发布包，部署到应用服务器中。应用服务器动态将应用加载到内存，相当于以动态方式把 web 服务器和应用程序合并成同一个程序，同时通过多线程而不是多进程来解决并发问题。这种方式兼顾了性能和应用独立发布的需求，同时依托应用服务器可以支持更多特性，所以 Java EE 能广泛占据企业端的市场。
但是，互联网服务的特点是一个服务给全球人使用，对可移植性和标准化并没那么热衷，但对并发以及性能的要求极高，Java EE 中的特性也没几个能满足这种需求，于是宁愿从头打造工具和组件。互联网高速发展了 10 多年后，大家开始思考，有没有一种应用的架构方式，即可以满足初期的快速研发需求，也可以承载后期的用户规模，还可以将应用的标准化功能沉淀到平台上独立提供？于是有了微服务，于是有了 FaaS。
从云计算的发展来看FaaS
第一阶段的云主要解决硬件资源（网络，计算，存储）的运维和供给问题，也就是 IaaS 云，可以理解成基于硬件资源的共享经济。IaaS 交付的主要是资源，接口以及控制台也是面向资源的。2006年AWS推出EC2云主机，作为最早的IaaS，用户可以通过AWS快速的申请到计算资源，并在上面部署自己的互联网服务。
PaaS（Platform as a Service）是构建在IaaS之上的一种平台服务，提供操作系统安装、监控和服务发现等功能，用户只需要部署自己的应用即可。PaaS 交付的使用服务、应用。Heroko是最早的商业PaaS平台，还有一个开源的PaaS——Cloud Foundry，用户可以基于它来构建私有PaaS。
SaaS 是构建在 PaaS上的云应用或者应用级的服务，其面向的是使用该应用的终端用户或者其上游服务、应用。我们这里不做过多的讨论。
FaaS（Functions as a Service）函数即服务，前面我们已经讨论到，FaaS是Serverless的一种形式。FaaS本质上是一种事件驱动的由消息触发的服务，FaaS供应商一般会集成各种同步和异步的事件源，通过订阅这些事件源，可以突发或者定期的触发函数运行。FaaS使我们更加关注应用程序的逻辑，完全屏蔽了环境配置之类的事情。
从目标来说，PaaS和FaaS二者有相似之处。PaaS 的目标也是给用户的自定义应用提供一种标准化的运行环境。但当前的以 GAE 以及 Cloud Foundry 为代表的 PaaS 解决方案，无论是公有云还是私有云，都一直处于一种不温不火的状态。这一方面是因为时机问题，早期的云用户主要关注的还是资源交付，不是应用交付，另外一方面 PaaS 如果试图要实现应用标准化，必须对应用有侵入和约束，同时 PaaS 接管的还是应用，开发者也是按应用交付的，也就是说，这种约束还需要应用开发者自己在应用中引入框架和 PaaS 平台交互实现。同时当前的 PaaS 并没有彻底屏蔽资源，没有实现按需运行和按需伸缩，很难做到以同一种架构应对用户规模的增长。
而 FaaS 的解决方案就比较彻底，用户交付的不再是应用，而是具体的业务逻辑模块，应用的组装定义由 FaaS 平台或者更高层的应用平台来定义。给 Function 提供标准化运行环境的难度要小于给应用提供标准化运行环境，同时 FaaS 平台的接管能力要大于 PaaS ，可能实现以同一种架构应对不同用户规模。
总结
总的来说，这一波以应用为中心的云原生应用浪潮带来的变革，才刚刚开启，会是下个十年云的主题。无论 FaaS 波及的范围会到那一层，无论未来的应用平台是不是现在 FaaS 这个样子，但大的方向是确定的，并且 FaaS 已经在这个方向上前进，值得期待。
