这是来自martinfowler.com的Serverless架构一文的大意翻译。
什么是Serverless?
Serverless首先是用于描述我们的应用程序是明显或充分地依赖第三方应用或服务来管理服务器端逻辑和状态，这些应用是典型的富客户端应用，比如单页Web应用或移动应用，它们使用基于云可访问的数据库比如Parse或Firebase，还有授权服务比如Auth0AWS Cognito等，这些服务类型之前曾经被描述为后端服务，下面使用Baas这一简称代表后端服务(Backend as a Service)。
其次，Serverless也意味着应用会有一些服务器端逻辑，但是不像传统架构是运行在无态容器中，通过事件触发，它是瞬间的，可能只使用一次，完全由第三方管理，一种思想认为这是“Functions as service函数服务”简称Faas，AWS Lambda就是一种流行的Faas实现，当然还有其他。
当开发Baas shaped应用，特别当开发一个富Web应用，而不是移动应用时，你会需要一些服务器端定制功能，Faas功能也许对于这种情况是一种好的解决方案，特别是如果他们和你使用的BaaS服务集成到一定程度时，这样功能案例包括数据校验和计算敏感的处理，比如图片和视频的制作。
下面是一些案例应用：
UI驱动应用：让我们看看带有服务器端逻辑的传统三层面向客户端系统，比如电子商务应用，传统的架构是看上去像下面：
客户端(浏览器) ---> 宠物店服务器 ---->数据库
这种架构的客户端相对不会太智能，系统中有太多逻辑：授权，分页，搜索和事务等都是由服务器应用实现。
而使用Serverless架构则会如下面：
下面是两者区别：
1.删除了原来在应用中的授权逻辑，使用地反复BaaS服务来替代
2.允许客户端直接访问数据库，比如产品列表等，数据库是第三方主机上比如AWS Dynamo，这样，我们访问数据库的安全策略就和访问服务器资源不同。
3.前面两点意味着非常重要的第三点，原来在宠物店的逻辑现在迁移到客户端了，比如跟踪用户会话，理解应用的UX用户体验结构比如分页，从数据库中读取和转为可用的视图等等，客户端其实这时已经变成了一个单页应用。
4.一些UX相关功能可能会要保留在服务器端，比如计算敏感或需要访问大量数据，比如搜索功能，对于这种功能我们不总是让其运行在服务器端，而是实现一个FaaS函数方式来响应http请求，客户端通过API网关来访问这个FaaS函数。
5.我们也许使用FaaS函数来替代购买功能，让其还是放在服务器端是因为安全原因，不需要在客户端再实现一遍，这也是通过API网关调用。
消息驱动应用
一个不同的案例是后端数据处理服务，假设你正在编写一个用户中心的应用，需要快速响应 UI请求，但是其次你需要截获所有发生活动类型，让我们看看一个在线系统：当用户点击一个广告你要快速导向点击到广告目标网址，但是同时你需要收集刚刚发生的点击事件与信息，这样才是对广告主负责的做法。
传统架构如下，广告服务器同步响应用户，同时会发送一个消息给一个可以异步处理的通道，称为“点击处理器”，应用然后更新数据库等等做其他动作。
而在Serverless架构下，会有多个“点击处理器”作为点击事件的消费者，这些消费应用也是作为FaaS功能运行在第三方提供的事件驱动上下文场景下的。注意，第三方提供消息系统Broker和FaaS环境，这两个系统会彼此紧密联系在一起。
FaaS环境可以并行处理几个点击事件，只要将函数代码实例化多个即可。
解密“函数作为服务”
为了解密FaaS，我们看看Amazon的Lambda产品：
AWS Lambda让你无需任何配置或管理服务器的代价下运行你的代码： (1) Lambda可以运行你的几乎所有类型的应用或后端服务的代码 (2) 因为零管理，只要上传你的代码和lambda会照顾运行等一切 (3) 并以高可用性扩展 (4) 你代码的运行性能. 你能设置你的代码自动从AWS服务触发 (5) 或者直接从任何web或移动应用直接调用你的代码 (6) (此处略去关于上述6点AWS详细说明…………)
状态
在本地状态方面FaaS功能有显著的约束，你能假设任何函数的调用创造的状态，无论是同一个进程或同一个主机内的状态，都不适用于下次调用了，RAM中状态需要写到本地磁盘，也就是说，FaaS是无态的。
这对应用程序体系结构产生了巨大的影响。这意味着FaaS是自然地无态，提供纯输入的函数转换，如果需要存储状态，使用数据库或跨应用的缓存或网络文件存储等等，实现跨请求的状态存储，为下一个请求访问上个请求的状态。
执行时间
FaaS是典型限制每次长调用，AWS Lambda函数不允许调用超过5分钟，超过就会中断。
这意味着长任务运行不适合PaaS，因此你可能需要重新架构：比如创建几个不同的协调的FaaS函数，而在传统环境中，你只需要一个这样的任务，既做协调又做执行。
启动延迟
FaaS函数响应一个请求会有延迟，其延迟有多长取决于很多情况，也许会从10ms到2分钟，让我们使用AWS lambda作为一个案例：
如果你的函数是使用Javascript或Python或少于一千行代码，应该不会运行超过10-100ms，更大的函数也许偶尔会发生长时间运行的情况。
如果你的Lambda函数使用JVM实现，偶尔会看到超过10秒的响应时间，只会在下面情况发生：
1.你的函数处理事件不频繁，两次调用之间长于10分钟
2.你在流量上有突然峰涌，原来每秒处理10个请求突然在10秒内上升到每秒100个请求。
这些情况可以通过这个丑陋方式避免：每隔5分钟ping一下函数的方式确认它是活着。
也就是说， 延迟时间会依赖你的应用风格和流量情况，曾经有一个团队使用异步消息处理Lambda的Java应用实现每天处理几百万的消息，根本不关心启动延迟，如果你编写一个低延迟交易应用，可能就无法使用FaaS系统，不管你使用什么语言实现。
API网关(Gateway)
它是一个HTTP服务器，通过配置实现路由和REST端点服务，每个路由URI都和相应的FaaS函数对应，当API网关接收到一个请求，会通过路由配置匹配到哦相应的FaaS函数。也就是说，API网关是将FaaS函数调用结果转化为Http响应然后返回调用者。
除了纯粹的路由请求以外，API网关也可以执行身份验证，输入验证，响应代码的映射等功能。
我们有一个API网关 + FaaS案例是以Serverless方式创建一个http前端的微服务，从而获得了FaaS函数的扩展性、可管理性和其他好处。
开源
因为Serverless的FaaS应用能够提供生产运行环节的质量要求，而开源项目比如Docker等容器则不属于这个范畴，
Apex开源项目能提供易于构建 部署和管理AWS Lambda函数，能让你用语言方式开发Lamda函数，而不是直接使用Amazon支持的Lambda。
与PaaS比较
如果PaaS能够在20ms内启动实例运行半秒，那么可以称它为serverless。
PaaS并不是将整个应用只为每个请求启动使用的，而FaaS平台恰好是这么做的。
NoOps
Serverless不意味着无运营"No Ops"，只是意味着没有内部系统管理。
存储过程作为服务
一些FaaS函数除了访问数据库的语句以外只有很少的代码，因此这样的FaaS函数也被称为存储过程的服务。但也有些问题，比如会需要使用具体厂商的语言，难以测试和进行版本控制等时比较棘手。Mike Roberts对这些问题都进行了认真讨论。
后记：
什么是Serverless无服务器架构？
Serverless不代表再也不需要服务器了，而是说：开发者再也不用过多考虑服务器的问题，计算资源作为服务而不是服务器的概念出现。Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署，你甚至可以管理某个具体功能或端口的部署，这就能让开发者快速迭代，更快速地开发软件。
以AWS Lambda为案例，Lambda能让不用思考任何服务器，也就是说，不用你处理服务器上的部署、服务器容量和服务器的扩展和失败容错，还有服务器上选择什么OS操作系统，语言的更新，日志等等问题。你的应用程序只需要和多个第三方的API或服务打交道，也可以自我创建一个无服务器的API。
Serverless有以下几个特点：
Serverless意味无维护，Serverless不代表完全去除服务器，而是代表去除有关对服务器运行状态的关心和担心，它们是否在工作，应用是否跑起来正常运行等等。Serverless代表的是你不要关心运营维护问题。有了Serverless，可以几乎无需Devops了。
Serverless不代表某个具体技术，有些人会给他们的语言框架取名为Serverless，Serverless其实去除维护的担心，如果你了解某个具体服务器技术当然有帮助，但不是必须的。
Serverless中的服务或功能代表的只是微功能或微服务，Serverless是思维方式的转变，从过去：“构建一个框架运行在一台服务器上，对多个事件进行响应。”变为：“构建或使用一个微服务或微功能来响应一个事件。”，你可以使用 django or node.js 和express等实现，但是serverless本身超越这些框架概念。框架变得也不那么重要了。
Serverless规模扩展性方面由于充分利用云计算的特点，因此其扩展是平滑的，同时由于Serverless是基于微服务的，而一些微功能微服务的云计算是零收费，这样有助于降低整体运营费用。
++补充：
++Serverless代表着未来云服务正在走向越来越分离关注点的趋势，业务系统不直接与硬件、操作系统和一般容器打交道而是通过一个更高级的容器运行业务系统，业务系统会向容器的管理中心申请各种资源。部署和运维业务不再过多关心具体硬件与其他细节，而是关心自身业务与需要的各种资源调配的设置与应用。以后几乎所有的部署与运维都是针对业务本身，所以以后感觉不到服务器的这个具体的硬件实施的存在。这就是亚马逊定义的“无服务器”架构。
Serverless的架构图
