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架构则会如下面：

image.png

下面是两者区别：

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代表着未来云服务正在走向越来越分离关注点的趋势，业务系统不直接与硬件、操作系统和一般容器打交道而是通过一个更高级的容器运行业务系统，业务系统会向容器的管理中心申请各种资源。部署和运维业务不再过多关心具体硬件与其他细节，而是关心自身业务与需要的各种资源调配的设置与应用。以后几乎所有的部署与运维都是针对业务本身，所以以后感觉不到服务器的这个具体的硬件实施的存在。这就是亚马逊定义的“无服务器”架构。

image.png

腾讯云-小程序：Serverless小程序后端技术分享

image.png

image.png

小程序的后台技术

小程序，是一种全新的连接用户与服务的方式，它可以在微信内被便捷地获取和传播，同时具有出色的使用体验。它的加载方式比传统的APP方式更快速上线，体验也不差，除了它本身的界面展示和刷新之外，小程序里面的数据获取通过微信和后端进行交互，小程序的运行实际上是一个类前端的运行方式，整个运行是在微信内，它和后端的交互实际上通过微信进行转发的，运行起来之后，它会提出一个api的请求，这个请求首先给到微信，微信再通过网络apr转到你自己的服务器上，服务器拿到这个请求以后进行数据的处理，然后再响应到前端，这就是小程序和后台交互的一种架构。

image.png

对于后端服务，这张图是大家传统做的方式，暴露api，这些都可以用来开发业务应用，业务应用之后需要有相应的存储文件，结构化的数据存储，或者是非结构化的数据存储，需要有数据库和缓存，为了实现这一套架构且不会由于某一块的服务器宕掉，或者有一些漏洞等等，我们通常的实现是一个较为复杂的过程。比如说，我们为了保证的Serverless和服务器不会垮掉，需要建立一个集群，我们要对外提供服务，需要LB的请求，请求到之后分到某一台服务器上。比如说文件存储，如果单纯只用一台设备，这台设备挂了，整个文件服务就挂了，所以我们要使用分布式存储来解决文件存储的问题。数据库和缓存也是一样的，需要构建集群，无论是两台还是三台还是多台，构建集群以后能确保不会由于某一个单点的问题导致整个服务不可用，从而导致服务瘫痪。

image.png

image.png

如果作为一个小程序开发者，这套架构在互联网公司已经搭建了，作为个人来说这一道太重了，需要了解这里面的某一块和它的配置，比如说数据库的集群怎么配？让大家没法把精力集中到你的业务和小程序本身，而是过多耗在运维和支撑上。

Serverless架构

image.png

我下面要介绍的Serverless架构，采用无服务器的方式，主要会介绍无服务器和云怎么结合，怎么利用云的服务减轻架构化的工作。介绍它的架构之前，我介绍一下Serverless架构，英文称之为Serverless，中文称之为无服务器，大家不用购买服务器，不用购买虚拟机或者物理机，这一块怎么运行呢？它使用计算托管的方式，在Serverless这里，我们可以看成两块，第一块就是函数即服务，它真正实现了你业务的托管计算。另外一种是后端即服务，包括对象存储，大家不用自己构建分布式存储，不用担心数据的丢失和安全性问题；同时在云上提供的数据库，消息队列和对象存储都是一样的，不用购买服务器自己搭建，在购买使用的过程当中我们可以称之为Serverless。因为这些都是托管型的，使用的时候不用关心它的安全性，不用关心可能服务器宕机导致的故障。

image.png

Serverless的计算托管式云在服务函数内，下面来讲一下云函数的架构。大家看到这个架构以后，我们后面在拿一个实际案例来看怎么把具体的api服务落地。云服务器架构本身是计算托管型的，计算托管意味着把真正的业务代码托管到云上面，然后在云上面运行，它的运行方式有一个特点是触发式运营，跟各个产品打通以后，各个产品产生的事件，后面的案例就是和API网关进行结合，从api网关来的事件就是api事件，当这个请求到达api网关时，我们就认为是一个事件，然后再运行。大家最初进行托管的时候，把代码和触发期的配置提交到云上面来，并不是说提交之后代码就运行起来，而是事件到达才运行起来，代码对这个事件进行处理。在这个过程中，对于每一次的事件，每一个代码拉起的过程，实际上都是单独处理一个事件，为什么呢？因为我们在这儿使用并发的模式，如果你有上万个用户同时访问你的小程序，要同时对上万的用户进行服务，启动上万的实例，它是在事件时运行起来，没有事件不能运行，这与微信小程序本身点开即用、用完即走的概念是符合的，有请求时才运行，没有请求时不运行。产品的计费模式也是根据实际运行的时间计费的。

