1.4 Serverless应用架构

要实现Serverless的理念，除了要有相关的工具、框架和平台提供Serverless实现的支持外，对于应用程序本身也有架构上的要求，让应用从架构层面上适应Serverless化的运行和管理环境，以获得Serverless架构的价值最大化。下面我们通过一个简单的例子观察Serverless架构下的应用与传统架构下的应用的异同。

1.4.1 传统应用架构

图1-2所示的是一个订单应用程序的架构图。这是一个常见的传统应用设计和部署架构，应用程序部署在数据中心的主机上。在一个应用的交付件（Deliverable）中包含了多个功能，如订单创建、订单查询和订单修改等。应用数据存储在外部数据库中。数据库和应用一样，也部署在数据中心的主机上，由用户负责运维。这是目前大多数企业中应用的设计和部署架构，在业界已经沿用多年，相信有一定IT工作经验的读者一定不会感到陌生。为了获得同样的订单管理功能，在Serverless架构下应该如何实现呢？

1.4.2 Serverless应用架构

图1-3是Serverless架构下的应用架构图。这个应用实现的功能和前文的应用一样，即为用户提供订单的增删查改服务。应用被部署在Serverless平台之上。应用的功能点变成若干个函数定义，部署于FaaS之中。数据仍然存放在后端数据库中。应用函数通过访问后端的数据库服务获取订单数据。

1.4.3 两种架构的比较

通过对上面两个应用架构图的观察，不难发现Serverless架构下的应用和传统架构下的应用有如下相同的地方：

❑ 两个应用都存在一个逻辑层，负责处理用户请求；

❑ 两个应用的数据都存储在应用外部的数据库中。

这两个架构不同的地方是：

❑ 传统架构的应用部署在主机之上，而Serverless架构的应用部署于Serverless平台之上，由Serverless平台提供运行所需的计算资源。

❑ 传统架构的应用里，所有的逻辑都集中在同一个部署交付件中。Serverless应用的逻辑层部署运行在Serverless平台的FaaS服务之上。因此，应用的逻辑被打散成多个独立的细颗粒度的函数逻辑。因为业务逻辑运行在FaaS服务之上，所以相关的业务逻辑拥有事件驱动、资源自动弹性扩展、高可用等特性。用户也无须运维业务逻辑所消耗的计算资源。

❑ Serverless架构的应用所依赖的数据库从具体的特定数据库实例，变成了数据库服务。用户无须关注数据库所消耗的计算资源的运维。

❑ 在Serverless架构下，由于应用的逻辑分散成了若干个函数，推荐通过API网关对这些函数逻辑进行统一的管控（如流量控制、安全管控、版本管理等）。在完备的Serverless平台上，API网关也会作为一种用户可以快速消费的服务而存在。

❑ 在Serverless架构下，具体的主机资源不再是用户关注的对象，不存于应用架构图中。取而代之的是Serverless平台及其子服务，如FaaS和各类BaaS服务。

Serverless平台的FaaS及BaaS的功能提供了实现Serverless架构理念的技术基础。FaaS是Serverless应用的标准运行环境，BaaS是Serverless应用访问第三方依赖的标准途径。Serverless应用架构的演化其实就是应用为了适应Serverless平台的FaaS和BaaS的一个过程，使得应用的架构可以最大化FaaS和BaaS所带来的价值。

上面的例子只是一个简化的原型，在实际项目中，根据场景的不同，不同Serverless应用架构的具体实现将会有很大的不同。虽然不同应用的架构不同，但是最终要实现的目标还是一致的，那就是实现Serverless这一理念所强调的“无服务器”化。