简介

不知道什么时候，出现了一个叫做 Serverless 架构的模式，看这个英语单词 Serverless，也就是没有服务的意思。没有服务怎么搭建应用程序呢？

后来仔细研究了一下，发现 Serverless 并不是说不需要服务，而是将服务搭建在 BaaS 或者 FaaS 平台上的。通常适用于单页应用程序或者业务逻辑并不负责的程序。

很明显这个 serverless 架构是云厂商想出来的，目的就是要让你用他们的服务。这个跟最近比较流行的 cloud native 有异曲同工之妙。

此类架构虽然消除了对传统架构中搭建服务的需求，可能会受益于显着降低的运营成本、复杂性和工程交付时间，但代价是增加对供应商的依赖和相对不成熟的支持服务。

本文将会详细讨论一下 serverless 和它背后的故事。

什么是 serverless

serverless 的概念毫无疑问是云厂商提出来的，诸如微软，谷歌，亚马逊都是 serverless 的推崇者，并且在他们提供的服务中进行深度绑定和推荐。

那么什么是 serverless 呢？

serverless 其实可以描述两种状态。第一种状态就是那些富客户端，对于富客户端来说业务逻辑都可以在客户端完成，在云端只需要用到数据库服务或者身份验证服务即可，这些类型的服务被称为 BaaS。

还有一种就是服务器端逻辑仍由应用程序开发人员编写，但与传统架构不同，它运行在无状态计算容器中，这些容器是事件触发的、短暂的（可能只持续一次调用），并完全由第三方来调用。这种服务被称为功能即服务或 FaaS。最有名的就是现在比较火的云上的 Lambda 服务了。

serverless 的例子

简单的三层服务

接下来我们来举几个具体可以使用到 serverless 的例子，方便大家的理解。

考虑一个最最常见的 web 项目，提供了增删改查的功能。很明显，我们需要一个客户端，一个服务器端和一个数据库，如下图所示：

上图是一个最简单的服务的例子，我们有一个客户端用来展示对应的 UI 界面，一般来说这个客户端就是浏览器。还有一个服务端用来接收所有的客户端请求和业务逻辑处理。最后有一个数据库用来存储对应的数据。

如果将上面的服务转换成为 serverless 架构，该如何修改呢？

在 serverless 架构中，服务端没有了，转而被各种 FaaS 所替代。然后客户端的功能会被增强，变成富客户端，大部分的业务逻辑都会在客户端进行，甚至在某些情况下可以直接从客户端读取数据库。

必须使用到 FaaS 服务的业务逻辑需要被拆分，如下图所示：

上图中，我们使用了第三方的云认证服务来进行安全认证。同时对于不重要的数据可以直接授权客户端进行数据库的查询。

对于更新服务，还是需要借助于 FaaS 提供的更新 API 来对数据库进行更新。

可以看到，Serverless 的架构已经和原来的架构完全不同了。带来的好处就是系统变得更加灵活，并且对功能重新做了划分，减少了服务端的业务逻辑，有点分布式的效果，对应的服务器成本更低。

缺点就是原来的一个服务被拆分成为了多个服务，需要对多个服务进行监控，然后基本上所有的数据都存放在云端，那么对服务提供商的安全能力提出了更高的要求。最后，这种灵活性和成本的减少会带来系统的复杂性，增加了维护的难度。

消息驱动

一个常见的消息驱动的例子就是前端的点击流上报。当用户在客户端点击某个按钮之后，会去调用服务端的某个接口。这个接口会将点击消息发送到消息队列中，然后再启用异步的后端服务从消息队列中拿取消息，最后更新数据库。

那么上面的例子如果用 Serverless 该怎么实现呢？

我们需要将服务端替换成 FaaS，并且将异步服务也替换成对应的 FaaS：

这里的好处是可以借助 FaaS 的快速拓展功能，在消息数量比较多的情况下，可以动态扩展消息处理函数，从而提升系统的处理速度。

FaaS

上面我们提到了很多次 FaaS，那么 FaaS 到底是什么呢？

按照它的英文原意，FaaS 就是函数作为服务。或者你可以看做是亚马逊的 AWS Lambda 服务。

AWS Lambda 可以不需要任何服务器就可以运行，只需要上传你的业务代码，就可以自动生成一个 Lambda 服务。然后这个服务就可以供外部调用。

当然，这里的不需要服务器是指客户不需要自己购买服务器和在上面搭建服务，事实上 lambda 也是需要在服务器上运行的。

FaaS 基本上可以兼容 Javascript、Python、Go 和任何 jvm 语言编写的代码，只需要做少许更改即可重新生成为 FaaS 服务。

FaaS 的另外一个优点就是可以水平扩展，并且这个水平扩展是完全自动的。这个水平扩展自动管理是由运营商来控制的，用户不需要考虑到实现的底层细节。这种水平扩展能力对于服务在某个时刻的峰值应用是非常有效的。

我们只需要设计好 FaaS 函数，剩下的一切都交给云厂商去做即可。

FaaS 的缺点

FaaS 是无状态的，也就是说你不能够使用本地内存变量或者本地磁盘的数据，因为 FaaS 不能保证这些数据的有效性和持久性。

所以需要对要存储的数据进行外部持久化。

另外，由于云服务器的限制，每次 FaaS 的调用都有一个最长超时时间，所以 FaaS 只适合那些能够快速响应的程序。

另外，FaaS 在启动的时候可能需要初始化，这种函数的实例化可能会带来请求的延迟。所以需要考虑云提供商的启动策略，并作出相应的调整。

当我们决定使用任何外包策略时，您都将部分系统的控制权交给第三方供应商。这种缺乏控制可能表现为系统停机、意外限制、成本变化、功能丢失、强制 API 升级等。

• 多租户问题

多租户是指多个不同客户（或租户）的多个软件实例在同一台机器上运行的情况，并且可能在同一托管应用程序中运行。这是一种云服务商实现规模经济效益的策略。服务供应商尽最大努力让客户觉得他们每个人都是唯一使用他们系统的人，但是，没有一个完美的方案能够同时解决多租户的安全性（一个客户能够看到另一个客户的数据）、健壮性（一个客户的软件中的错误导致另一个客户的软件出现故障）和性能（一个高负载的客户）等方面的问题。

• 供应商绑定

如果你在一个服务商使用了 serverless,那么将其切换到另外一个供应商的成本是巨大的。可能需要更新对应的运营工具，还可能需要更新代码。

FaaS 的优点

我们可以把 Serverless 看做是最简单的外包解决方案，你不需要自己管理服务器和数据库，这些都可以托管给云厂商。

一方面，基础设施服务的投入变少了，另外一方面，可以节约维护这些基础设施的人力成本。

另外，您对代码进行的任何性能优化不仅会提高应用程序的速度，而且它们将与降低运营成本有直接或者间接的联系，具体取决于服务供应商的收费方案。例如，假设一个应用程序最初需要一秒钟来处理一个事件。如果通过代码优化将这一时间减少到 200 毫秒，将立即看到计算成本节省 80%，而无需进行任何基础架构更改。

与部署整个服务器相比，打包和部署 FaaS 功能很简单。您所做的就是将所有代码打包成一个 zip 文件，然后上传。

总结

serverless 架构是目前比较热门的一种架构方式，我们可以去尝试使用这种新的架构方式，来看看能否给我们的业务带来不同的变化。但是也需要看到并不是所有的服务都可以使用 serverless 架构。我们需要对其进行权衡。

本文已收录于 http://www.flydean.com/11-serverless-architecture/

最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！