花了 1000G，我终于弄清楚了 Serverless 是什么（上）？

在过去的 24 小时，我通过微信公号的『电子书』一事，大概处理了 8000 个请求：

Serverless 请求统计

大部分的请求都是在 200ms 内完成的，而在最开始的请求潮里（刚发推送的时候，十分钟里近 1500 个请求），平均的响应时间都在 50ms 内。

Serverless 请求时间

这也表明了，Serverless 相当的可靠。显然，当请求越多的时候，响应时间越快，这简直有违常理——一般来说，随着请求的增加，响应时间会越来越慢。

毫无疑问，在最近的几年里，微服务渐渐成为了一个相当流行的架构风格。微服务大致从 2014 年起，开始流行开来，如下图所示：

microservices vs serverless

而微服务是从 2016 年起，开始受到开发者的关注。并且从其发展趋势来看，它大有可能在两年后，拥有今天微服务一样的地位。可见，它是一个相当具有潜力的架构。

什么是 Serverless 架构？？

为了弄清 Serverless 究竟是什么东西？Serverless 到底是个什么？我使用 Serverless 尝试了一个又一个示例，我自己也做了四五个应用，总算是对 Serverelss 有了一个大致上的认识。

虚拟化与隔离

开发人员为了保证开发环境的正确（即，这个 Bug 不是环境因素造成的），想出了一系列的隔离方式：虚拟机、容器虚拟化、语言虚拟机、应用容器（如 Java 的 Tomcat）、虚拟环境（如 Python 中的 virtualenv），甚至是独立于语言的 DSL。

从最早的物理服务器开始，我们都在不断地抽象或者虚拟化服务器。

服务器技术发展

• 我们使用 XEN、KVM等虚拟化技术，隔离了硬件以及运行在这之上的操作系统。

• 我们使用云计算进一步地自动管理这些虚拟化的资源。

• 我们使用 Docker 等容器技术，隔离了应用的操作系统与服务器的操作。

现在，我们有了 Serverless，我们可以隔离操作系统，乃至更底层的技术细节。

为什么是花了 1000G ？

现在，让我简单地解释『花了 1000G，我终于弄清楚了 Serverless 是什么？』这句话，来说说 Serverless 到底是什么鬼？

在实践的过程中，我采用的是 AWS Lambda 作为 Serverless 服务背后的计算引擎。AWS Lambda 是一种函数即服务（Function-as-a-Servcie，FaaS）的计算服务，简单的来说就是：开发人员直接编写运行在云上的函数、功能、服务。由云服务产商提供操作系统、运行环境、网关等一系列的基础环境，我们只需要关注于编写我们的业务代码即可。

是的，你没听错，我们只需要考虑怎么用代码提供价值即可。我们甚至连可扩展、蓝绿部署等一系列的问题都不用考虑，Amazon 优秀的运营工程师已经帮助我们打造了这一系列的基础设施。并且与传统的 AWS 服务一样，如 Elastic Compute Cloud（EC2），它们都是按流量算钱的。

那么问题又来了，它到底是怎么对一个函数收钱的。我在 Lambda 函数上运行一个 Hello, world 它会怎么收我的钱呢？

如果要对一个运行的函数收费，那么想必只有运行时间、CPU、内存占用、硬盘这几个条件。可针对于不同的需求，提供不同的 CPU 是一件很麻烦的事。对于代码来说，一个应用占用的硬盘空间几乎可以忽略不计。当然，这些应用会在你的 S3 上有一个备份。于是，诸如 AWS 采用的是运行时间 + 内存的计算方式。

内存 (MB)	每个月的免费套餐秒数	每 100ms 的价格 (USD)
128	3,200,000	0.000000208
192	2,133,333	0.000000313
256	1,600,000	0.000000417
...	...	...
1024	400,000	0.000001667
...	...	...

在运行程序的时候，AWS 会统计出一个时间和内存，如下所示：

  
  
REPORT RequestId: 041138f9-bc81-11e7-aa63-0dbab83f773d    Duration: 2.49 ms   Billed Duration: 100 ms     Memory Size: 1024 MB    Max Memory Used: 20 MB