Serverless的使用

image.png

怎么使用Serverless呢？传统的架构就是前面说的web服务，然后是使用存储、缓存，我们对外服务以后，有对外暴露相应的api，实际上用户的业务逻辑都是放在云函数内，需要结构化存储，需要进行缓存或者对象存储，我们需要数据服务或者云缓存服务等，其他的服务都可以直接在线服务，这些服务直接通过代码调用。
前面讲了Serverless的架构介绍，后面是对于这个后台开发的介绍，后面也是基于这个方式进行详细案例的说明。

image.png

小程序除了本身的页面启动，后续与网络的交互都是由小程序发起，经过微信本身以后，首先请求到达api网关，对于对外的api的管理，把这个api暴露到官网上，可以被要程序访问得到。它本身也能够提供api的发布和版本的切换能力，api网关之后就是云函数。云函数就是实际处理业务的逻辑，如果你需要使用数据库，就在代码内发数据库的连接，需要存储文件，就调用相应的窗口写文件。
基于这个方案我们来看一下，传统提供的是中间的一块，因为前端是用户的小程序，后端是微信本身提供的接口服务，中间建议的是开发者自己的服务器。我们现在要展示的一个案例，也就是怎么把中间的开发者服务器替换掉，用Serverless的方案落地，我们使用了api网关加云数据库实现开发者服务器所能够做到的事情，不需要购买服务器而落地我们的api。
首先从最前面的小程序来看，这个案例也是小程序开发者上面的demo，demo的前端包括登陆端口，以及session展示，我们在小程序这端首先获取一个talk，开发者拿到以后再跟微信交互，验证合法以后，我们这里选择了记录到云数据库，这就是小程序界面提供点击登陆的位置，后面的业务会发送请求到云上面来。
对于这个小程序的核心，我们在某一个api上面的路径就是在hos的login url上发起GET操作，根据Wx.login构造请求的头部，body内容，发送获取到的code及加密数据到后台。

image.png

api网关

我们看一下api网关做的事情，它对外以一个api的接口呈现出来，我们直接提供了对外访问的域名，用户基于这个域名绑定自己所拥有的域名，这种情况下可以实现发布的要求，微信小程序的开发者要求域名要备案，把自己的域名绑定到api的服务上面来，对外提供，在右侧api的网关上，配一个/login Get，在后台还未实现之前，可以配置为mock方法，解耦前后端，小程序可以基于api构造的mock数据开发。实现云函数后，对接api到云函数并更新发布api，避免开发的同时影响到在线业务。

云函数的处理流程

从云函数的方面来说，用户会承载计算业务。按照我们最开始用户给的官方图，拿到api的请求以后，解析请求内容，根据规范连接微信认证服务器，获取认证情况并记录session，返回session信息给到请求端。拿到微信服务器的返回以后可以判断用户的登陆过程是成功还是失败，如果成功以后可以拿到用户相应的值，这个地方我们发起到数据库的连接，建立一个masico的连接，完成session的记录。
云函数的处理流程之后，下面展示的是我们怎么和数据库建立连接，登陆信息的细节流程，创建连接并可复用连接，拼装SQL语句并执行。

数据库的配置

这个地方就是我们购买以后，数据库启动并且做了登陆以后，可以进入到数据库里面查看数据，查看session的记录。

实操案例——用户登陆及session展示

创建并初始化实例，按照mysql标准化使用方式操作，计算托管式的优势用户关心核心的代码，不用关心周边的运维，由于托管式业务，无论是个人请求，个人开发者的小程序，很有可能你的一个小程序就成为爆款，爆款以后可能访问量就是突增的形式。
我们利用session的架构实现小程序，而且不用去担心运维；秒级启动，弹性计算能力满足用户上万的并发。核心点关注业务代码，而不用关注web，这就是快速的应用实现小程序的落地的方法。

