移动互联网、物联网和大数据应用的快速发展极大地促进了人们对云计算的需求。但是让应用架构拥有良好的可伸缩性和高可用性并非易事，运维和管控庞大的基础架构更是极大的挑战。近年来，一个新的架构风格Serverless成了热门话题。

Serverless架构预示着构建可扩展、强大、具有成本效益和高性能的后端系统的新方法。同时鼓励通过使用Serverless计算服务来执行代码来创建应用程序的新方式。Serverless可以使开发人员专注于真正重要的事务，如解决业务问题和快速迭代。免于业务进行相关的传统成本，例如配置服务器，管理基础设施，修补软件，或支付未使用的计算资源。

本文将全面阐述Serverless架构与传统架构的区别，优势及具体应用场景等。

Serverless简介

近些年来，移动和物联网应用极大推动了Serverless架构与技术的迅猛发展。这种新模式基于微服务架构，正在彻底改变软件开发和部署领域。

值得注意的是，Serverless架构并不是真正的没有服务器，使用“无服务器”有点用词不当。无论使用AWS Lambda之类的计算服务来执行代码还是与API进行交互，仍然有服务器在后台运行。区别在于，这些服务器隐藏起来，我们是看不见的。我们不需要考虑基础设施，也无法调整/改动底层操作系统。别人负责基础设施管理的基本细节，那样我们可以腾出时间处理其他事情。无服务器技术是指，在计算服务中运行代码，并与服务和API进行交互，以完成任务。

Serverless框架被外部事件触发后，会调用自主的代码片段。这些代码片段彼此松散耦合，各个片段实际上旨在每次执行一个任务。Serverless框架负责在运行时编排代码片段。它就好比是在云端可扩展、对开发人员友好的IFTTT服务。这种新兴的云计算服务交付模式为开发人员和管理员带来了许多优点。它提供了合适的灵活性和控制性级别，因而在IaaS和PaaS之间找到了一条中间道路。

Serverless的发展

在一个典型的Web应用程序中，服务器接受来自前端的HTTP请求，处理请求。数据在保存到数据库之前可能经过无数个应用层次。最后，后端生成响应――可能采用JSON或完全呈现的标记这种形式，响应被发回给客户端（图1）。当然，一旦将其他元素考虑进来，比如负载均衡、事务、集群、缓存、消息传递和数据冗余，大多数系统比较复杂。大多数这种软件需要服务器在数据中心或在云端运行，这些服务器需要加以管理、维护、打补丁和备份起来。

服务器的配置、管理和打补丁是一项很耗费时间的任务，常常需要专门的操作人员。很难搭建并高效地运行一个重大的环境。基础设施和硬件是任何IT系统的必要组成部分，但它们也常常让人容易分心，忽视最重要的事情：解决业务问题。

过去这几年出现了平台即服务（PaaS）和容器等技术，这些解决方案有望解决这个头痛的问题：基础设施环境不一致、冲突和服务器管理开销。PaaS是一种云计算，它为用户提供了运行软件的平台，同时把一部分底层基础设施隐藏起来。为了有效地使用PaaS，开发人员需要编写针对该平台相应功能特性的软件。由于大多数PaaS实现方法具有短暂性，把当初被设计成在独立服务器上运行的老式应用程序迁移到PaaS服务，需要额外的开发工作。不过，如果面临选择，许多开发人员会决定使用PaaS，而不是更传统、更手动化的解决方案，那是由于PaaS减少了维护和平台支持方面的要求，这可以理解。

容器化是一种隔离应用程序的方法，让应用程序有自己的环境。这种轻量级方法可替代全面的虚拟化。容器是孤立的、轻量级的，但它们需要部署到服务器上，无论在公共云上、在私有云中还是在现场。如果依赖关系明确，容器是一种出色的解决方案，不过它们在内务处理（housekeeping）方面有各自的挑战和复杂性。它们并不是与仅仅能够直接在云端运行代码来得一样容易。

当我们还在容器的浪潮中前行时，已经有一些革命先驱悄然布局另外一个云计算战场：Serverless。2014年11月14日，亚马逊AWS发布了新产品Lambda。当时Lambda被描述为：一种计算服务，根据时间运行用户的代码，无需关心底层的计算资源。从某种意义上来说，Lambda姗姗来迟，它更像S3，更像云计算的PaaS理念：客户只管业务，无需担心存储和计算资源。

而在此之前不久，2014年10月22日，谷歌今天收购了实时后端数据库创业公司Firebase。Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作，只需编写 HTML＋CSS＋JavaScrip前端代码，不需要服务器端代码（如需整合，也极其简单）。相对于上两者，Facebook 在2014年二月收购的 Parse，则侧重于提供一个通用的后台服务。不过这些服务被称为Serverless或no sever。很像PASS，用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。

Lambda是亚马逊网络服务（AWS）提供的一种计算服务。Lambda能够以一种大规模并行方式执行代码，以响应事件。Lambda拿来你的代码后即可运行，根本不需要配置服务器、安装软件、部署容器，或者是为低层细节而操心。AWS负责配置和管理运行实际代码的弹性计算云（EC2）服务器，并提供开发人员不需要考虑的一套高可用性计算基础设施，包括容量配置和自动扩展机制。无服务器架构这个词是指这些新型的软件架构：不需要直接访问服务器就能运行。通过采用Lambda，并充分利用各种功能强大的单一用途的API和Web服务，开发人员就可以迅速构建松散耦合、可扩展、高效的架构。无服务器架构的最终目的就是，远离服务器和基础设施方面的问题，让开发人员可以主要专注于代码。

