11 Serverless Architecture

11. 架构之:serverless架构

简介

不知道什么时候，出现了一个叫做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架构。我们需要对其进行权衡。