Q/A

Q：在api网关部署HTTPS证书吗？
A：对，这个证书是腾讯云提供的，绑定你自己域名的时候，可以实现HTTPS的支持。

Q：我们在生产环境的时候由腾讯云提供的证书？
A：对。

Q：在生产环节需要腾讯云提供的证书上线我们的服务？
A：对，这是小程序方面的要求，因为小程序要求必须使用自有域名和小程序打通。

Q：小程序即用即删，如果手机里面有很多会很卡，如果小程序用过在微信上面的页面会显示出来，如果上万个对微信本身有什么影响？
A：可以从一些限制可以看到，现在对于微信小程序的大小有限制的，它本身的大小是要求，目前我记得是5兆包2兆包的大小，如果是上千个，对于你手机来说可能是多存储了一些数据，每个包最大用满可能就是5兆，本身小程序页面的加载都是有限制的，这个限制从微信角度来考虑，都是为了保证小程序的流畅运行，不会对用户的手机造成很大的冲击，这一块要微信的同学介绍，我是偏后端的。

Q：我再举个例子，小程序进入的时候加载速度比较快的，举一个比较极端的，比如说跳一跳，第一次使用的时候，它的加载速度，比如说今天用完了，删掉，过一段时间再进去，相比来说加载速度有差别吗？或者第二次用的时候快一些吗？原因是什么？
A：这个要由微信的同学解答比较好一些，因为这些都是小程序本身的体现，或者说速度的一种体现。

Q：你好，我是做后端开发的，什么样的模型不是用Serverless来做的。
A：Serverless它本身的一些特性也限制了它的使用场景，比如说对于内存的配置，cpu的配置，运行时间的限制，不是所有场合都适用，它本身对运行时间有限制的，不能长时间的运用，包括内存的使用，包括cpu的应用，比如说动画的渲染，长时间的批量计算，这些都不适合api的服务，由于它的请求到达以后必须快速响应用户，api比较适合的。

BaaS云架构核心模式之Serverless架构——用服务代替服务器(Martin Fowler)

Martin Fowler最近非常推崇的serverless架构模式，是BaaS云架构实现的核心架构模式。

Martin Fowler在2016.6.17号发表了一篇博客： 《Serverless Architectures》,引起业界广泛关注：
在这篇博客里，他介绍了serverless架构，以及FaaS，Microservice，Docker等流行的架构和概念，描述了Amazon AWS lambda的价值， 进一步将这种云时代的架构清晰的展现在大家的视野里。
__ 本文很多内容来自这篇博客，让大家清晰了解Martin对serverless架构的概念和价值的阐述。__ 在此基础上我按照模式的讲解思路将进一步阐述我个人对Serverless架构和BaaS之间的关系，以及后续的发展。

image.png

1.概念 (Concept)

Serverless是最新兴起的架构模式，中文意思是“无服务器”架构。跟很多其它软件类似，对Serverless还没有清晰定义，但是肯定有两个互相有重叠的定义：

1. Serverless最初是用于描述依赖第三方服务（‘云端’）实现对逻辑和状态进行管理的应用。典型的包括“富客户端”（例如单页Web应用、移动应用），他们一般都使用基于云端的数据库（例如Parse、Firebase），认证服务（Auth0、AWS congnito）等。
   这类服务以前被称为“（Mobile） backend as a Service （https://en.wikipedia.org/wiki/Mobile_backend_as_a_service）”，我将在本文中称他们为“BaaS”。

