一个简单的 Serverless 架构例子

Posted 2021-04-30 Serverless架构

Serverless 不是一颗银弹，它是一种架构理念，有它自己的优势和适用场景。本文以使用 AWS Serverless 技术构建一个简单的 microservice 为例，谈谈这种架构如何节省开发和运维成本。作为该专栏的第一篇文章，笔者也希望能以此抛砖引玉，为此专栏带来更成熟的观点和更优秀的文章。

应用场景

首先假设一个场景：公司 A 是做某个垂直领域的电商，刚刚起步，流量不是特别大，但发展势头不错。他们需要一个管理优惠码的 service，做几件事情：

1. 添加优惠码

2. 删除优惠码

3. 验证优惠码

目前预计上线时需要处理的请求最多每秒 1 个，但随着公司业务规模扩大，特别是验证优惠码的请求量，估计会增长很快。

传统方案 vs Serverless 方案

实现这个 service 可以有多种方案，先说说非 Serverless 中的一种的解决办法：

这个方案通过 ELB 将请求分发到处理业务逻辑的 EC2 上，数据则是存储在 DyanmoDB 里。为保证 High Availability，一开始使用分布在 3 个不同 Availability Zones 的 3 台 EC2，考虑到公司业务增长很快，使用 Auto-scaling Group 确保在需要时能自动添加 EC2 去处理请求。以上为大体架构方面的工作，此外还需要做的事情包括：管理EC2的密匙、定时更新 EC2 系统确保安全性、配置防火墙及 Security Group 确保安全性等等。

搭建这个 service 的费用，抛开网络流量和存储，单单看 EC2 运行的费用。假设一开始使用的是通用类型实例中的 m4.xlarge，On-demand 的费用一个月一台 EC2 接近 80 美元（EC2 费用计算器）。至少有3台 EC2 一直在跑，也就至少 240 美元。这是刚上线时的预计，随着业务扩大，整个系统的 scale 也会扩大，成本也会更高。

再来看看 Serverless 的解决方案：

这个方案通过 API Gateway 将不同操作请求触发相应的 Lambda 函数，并使用 DynamoDB 作为数据存储。Lambda 函数即业务逻辑的实现。API Gateway 会自动 scale 去应对流量，同样 Lambda 也会根据流量自动 scale。开发方面，只需要实现 Lambda 函数即可。运维方面，省去了上一个方案中管理密匙、打安全补丁等工作——因为根本没有机器需要去维护。

使用这个方案的成本，同上一个方案一样，会随着公司业务规模的增大而增加。然而不同的是，上一个方案，只要有 EC2 在跑，就需要付钱，不管有没有请求进来。使用 API Gateway 和 Lambda，是按流量和请求量计费的。抛开网络流量和存储来算，100万个请求，API Gateway 目前的收费 3.5 美元。Lambda 则是按照请求量和每个函数的执行时间计费，即使上线第一个月内平均每秒达到 1 个请求（共 60 * 60 * 60 * 24 * 30 = 2592000 个），每个请求运行 10ms，那么 Lambda 的花费也只是 0.57 美元（Lambda 费用计算器）。总体算下来，第一个月大概成本小于 10 美元。

实际成本会更复杂些，需要将许多其他因素考虑在内。小 scale 的、业务简单的 service，Serverless 架构带来的好处很明显，但如果是一个 scale 很大、业务很复杂的 service，就得从成本、可维护性和可控性方面考虑权衡下了。

总结

总体来看，对于一个低流量的 service，使用 Serverless 明显得比非 Serverless 节省开发、部署和运维成本。整个流程少了机器，便少了许多工作量。Serverless 在这方面体现出来的优势，不单单是对刚刚起步的公司成立，对运维着众多每秒请求量不到 1 的 microservices 的大公司也同样适用。

目前 Serverless 处于早期发展阶段，已经有一些公司（Netflix 使用 Lambda 管理基础设施，在线课程网站 A Cloud Guru 整站使用 Lambda 及其他 AWS services 搭建）将这种方案运用到实际的 Production 环境里。简单、低流量的场景目前来看 使用 Serverless 的优势明显。随着这种架构理念的普及推广和云服务提供商生态的完善，Serverless 在更多、更复杂领域的实践值得期待。