Serverless
首发于Serverless

一个简单的 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 在更多、更复杂领域的实践值得期待。

A Serverless Pro
编辑于 2017-06-28

文章被以下专栏收录