2. Serverless也可以指这样的应用，一部分服务逻辑由应用实现，但是跟传统架构不同在于，他们运行于无状态的容器中，可以由事件触发，短暂的，完全被第三方管理。（感谢ThoughtWorks在最近Tech Radar中做出的定义）。这种思路是‘Functions as a Service / FaaS’，AWS Lambda是目前最佳的FaaS实现之一，本文后续介绍中将使用FaaS作为这种架构的缩写。当开发Baas shaped应用，特别当开发一个富Web应用，而不是移动应用时，你会需要一些服务器端定制功能，Faas功能也许对于这种情况是一种好的解决方案，特别是如果他们和你使用的BaaS服务集成到一定程度时，这样功能案例包括数据校验和计算敏感的处理，比如图片和视频的制作。
   但是我更愿意讨论的是本领域第二种方式，相比来说技术架构更新，引领了Serverless的很多创新。然而，这两个领域开始融合，一个例子是Auth0（https://auth0.com/），一开始Auth0是作为Baas（‘Authentication as a Service’），但是随着Auth0 webtask的发布，演变成了FaaS应用。
   更多场合，当开发基于BaaS的应用时，特别当开发基于web的应用而不是移动应用时，更需要一部分服务端功能。特别当跟正在使用的BaaS整合在一起时，FaaS模式可以作为最佳实践。这类功能包括数据认可（以免客户端恶意攻击）和计算敏感进程（例如图像或者视频篡改）。

2.问题 (Problem)

在目前主流云计算IaaS和PaaS中，开发者进行业务开发时， 仍然需要关心很多和服务器相关的服务端开发， 比如缓存，消息服务， web应用服务器， 数据库， 需要对服务器进行性能优化，考虑存储和计算资源， 考虑负载和扩展，考虑服务器容灾稳定性等非业务逻辑的开发。 这些服务器的运维和开发，知识和经验极大的限制了开发者进行业务开发的效率。 如何让开发者无需在服务器实现和部署服务，而直接租用服务或者开发服务而无需关注如何在服务器中运行部署服务，对开发者来说，这是一种去服务器而直接使用服务的架构。

3.背景 (Context)

