当前大多数公司在运营应用产品时，无论是选择公有云还是自建的数据中心，都会面临服务器数量预估、存储容量规划和数据库的选型等问题。同时需要在基础设施之上部署依赖软件，以运行应用程序。当前是否存在一种简单的架构模型能够满足我们这种应用场景？当然，这个架构已经存在许久，它就是今天软件架构世界中很热门的一个话题——Serverless。
初识Serverless
值得关注的是，在最近的几年里，微服务逐渐成为了一种新潮且实用的架构方案。微服务从2014年开始流行，如下图所示：
而Serverless的理念是从2016年开始兴起，从其发展趋势来看，它在两三年后，可能对微服务架构的地位构成一定的挑战。我们可以知道这么几点：
开发者专注于业务，摆脱运维的负担
Serverless按需使用
Serverless运行时间计费
Serverless应用严重依赖于特定的云平台、第三方服务
在一个基于AWS产品开发的Serverless应用里，由以下组件构成：
API Gateway来处理并发请求，其包括认证、流量管理、授权和访问控制、监控等功能
计算服务Lambda来进行代码相关的一切计算工作，诸如授权验证、请求、输出等等
基础设施管理CloudFormation创建和配置 AWS 基础设施部署，诸如所使用的S3存储桶的名称等
静态存储S3存储前端代码和静态资源
数据库DynamoDB存储应用的相关数据
因此，Serverless 并不意味着没有服务器，只是服务器以不同功能的第三方服务的形式存在。
在这种情况下，模块的分层演变为不同的服务。在现今的微服务设计中，每一个领域或者子域都是一个服务。而在Serverless应用中，这些领域及子域根据他们的功能，又可能会进一步切分成不同的Serverless函数。
云的征程
很久之前，我们开发的软件由C/S和MVC的架构，转变为SOA，直到最近几年的微服务架构，更近一点就是Cloud Native（云原生）应用，企业应用从单体架构，到服务化，再到更细粒度的微服务化，应用开发之初就是为了应对业务的特有的高并发、容错等特性，需要很高的性能及可扩展性，人们对软件开发的追求孜孜不倦，希望力求在软件开发的复杂度和效率之间达到一个平衡。但可惜的是，没有银弹！几十年前（1975年）Fred Brooks就在The Mythical Man-Month中就写到了这句话。那么Serverlss会是那颗银弹吗？
云改变了我们对操作系统的认知，原来一个系统的计算资源、存储和网络是可以分离配置的，而且还可以弹性扩展，但是长久以来，我们在开发应用时始终没有摆脱的服务器的束缚，应用必须运行在服务器上（不论是实体还是虚拟的），并且必须经过部署、配置、初始化才可以运行，还需要对服务器和应用进行监控和管理，同时需要保证数据的安全性，当前的云产品能解放我们吗？
Serverless架构是云的延伸，为了理解serverless，我们有必要回顾一下云计算的发展。
IaaS
2006年AWS推出EC2（Elastic Compute Cloud），作为第一代IaaS（Infrastructure as a Service），用户可以通过AWS快速的申请到计算资源，并在上面部署自己的互联网服务。IaaS从本质上讲是服务器租赁并提供基础设施外包服务。就比如我们用的水和电一样，我们不会自己去引入自来水和发电，而是直接从自来水公司和电网公司购入，并根据实际使用付费。
EC2真正对IT的改变是硬件的虚拟化（更细粒度的虚拟化），而EC2给用户带来了以下五个好处：
- 降低劳动力成本：减少了企业本身雇佣IT人员的成本
- 降低风险：不用再像自己运维物理机那样，担心各种意外风险，EC2有主机损坏，再申请一个就好了。
- 降低基础设施成本：可以按小时、周、月或者年为周期租用EC2。
- 扩展性：不必过早的预期基础设施采购，因为通过云厂商可以很快的获取。
- 节约时间成本：快速的获取资源开展业务实验。
有利有弊，我们将在后面讨论。
PaaS
PaaS（Platform as a Service）是构建在IaaS之上的一种平台服务，提供操作系统安装、监控和服务发现等功能，用户只需要部署自己的应用即可，最早的一代是Heroku。Heroko是商业的PaaS，还有一个开源的PaaS——Cloud Foundry，用户可以基于它来构建私有PaaS，如果同时使用公有云和私有云，如果能在两者之间构建一个统一的PaaS，那就是“混合云”了。
在PaaS上的卓越贡献者当属docker了，因为docker理念的横空出世，推动了PaaS技术的发展，从mesos、swarm与kubernetes的群雄逐鹿到后来kubernetes一家独大，再到CNCF的成立，这些我们后续再慢慢道来。因为使用容器的轻量、隔离型，推进了应用的容器化日程。管理云上的容器，可以称为是CaaS（Container as a Service），如GCE（Google Container Engine）。也可以基于Kubernetes、Mesos这类开源软件构件自己的CaaS，不论是直接在IaaS构建还是基于PaaS。
PaaS是对软件的一个更高的抽象层次，已经接触到应用程序的运行环境本身，可以由开发者自定义，而不必接触更底层的操作系统。
Serverless
当然，Serverless不如IaaS和PaaS那么好理解，因为它通常包含了两个方面BaaS（Backend as a Service）和FaaS（Function as a Service）。
BaaS
BaaS（Backend as a Service）后端即服务，一般是一个个的API调用后端或别人已经实现好的程序逻辑，比如身份验证服务Auth0，这些BaaS通常会用来管理数据，还有很多公有云上提供的我们常用的开源软件的商用服务，比如亚马逊的RDS可以替代我们自己部署的MySQL，还有各种其它数据库、中间价和存储服务等。
FaaS
FaaS（Functions as a Service）函数即服务，FaaS是无服务器计算的额一种形式，当前使用最广泛的是AWS的Lambada。
现在当大家讨论Serverless的时候首先想到的就是FaaS。FaaS本质上是一种事件驱动的由消息触发的服务，FaaS服务商一般会集成各种同步和异步的事件源，通过订阅这些事件源，可以突发或者定期的触发函数运行。
与传统的服务器端软件的不同是经应用程序部署到拥有操作系统的虚拟机或者容器中，一般需要长时间驻留在操作系统中运行，而FaaS是直接将程序部署上到平台上即可，当有事件到来时触发执行，执行完了就可以杀死。
根据MF网站的无服务器架构定义，FaaS是：
- 从根本上说，FaaS是关于运行后端代码而无需管理自己的服务器系统或您自己的长期驻留long-lived的服务器应用程序。与容器和PaaS（平台即服务）等其他现代架构趋势进行比较时，第二个子句 - 长期驻留（long-lived）的服务器应用程序是一个关键的区别。（FaaS不是长期驻留的普通API）
- FaaS产品不需要对特定框架或库进行编码。FaaS函数是语言和环境的常规应用程序。例如，AWS Lambda函数可以在Javascript，Python，Go，任何JVM语言（Java，Clojure，Scala等）或任何.NET语言中实现。但是，Lambda函数还可以执行与其部署工件捆绑在一起的另一个进程，因此您实际上可以使用任何可以编译为Unix进程的语言。
- 部署与传统系统有很大不同，因为我们没有自己运行的服务器应用程序。在FaaS环境中，我们将函数功能的代码上传到FaaS提供商，提供商执行配置资源，实例化VM，管理流程等所需的一切。
- 水平扩展是完全自动的，弹性的，并由提供者管理。如果您的系统需要并行处理100个请求，则提供商将处理该请求而无需您进行任何额外配置。函数的执行是一个“计算容器”，运行是短暂的，FaaS提供者实现容器的创建和销毁完全是由运行时需求驱动。最重要的是，使用FaaS ，供应商可以处理所有底层资源配置和分配 - 用户根本不需要集群或VM管理。(容器+FaaS是Serverless重要的机制，只有容器或FaaS都是片面的，两者分别是静态和动态的)
- FaaS中的函数通常由提供程序定义的事件类型触发。
- 大多数提供程序还允许触发函数作为对入站HTTP请求的响应; 在AWS中，通常通过使用API网关来实现这一点。函数也可以通过平台提供的API直接调用，无论是在外部还是在同一个云环境中，但这是一种相对不常见的用法。
技术对比
Serverless与FaaS
微服务（MicroService）是软件架构领域业另一个热门的话题。如果说微服务是以专注于单一责任与功能的小型功能块为基础，利用模组化的方式组合出复杂的大型应用程序，那么我们还可以进一步认为Serverless架构可以提供一种更加“代码碎片化”的软件架构范式，我们称之为Function as a Services（FaaS）。而所谓的“函数”（Function）提供的是相比微服务更加细小的程序单元。例如，可以通过微服务代表为某个客户执行所有CRUD操作所需的代码，而FaaS中的“函数”可以代表客户所要执行的每个操作：创建、读取、更新，以及删除。当触发“创建账户”事件后，将通过AWS Lambda函数的方式执行相应的“函数”。从这一层意思来说，我们可以简单地将Serverless架构与FaaS概念等同起来。
FaaS与PaaS
乍看起来，FaaS与PaaS的概念在某些方面有许多相似的地方。人们甚至认为FaaS就是另一种形式的PaaS。但是Intent Media的工程副总裁Mike Roberts有自己的不同看法：“大部分PaaS应用无法针对每个请求启动和停止整个应用程序，而FaaS平台生来就是为了实现这样的目的。”
FaaS和PaaS在运维方面最大的差异在于缩放能力。对于大部分PaaS平台，用户依然需要考虑缩放。但是对于FaaS应用，这种问题完全是透明的。就算将PaaS应用设置为自动缩放，依然无法在具体请求的层面上进行缩放，而FaaS应用在成本方面效益就高多了。AWS云架构战略副总裁Adrian Cockcroft曾经针对两者的界定给出了一个简单的方法：“如果你的PaaS能够有效地在20毫秒内启动实例并运行半秒,那么就可以称之为Serverless”。