其中的 Memory Size 即是我们选用的套餐类型，Duration 即是运行的时间，Max Memory Used 是我们应用运行时占用的内存。根据我们的 Max Memory Used 数值及应用的计算量，我们可以很轻松地计算出我们所需要的套餐。

因此，如果我们选用 1024M 的套餐，然后运行了 320 次，一共算是使用了 320G 的计算量。而其运行时间会被舍入到最近的 100ms，就算我们运行了 2.49ms，那么也是按 100ms 算的。那么假设，我们的 320 次计算都花了 1s，也就是 10100ms，那么我们要支付的费用是：10320*0.000001667=0.0053344刀，即使转成人民币也就是不到 4 毛钱的 0.03627392。

如果我们先用的是 128M 的套餐，那么运行了 2000 次，就是 200G 的计算量了。

如果我们先用的是 128M 的套餐，那么运行了 8000 次，就是 1000G 的计算量了。

不过如上表所示，AWS 为 Lambda 提供了一个免费套餐（无期限地提供给新老用户）包含每月 1M 免费请求以及每月 400 000 GB 秒的计算时间。这就意味着，在很长的时间里，我们一分钟都不用花。

Serverless 是什么？

而从上节的内容中，我们可以知道这么几点：

• 在 Serverless 应用中，开发者只需要专注于业务，剩下的运维等工作都不需要操心

• Serverless 是真正的按需使用，请求到来时才开始运行

• Serverless 是按运行时间和内存来算钱的

• Serverless 应用严重依赖于特定的云平台、第三方服务

当然这些都是一些虚无缥缈地东西。

按 AWS 官方对于 Serverless 的介绍是这样的：

服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。”[^aws_serverless]

在一个基于 AWS 的 Serverless 应用里，应用的组成是：

• 网关 API Gateway 来接受和处理成千上万个并发 API 调用，包括流量管理、授权和访问控制、监控等

• 计算服务 Lambda 来进行代码相关的一切计算工作，诸如授权验证、请求、输出等等

• 基础设施管理 CloudFormation 来创建和配置 AWS 基础设施部署，诸如所使用的 S3 存储桶的名称等

• 静态存储 S3 作为前端代码和静态资源存放的地方

• 数据库 DynamoDB 来存储应用的数据

• 等等

以博客系统为例，当我们访问一篇博客的时候，只是一个 GET 请求，可以由 S3 为我们提供前端的静态资源和响应的 HTML。

Serverless SPA 架构

而当我们创建一个博客的时候：

• 我们的请求先来到了 API Gateway，API Gateway 计费器 + 1

• 接着请求来到了 Lambda，进行数据处理，如生成 ID、创建时间等等，Lambda 计费器 + 1

• Lambda 在计算完后，将数据存储到 DynamoDB 上，DynamoDB 计费器 + 1

• 最后，我们会生成静态的博客到 S3 上，而 S3 只在使用的时候按存储收费。

在这个过程中，我们使用了一系列稳定存在的云服务，并且只在使用时才计费。由于这些服务可以自然、方便地进行调用，我们实际上只需要关注在我们的 Lambda 函数上，以及如何使用这些服务完成整个开发流程。

因此，Serverless 并不意味着没有服务器，只是服务器以特定功能的第三方服务的形式存在。

当然并不一定使用这些云服务（如 AWS），才能称为 Serverless。诸如我的同事在 《Serverless 实战：打造个人阅读追踪系统》，采用的是：IFTTT + WebTask + GitHub Webhook 的技术栈。它只是意味着，你所有的应用中的一部分服务直接使用的是第三方服务。

在这种情况下，系统间的分层可能会变成一个又一个的服务。原本，在今天主流的微服务设计里，每一个领域或者子域都是一个服务。而在 Serverless 应用中，这些领域及子域因为他们的功能，又可能会进一步切分成一个又一个 Serverless 函数。

更小的函数

只是这些服务、函数比以往的粒度更加细致。

---

更多精彩内容，请期待下一篇