服务端开发在云计算时代基本是如下趋势：
Real Server->Virtual Server-> Server with Middlewares -> Service
__ 云计算的发展从IaaS，PaaS，SaaS，到最新的BaaS，在这个趋势中serverless(去服务器化）越来越明显。
IaaS将真实的物理机变成了虚拟机， PaaS进一步将虚拟机变成了包含基础设施的中间件服务。 BaaS&SaaS将中间件服务扩展到更基础的后端能力。 这些是云计算解决效率很成本的重要体现。 Serverless这种无服务器架构，用服务代替服务器，无需了解落实服务进一步提高云计算的成本和效率，从而为BaaS这种新时代云计算提供架构基础__

4.限制 (Force)

BaaS要被开发者广泛接受，需要在云端解决以下的限制：
BaaS服务的治理
BaaS服务需要提供逻辑定制扩展
BaaS服务能力独立部署，快速启动
BaaS服务可以弹性扩展，满足大并发需要
BaaS服务可以被监控，计费
BaaS服务要解决DevOps相关的问题
...

5.解决 (Solution)

要实现serverless架构， 需要利用以下技术和方案：
实现BaaS中的云代码特性， 开发者可以直接开发在云端业务代码，实现Functions as a Service。
实现API网关，对用API代表服务的入口，并对所有服务进行治理。
微服务架构技术，用微服务的概念来实施服务的开发。
利用docker容器技术部署运行微服务。

典型场景

UI驱动应用

先讨论一个带有服务功能逻辑的传统面向客户端的三层应用，一个典型的电子商务应用（例如在线宠物商店）。
一般架构如图所示，假如服务端用Java开发完成，客户端用HTML/Javascript：

image.png

这种架构中，因为有不少系统逻辑，例如认证、页面导航、搜索、交易等在服务端完成，客户端显得相对不太智能。
采用Serverless架构，开起来如图二所示：

image.png

这仅是最简单的视图，但是即使如此，还是有不少改变。请注意并不是建议架构迁移，而是使用这个工具来解释某些Serverless概念。

1. 删除了认证逻辑，而用第三方BaaS服务取代。
2. 使用另外一个BaaS，允许客户端直接访问架构与第三方（例如AWS Dynamo）上的数据子库。通过这种方式提供给客户更安全的访问数据库模式。
3. 前两点中包含着很重要的第三点，也就是以前运行在宠物商店服务端的逻辑现在都转移到客户端中，例如跟踪用户访问，理解应用的UX架构（例如页面导航），读取数据库转化为可视视图等。客户端则慢慢转化为单页面应用。
4. 某些我们想保留在服务端的UX相关功能，例如，计算敏感或者需要访问大量数据，比如搜索这类应用。对于搜索这类需求，我们不需要运行一个专用服务，而是通过FaaS模块，通过API Gateway对http访问提供响应。 这样可以使得客户端和服务端都从同一个数据库读取相关数据。 由于原始服务使用Java开发，AWS Lambda（FaaS提供者）支持Java功能，因此可以直接从宠物商店服务端将代码直接移植到宠物商店搜索功能，而不用重写代码。
5. 最后，可以将‘purchase’功能用另外一个FaaS功能取代，因为安全原因放在服务端还不如重新在客户端重新实现，当然前端还是APIGateway。

消息驱动应用

一个不同的例子是后台数据处理服务。例如正在写一个面向用户的应用，需要对UI请求快速响应，但是同时还想获取所有发生的行为。我们设想一个在线广告系统，当用户点击一个广告时，希望快速导向目标，但是同时，需要搜集点击量以便向广告商收取费用。

传统的架构，‘Ad Server’同步地响应客户，但是同时还会向异步处理‘点击量’的应用发送一个消息更新，以便以后向广告商收费的数据库。

image.png

而Serverless架构则如下：

image.png

架构跟我们第一个例子有些许不同，这里我们用FaaS功能取代了一个一直运行的应用。此FaaS运行于方案提供商提供的消息驱动上下文之间。需要注意的是供应商提供了消息代理和FaaS，两者之间更加紧密地合作在一起。
FaaS环境通过复制出若干实例也可以并行处理这些点击，这对开发无疑带来全新概念。

BaaS云代码解决方案 - FaaS(Function as a Service)

FaaS可以作为最细粒度的BaaS， 就像一个接口实现可能有多个Function来完成一样。 一个BaaS服务可以有一个FaaS来实现，也可能是多个FaaS一起成一个chain来完成。 在这里我们将考虑FaaS的概念和实现。
下面的架构图来自IBM OpenWhisk， 非常贴切的描述了BaaS云代码的架构：

image.png

我们已经多次提过FaaS概念，现在我们来看看其真正含义。我们先看看Amazon Lambda产品的公开说明。我自己添加了标记，将会逐一展开说明。

AWS Lambda使得用户不需部署或者管理服务就可运行代码：
（1）…通过Lambda，可以虚拟化地运行任何类型应用和后台服务
（2）—都是免管理的。只需上载代码，Lambda会管理其他一切
（3）并且以高可用模式扩展应用
（4）可以配置自动从其他AWS服务激活代码
（5）或者从任何移动应用中调用。

功能上FaaS就是不需要关心后台服务器或者应用服务，只需关心自己的代码即可。与现代其他架构相比（例如容器和PaaS），这是最大的不同。 如果回到上面所说的点击案例，FaaS代替了点击处理服务器（至少是一台物理服务器，但是绝对是一个特定应用），因为这种架构不需要一台指定服务器，甚至不需要一个一直运行的应用模块来处理。
FaaS并不需要特定框架或者库，从编程语言和环境角度更像是一个普通应用。例如AWS Lambda功能可以采用JavaScript、Python和任何其他JVM语言（Java、Clojure、Scala等）。Lambda功能可以运行任何其他绑定部署的代码，因此可以用任何可以编译成Unix进程的语言。FaaS功能也有一些架构上的限制，特别当面对状态（state）或者执行区间（execution duration）的问题，后面我们会提到。回到上面说的点击系统，转到FaaS架构唯一需要更改的代码就是‘main method/startup’代码（示例中被删除了），开始来代码应该是在顶层消息处理器中（‘message listener interface’实现），但却可能只是在方法签名(method signature)的一个小小改变。所有其他代码（例如写入数据库的代码）都没有任何改变。
因为没有应用服务需要部署因此FaaS跟传统架构差别很大，只需要上载代码到FaaS提供者就足够了。现在这也就意味着上载一个代码包（例如以zip或者JAR形式），然后调用特定API初始话此更新。
水平扩展是完全自动、弹性，由提供者来管理。如果应用需要并发处理100个请求，提供者将会处理后台所有需求。‘计算容器’只是短暂运行应用代码，运行完毕后就销毁这些需求。仍然回到点击案例，假如今天运气不错，客户点击了日常点击量的十倍。点击进程能处理这些变化吗？例如，我们设计的代码可以同时处理多条消息吗？即使可以，一个进程可以处理这么多负载吗？是否可以动态自动扩展进程还是需要手工重新配置？有了FaaS，代码只需要处理并发，而其他自扩展功能则由提供者自动处理。
 FaaS功能是由提供者定义的消息类型触发的。对于Amazon AWS，这些出发包括 S3（文件）更新，时间（调度任务）和添加到消息总线上的消息（例如kinesis）。代码一般都会提供消息源所需的参数。点击案例中，已经假定我们使用了支持FaaS的消息代理。如果还没有的话，就需要一个，对消息生产者也有同样的要求。
许多提供者允许FaaS功能作为http响应来出发，一般是API网关。例如在宠物商店案例中，‘search’和‘purchase’功能。
以下是FaaS，云代码实施中解决的关键问题：

State(状态)

FaaS功能如果使用本地状态，会有很多严格限制。简单说需要假设任何进程间或者主机状态对子进程都不可见，包括在RAM和写到本地盘上的状态。换句话说，从一个部署单元来看FaaS功能是无状态的。这一点对应用架构来说影响很大，同样‘Twelve-Factor App’概念对架构也有细致的限制。
考虑到限制，应该如何解决呢？一般来说FaaS功能要么是自然无状态，也就是提供纯功能调用，要么会使用数据库，跨进程见cache（例如Redis），或者共享文件系统（或者S3）来存放状态或者提供处理请求所需的更多输入信息。

Execution Duration(执行区间)

FaaS功能一般会限制每个功能允许运行多长。目前AWS Lambda功能允许最多运行5分钟，如果超出就被强行退出。这意味着某些长时间运行的任务如果转到FaaS架构，就需要重新设计，也就是说需要多创建几个不同FaaS功能协调器，而在传统架构中，只需有一个就可以了。

Startup Latency(启动延迟)

目前FaaS功能多长时间会响应跟很多因素有关，其延迟可能从10ms到2分钟。听起来不太好，我们用AWS Lambda举个例子。
加入你的功能用Javascript或者Python开发，也不大（例如小于几千行代码），此时延迟一般不会超过10-100ms。更大的功能有可能会有更长的响应时间。
如果Lambda功能运行在JVM上，当JVM运行时，偶尔会看到响应时间更长（例如大于10秒）的情况，然而对于以下情况，高延迟则会很显著：
应用并不是很活跃，大概每十分种处理一次事件。
* 突然流量爆发。例如从每秒10次濡染增长到每秒100次。
前者一般可以通过提高响应频次的方法来解决。
这些问题需要考虑吗？的确需要看应用的具体情况。我以前团队用Java开发过一个异步消息处理Lambda应用，每天处理上亿条消息，而且没有启动延迟问题。也就是说不管采用什么开发语言，如果你想写一个低延时交易应用，现在可能并不适合采用FaaS架构。
为了确认应用是否有问题，最好是用生产类型负载测试一下。如果场景不适合，可以考虑转向FaaS提供商。

BaaS服务治理解决方案 - API网关(API Gateway)

image.png

BaaS云架构中需要将一个后端服务以一个服务点(Restful API)的方式暴露给使用着，同是需要对这些服务点进行管理，提供文档，测试等信息，提高开发者体验。 当一个服务被实现后，提供一个API 网关的东西，将这个服务和服务点API关联起来。
API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facet模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。
API Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过API Gateway，然后路由这些请求到对应的微服务。API Gateway将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在web协议与内部使用的非Web友好型协议间进行转换，如 HTTP协议、WebSocket协议。
关于FaaS我们之前讨论过‘API Gateway’，一个API Gateway是一个http服务器，路由和服务点都在配置里定义，每个路由都跟一个FaaS功能有联系。当一个API Gateway接受请求，找到提供请求服务的路径，然后调用相关FaaS功能。一般API Gateway允许将http参数映射成FaaS功能需要的输入参数。API Gateway将FaaS功能结果转换为http响应，返回调用者。
Amazon Web Services等云服务提供商都各自提供自己的API Gateway。
除了API Gateway路由请求需要认证，输入验证，相应代码映射等，有时候可能还会想是否这是个好主意，那么让我们更深入论证一下。
APIGateway+FaaS的一个应用场景就是用Serverless方式创建http前端微服务，充分利用扩展，管理和其它与FaaS功能有关的其它优点。
目前API Gateway开发工具并不太成熟，因此定义API Gateway应用时候最好不是非常核心的引用。

BaaS服务实施方案 - Microservice

微服务用于解决如何分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
对于Serverless架构里，最关键的就是用将代表复杂答题时应用的服务器消除，取而代之用一些列轻量，简单，易开发维护扩展，相互松耦合，原子性的服务来代替。 MicroService架构也是BaaS种很重要的架构模式， 我们会在后续详细介绍。
BaaS服务DevOps方案 - Docker
在BaaS开发架构中，服务的需要能够动态灵活按需的发布在一个轻量级无状态的容器里，这个容器就是目前流行的Docker，Docker对实施服务的DevOps提供了革命性的方案，后续会详细介绍Docker在BaaS架构体系中的重要性。

6. 案例 （Case）

Beehive云开发平台 - 阿里内部自己的BaaS开发平台

Beehive是按照BaaS架构理念构建的云开发平台， 在这个平台我们预先实现了对社交内容类开发必要的多种功能，包括数据，社交，权限，事件，计数，文件储存，地理位置等。 提供给开发者快速业务创新的平台。 目前已经有2个内部项目通过Beehive云开发平台开发。 该平台在服务器端实现了API Gateway, Data as a Service（通用数据存储）等架构特性。
下个版本，将重点实现Cloud Code(FaaS）， 微服务docker化部署， 能力市场等特性。 打造云时代的新一代开发者平台。 对标Amazon APIGateway & lambda, Google FireBase, IBM BlueMix + OpenWhisk。

• Amazon APIGateway & lambda
• IBM OpenWhisk
• IBM Bluemix OpenWhisk平台让广大开发人员能够迅速构建微服务，从而可以响应诸多事件，比如鼠标点击或收到来自监视摄像头的传感器数据，执行软件代码。事件发生后，代码会自动执行。因而，开发人员不需要为预先配置基础设施之类的事情（比如服务器或系统运行）而操心――他们只需专注于代码，因而显著加快了工作流程。
• Google FireBase
  《2016 Google I/O Firebase, Google在BaaS上又前进了一步》 -这里有对Google Firebase BaaS开发平台详细介绍。
• Auth0
  一开始Auth0是作为Baas（‘Authentication as a Service’），但是随着Auth0 webtask的发布，演变成了FaaS应用。
• Contentful

在BaaS云开发平台基础上，可以很容易开发出各种垂直类的SaaS平台。
Contentful就是一个很好的示例。

image.png

Contenful可以理解为基于BaaS基础上的一个CMS SaaS平台， 虽然是个内容管理平台，对充分体现了BaaS，Serverless， 定制化SaaS等理念。 有兴趣的同学可以深入研究下。
这是一个几乎不用服务器Serverless的内容管理系统网站架构，相比于传统使用WordPress和CraftCMS等内容管理系统可以节省网站的运营管理，相比于维护传统的LAMP架构，Serverless几乎可以没有DevOps。
有时很多客户只是需要一个静态网站，有一个漂亮的图形首页和一些其他静态页面即可，网站一旦发布，几乎很少需要运营维护。那么使用什么技术构建这种静态网站？无疑是Serverless架构，亚马逊的Web服务已经罗列出优点：
1.不需要纠结于操作系统的选择以及安全与管理
2.没有服务器需要配置 监控或扩展
3.没有成本超额造成的风险
4.没有性能考量造成的风险

Serverless更多思考

什么不是Serverless?

目前我们定义Serverless主要意味着’Backend as a Service’ 和 ‘Functions as a Service’。针对他们我们也深入探讨了各种因素。
开始讨论有缺点之前，我们再来看看定义，或者至少定义一下什么不是‘Serverless’。很多人会很迷惘，因此讨论一下还是很值得的。

跟PaaS比较

考虑到Serverless FaaS功能很像12-Factor applications（译者注：是一种创建现代，可扩展，可维护SaaS应用的方法论），它们只是像Heroku的另外一种PaaS吗？下面引用Adrian Cockcroft的一段论述：
如果你的PaaS可以将以前半秒启动的应用在20ms内启动，就叫它Serverless。——Adrian Cockcroft
换句话说，许多PaaS应用不会每次请求来了启动，请求结束则关闭。而FaaS平台是这样的。
好吧，然并卵。如果我是一个很好地12-Factor App开发者，并不会太多开发上的不同吧？这是真的。但是在运维应用上却又很大不同。因为所有好的DevOps-savvy工程师都会同时考虑开发和运维，对吧？FaaS和PaaS在运维方面最大不同来自于可扩展性（scaling）。许多PaaS架构，用户必须考虑scale，例如杜宇Heroku来说需要运行多少Dynos；而对于FaaS应用来说，这是完全透明的。即使配置PaaS应用自扩展，也不会将它设置为请求级别的（除非负载访问情况很特殊），而对FaaS应用来说，从投入角度更加有效。
考虑到这些优势，为什么还是用PaaS架构？有一些原因，但是工具，API Gateway成熟度应该是最大原因。另外，12-Factor Apps为了优化，实现PaaS时会采用App内部只读cache，而对于FaaS来说则没有这个选项。

NoOps

Serverless并不意味着‘免维护’。或许根据你对Serverless有多适应，应该意味着‘不需定时维护’，有很重要的两点需要考虑。
首先，‘Ops’意味着比服务器维护更多的内容。至少还包括监控，部署，安全，网络，以及产品排错和系统扩展。这些问题对于Serverless应用来说仍然还在，需要一种策略来处理。某种程度上，在Serverless世界Ops有些困难，因为一切都是新的。
第二，即使系统管理还在发生，其实我们是他们外包给了Serverless。这并不是件坏事，我们实际上外包了很多事情。但是根据你真正想做什么，可能是件好事也可能时间坏事，有时候这种抽象会出现问题，你需要确认到底是谁在支持你的应用。

Stored Procedures as a Service

关于Serverless FaaS另外一个论点在于‘Stored Precedures as a Service’，我认为这一论点来自于很多FaaS的实现（包括本文中用到的例子）都是小段代码访问数据库。如果这就是所有要求，用FaaS当然是可以的。但是因为这仅仅是FaaS的一小部分功能，用这种想法考虑FaaS是以偏概全了。

还有人说，考虑FaaS是否会带来跟stored procedures同样的问题是值得的，包括技术方面的问题（Camile在tweet上提到这些问题）。使用stored procs值得审视FaaS上下文，这里有很多教训。例如：

经常需要用特定语言，或者是特定的框架、某种语言的扩展。
因为执行时必须要有数据库上下文，测试很困难。
版本控制需要技巧
注意，以上所述并不能涵盖所有stored procs，但是确实是我实际中遇到的问题。我们看看是否也适用于FaaS：

第一点对FaaS实施绝对不使用，因此可以毫不犹豫将它划去。
因为这里我们只讨论编码。整合测试是我们需要后续讨论的另外一个问题。
应为FaaS功能对于代码版本控制足够了，但是对于应用打包来说并没有成熟模板。Serverless框架自己提供了一套，AWS也宣称在2016年五月Serverless大会上发布一套，但是至少现在是一个值得担心的问题。

总结

Serverless代表无服务器计算技术崛起， 是新一代云服务和开发架构的实践。
BaaS是云端一体的开发架构，而serverless是BaaS的服务器端实现的主要架构方式。
Serverless架构是BaaS实现的精髓，是BaaS进一步的解读，FaaS（Function as a service)是BaaS中云代码的实现方式。 Amazon的Lambda是FaaS的实现之一，是很好的参考。
Amazon的BaaS战略通过Amazon API Gateway， Amazon Lambda来实现，在后端服务上已经处于领跑地位，真正把微服务，docker，BaaS等思想落地。

下面有一些简单公示，方便大家理解：
BaaS = 云API + 端API。
云API = service with Serverless(API Gateway + Mirocroserivce + Docker) + ...
端API= 多端SDKs + Component(前端组件)