Serverless 微服务架构案例

本文是GitChat《Serverless 风格微服务的持续交付（上）：架构案例》部分内容已做修改。文章聊天实录请见：“顾宇：构建Serverless 风格微服务实战解析（上）”

无服务器架构 (Serverless Architectures) 简介

Serverless 架构最早可以追溯到 Ken Fromm 发表的文章《Why The Future Of Software And Apps Is Serverless》。在这篇文章里， Ken Fromm 描述了未来云计算基础设施成熟的条件下应用程序是不需要服务器端的。在无武器场景下构建应用程序的时候。开发人员和运维人员无需担心服务器如何安装配置，如何设置网络和负载均衡，无需监控状态，甚至不再会出现服务器相关的工作内容。这样可以让原本建设机房的时间成本和货币成本从按年计算缩短至按秒计算。

在 Martin Fowler 的博客《Serverless Architectures》中，他将无服务器架构分为两种：

第一种无服务器架构被称为被称为BaaS（Backend as a Service，后端应用即服务）。即应用的架构是由一大堆第三方 API 来组织的。一切状态和逻辑都由这些服务提供方来管理。随着移动应用和单页 Web 应用这样的富客户端（Rich Client）应用的普及，前后端的通信渐渐以 API 调用为主，而所需的服务不再由 服务端应用开发工程师和运维工程师来维护，只需要调用提供服务的第三方 API 就可以完成相应的功能。例如云上的数据库服务和用户认证服务。

另一种无服务器架构被称为FaaS（Function as a Service，函数即服务)。这一架构的兴起源于 AWS Lambda 的发展。 AWS Lambda 是一种无状态的代码运行时服务，这项服务提供最小的代码运行资源。你可以使用 Java，Node.js，Python 和 C# 编写程序处理 AWS 各种服务的事件。无需初始化一台服务器，安装操作系统并配置程序运行环境。由于运行资源很少，完成的计算有限，使得这种应用无法保存状态，因此这类程序以函数的方式存在。

本文所介绍的 Serverless 架构主要是以 AWS Lambda 以及 Amazon API Gateway 架构的应用，它同时也具备 BaaS 的特征。

AWS Lambda 的编程模型

AWS Lambda 运行在一个假想的虚拟容器里，但你无法通过 API 配置这个容器。此外，这个虚拟的容器有一些资源限制，主要限制如下：

5 分钟（300 秒）的程序运行时间。

512 MB 的文件系统空间。（在 /tmp 目录下）

最大1536 MB 的内存。（最小 128 MB，以 64 MB 作为增量）

最多 1024 个文件描述符。

最大 1024 个内部线程。

AWS Lambda 的编程模型如下所示：

Lambda 的执行流程：

当事件触发 Lambda 执行的时候，Lambda 会将事件所携带的信息通过上下文对象（Context Object）传给处理函数（Handler）。此外，Lambda 还可以读取预先设置的环境变量。

执行处理函数，并将日志通过 CloudWatch 记录下来。

执行完毕后通过事件返回执行结果，或者抛出异常。

执行结果和对应的异常可以绑定其它资源继续处理。

当事件请求大批量发生的时候。Lambda 会为每一个事件单独执行一次 。这意味着每一个请求之间的执行期间，内容是不能共享的。（经本人亲测，内存中存储的是可以共享的，但内容保留的有效时间和状态无法保证。）

Amazon API Gateway + AWS Lambda 的微服务架构

根据 Martin Fowler 对