Lambda是一种计算服务，它在AWS基础设施上执行用用JavaScript（node.js）、Python或Java编写的代码。源代码部署到孤立的容器上，该容器有单独分配的内存、磁盘空间和处理器。代码、配置和依赖项这一组合通常被称为Lambda函数。Lambda运行时环境可以并行多次调用某个函数。Lambda支持推拉事件操作模式，并与数量众多的AWS服务整合起来。函数可以通过API网关由HTTP请求来调用，也可以按时间表来运行。请注意：Lambda并不是市面上唯一的计算服务。微软Azure函数（Microsoft Azure Functions）、IBM Bluemix OpenWhisk和谷歌云函数（Google Cloud Functions）是可能应该关注的其他计算服务。、

Serverless的概念

Serverless是一种基于互联网的技术架构理念，应用逻辑并非全部在服务端实现，而是采用FAAS（Function as a Service）架构，通过功能组合来实现应用程序逻辑。同时，Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA，按照调用次数进行计费，有效的节省应用成本。

提到Serverless，大家都想到一张经典图描述传统的互联应用架构图与Serverless architactures的不同点，Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA，按照调用次数进行计费，有效的节省应用成本。

Serverless是最新兴起的架构模式，中文意思是“无服务器”架构。目前，业界并没有给出明确的定义，把其分成两种类型，分别为“Backend as a Service” 和 “Functions as a Service”。
“Backend as a Service”即BaaS，是一种新型的云服务，旨在为移动和Web应用提供后端云服务，实现对逻辑和状态进行管理，包括云端数据/文件存储（例如Parse、Firebase）、消息推送、应用数据分析等等。可以说BaaS是诞生于移动互联网，为了加速移动应用开发和降低成本而形成的开发架构。BaaS可以带来后端能力的服务化，服务化也为后端能力优化管理带来了可能，这些能力通过服务开发者而诞生，重复的建设和规划会在初期就得到避免。

开发者通过使用这些服务，实现自己的业务功能的同时，也会对服务的能力进一步提出要求，促进后端服务的发展。BaaS是在PaaS和SaaS之间，为了满足移动互联网快速发展的需要，将后端的能力以服务形式提供，是在PaaS平台开发能力的基础上，用SaaS的思路，将后端能力服务化，让开发者在此基础上开发自己的Software解决方案。

“Functions as a Service”即FaaS，指这样的应用，一部分服务逻辑由应用实现，但是跟传统架构不同在于，他们运行于无状态的容器中，可以由事件触发，短暂的，完全被第三方管理，功能上FaaS就是不需要关心后台服务器或者应用服务，只需关心自己的代码即可。其中AWS Lambda是目前最佳的FaaS实现之一。

Serverless代表无服务器计算技术崛起， 是微服务的一种表现形式，是新一代云服务和开发架构的实践，是云计算发展重点方向之一。Serverless架构是BaaS实现的精髓，是BaaS进一步的解读，FaaS（Function as a service）是BaaS中云代码的实现方式。作为使用方我们不仅熟悉业内Serverless架构的经典产品，而且需要进行学习进而开发属于自己Serverless产品，或者能够很好的进行选型为自己产品快速的开发与运营提供基础条件。

在许多不同的系统和应用程序架构当中，面向服务的架构（SOA）在软件开发人员当中具有很高的知名度。这种架构清楚地使这个想法概念化：系统可以由许多独立的服务组成。SOA方面的文章已写了不少，可是由于开发人员常常把设计理念与具体的实施和属性混为一谈，所以它仍存在争议和误解。

SOA没有硬性规定使用任何特定的技术。相反，它鼓励这样一种架构方法：开发人员创建自治服务，这些服务通过消息传递来进行联系，常常有一种模式（schema）或契约（contract），定义了消息是如何创建或交换的。服务的可重用性、自主性、可组合性、细粒度和可发现性，这些都是与SOA有关的重要原则。

微服务和无服务器架构在核心思想上与面向服务的架构一脉相承。它们保留了许多上述原则和理念，同时试图消除老式的面向服务架构具有的复杂性。

最近出现的一股趋势是，使用微服务架构来实施系统。开发人员往往把微服务考虑成小型、单独、完全独立的服务，它们围绕一个特定的业务用途或功能而建。微服务可能有一个应用程序层，有自己的API和数据库。

理想情况下，微服务应该易于替换，每个服务用一种适当的框架和语言编写而成。微服务可以用不同的通用语言或特定领域语言（DSL）来编写，光这一点就让许多开发人员为之着迷。虽然可以通过使用合适的语言或针对相应任务的一套专用库来获得一些好处，但这也常常是个陷阱。如果拥有多种语言和框架，支持起来有难度；要是没有一套严格的准则，会在将来导致混淆和困难。

每个微服务可能保持其状态、存储数据，这增加了系统的复杂性。一致性和协调性管理也可能成为一个问题，因为状态必须常常跨不同的服务来加以同步。微服务可以通过消息总线间接联系，也可以通过将消息发给对方来直接联系。

可以说，无服务器架构同样体现了来自微服务的许多原则。毕竟，每个计算函数都可以被认为是其自己的独立服务，这取决于你如何设计系统。然而，你不需要完全接受微服务口号，就可以围绕某个特定的业务用途来开发每个函数或服务，保持状态，等等。

无服务器架构的好处在于，你想运用几个微服务原则，就可以随意运用几个，非常的方便快捷。