智能时代的新技术实战
上QQ阅读APP看本书，新人免费读10天
设备和账号都新为新人
上一章目录下一章

深入Serverless—让Lambda和API Gateway支持二进制数据

by AWS Team

1．概述

Serverless即无服务器架构正在迅速举起，AWS Lambda和AWS API Gateway作为Serverless架构主要的服务，正受到广泛关注，也有越来越多用户使用它们，享受其带来的便利。传统上来说，Lambda和API Gateway主要用以实现RESTful接口，其响应输出结果是JSON数据，而实际业务场景还有需要输出二进制数据流的情况，比如输出图片内容。本文以触发式图片处理服务为例，深入挖掘Lambda和API Gateway的最新功能，让它们支持二进制数据，展示无服务器架构更全面的服务能力。

先看一个经典架构的案例——响应式主动图片处理服务。

Lambda配合S3文件上传事件触发在后台进行图片处理，比如生成缩略图，然后再上传到S3，这是Lambda用于事件触发的一个经典场景。

http://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html

在实际生产环境中这套架构还有一些局限，比如：

· 后台运行的图片处理可能无法保证及时完成，用户上传完原图后需要立即查看缩略图时还没有生成。

· 很多图片都是刚上传后使用频繁，一段时间以后就使用很少了，但是缩略图还不能删，因为也可能有少量使用，比如查看历史订单时。

· 客户端设备类型繁多，一次性生成所有尺寸的缩略图，会消耗较多Lambda运算时间和S3存储。

· 如果增加了新的尺寸类型，旧图片要再生成新的缩略图就比较麻烦了。

我们使用用户触发的架构来实现实时图片处理服务，即当用户请求某个缩略图时实时生成该尺寸的缩略图，然后通过CloudFront缓存在CDN上。这其实还是事件触发执行Lambda，只是由文件上传的事件主动触发，变成了用户访问的被动触发。但是只有原图存储在S3，任何尺寸的缩图都不生成文件不存储到S3。要实现此架构方案，核心技术点就是让Lambda和API Gateway可以响应输出二进制的图片数据流。

总体架构图如下：

主要技术点：

· 涉及服务都是AWS完全托管的，自动扩容，无需运维，尤其是Lambda，按运算时间付费，省去EC2部署的繁琐。

· 原图存在S3上，只开放给Lambda的读取权限，禁止其它人访问原图，保护原图数据安全。

· Lambda实时生成缩略图，尽管Lambda目前还不支持直接输出二进制数据，我们可以设置让它输出base64编码后的文本，并且不再使用JSON结构。配合API Gateway可以把base64编码后的文本再转换回二进制数据，最终就可以实现输出二进制数据流了。

· 用API Gateway实现图片访问的URL。我们常见的API Gateway用来做RESTful的API接口，接口的URL形式通常是/resource? parameter=value，其实还可以配置成不用GET参数，而把URL中的路径部分作参数映射成后端的参数。

· 回源API Gateway，缓存时间可以用户自定义，建议为24小时。直接支持HTTPS，支持享用AWS全球边缘节点。

· CloudFront上还可使用Route 53配置域名，支持用户自己的域名。

相比前述的主动生成，被动触发生成有以下便利或优势：

· 缩略图都不存储在S3上，节省存储空间和成本。

· 方便给旧图增加新尺寸的缩略图。

2．部署与配置

本例中使用的Region是Oregon(us-west-2)，有关文件从以下链接下载：

https://s3.amazonaws.com/snowpeak-share/lambda/awslogo.png

2.1 使用IAM设置权限

打开控制台：

https://console.aws.amazon.com/iam/home? region=us-west-2

创建一个Policy，名叫CloudWatchLogsWrite，用于确保Lambda运行的日志可以写到CloudWatch Logs。内容是

    {
    "Version":
    "2012-10-17",
    "Statement": [
    {
    "Effect":
    "Allow",
    "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents",
    "logs:DescribeLogStreams"
    ],
    "Resource": [
    "arn:aws:logs:*:*:*"
    ]
    }
    ]
    }

创建一个Role，名叫LambdaReadS3，用于Lambda访问S3。Attach Poilcy选AmazonS3ReadOnlyAccess和刚刚创建的CloudWatchLogsWrite。

记下它的ARN，比如arn:aws:iam::111122223333:role/LambdaReadS3

2.2 使用S3配置原图存储

打开控制台

https://console.aws.amazon.com/s3/home? region=us-west-2

创建Bucket, Bucket Name需要填写全局唯一的，比如img201703, Region选US Standard。通常图片的原图禁止直接访问，这里我们设置权限，仅允许Lambda访问。

Permissions下点Add bucket policy，使用AWS Policy Generator：

Select Type of Policy选S3 bucket policy，

Principal填写前述创建的LambdaReadS3的ARN

，

Actions下拉选中GetObjext，

Amazon Resource Name(ARN)填写刚刚创建的bucket的ARN，比如

然后点Add Statement，最后再点Generate Policy，生成类似

    {
    "Id": "Policy1411122223333",
    "Version":
    "2012-10-17",
    "Statement": [
    {
    "Sid": "Stmt1411122223333",
    "Action": [
    "s3:GetObject"
    ],
    "Effect":
    "Allow",
    "Resource":
    "arn:aws:s3:::img201703/*",
    "Principal": {
    "AWS": [
    "arn:aws:iam::111122223333:role/LambdaReadS3"
    ]
    }
    }
    ]
    }

复制粘贴到Bucket Policy Editor里save即可。

验证S3 bucket配置效果。把前下载图片文件awslogo.png下载到自己电脑，然后把它上传到这个bucket里，测试一下。直接访问链接不能下载，需要右键菜单点“Download”才能下载，说明权限配置已经成功。

2.3 创建Lambda函数

AWS Lambda管理控制台：

https://us-west-2.console.aws.amazon.com/lambda/home? region=us-west-2#/

点击Create a Lambda function按钮

Select runtime菜单选Node.js 4.3，然后点Blank Function。

Configure triggers页，点Next。

Configure function页，在Name栏输入ImageMagick, Description栏输入

Uses ImageMagick to perform simple image processing operations, such as resizing.

Lambda function code里填写以下代码：

    'use strict';

    var AWS = require('aws-sdk');
    const im = require('imagemagick');
    const fs = require('fs');

    const defaultFilePath = 'awslogo_w300.png';
    // 样式名配置，把宽高尺寸组合定义成样式名。
    const config = {
    'w500':{'width':500,
    'height':300},
    'w300':{'width':300,
    'height':150},
    'w50':{'width':50,
    'height':40}
    };
    // 默认样式名
    const defaultStyle = 'w50';
    // 完成处理后把临时文件删除的方法。
    const postProcessResource = (resource, fn) => {

    let ret=null;
    if (resource) {
    if (fn) {
    ret = fn(resource);
    }
    try {

    fs.unlinkSync(resource);
    } catch (err) {
    // Ignore
    }
    }
    return ret;
    };
    // 生成缩略图的主方法
    const resize = (filePathResize, style, data, callback) => {
    // Lambda 本地写文件，必须是 /tmp/ 下
    var filePathResize =
    '/tmp/'+filePathResize;
    // 直接用 Buffer 操作图片转换，源文件不写到本地磁盘，但是转换成的文件要写盘，所以最后
    再用 postProcessResource 把临时文件删了。
    var resizeReq = {
    srcData: data.Body,
    dstPath: filePathResize,
    width: style.width,
    height: style.height
    };
    try {
    im.resize(resizeReq,
    (err) => {
    if (err) {
    throw err;
    } else {

    console.log('Resize ok: '+ filePathResize);
    // 注意这里不使用JSON结构，直接输出图片内容数据，并且要进行base64转码。
    callback(null,
    postProcessResource(filePathResize, (file) => new
    Buffer(fs.readFileSync(file)).toString('base64')));
    }
    });
    } catch (err) {
    console.log('Resize
    operation failed:', err);
    callback(err);
    }
    };

    exports.handler = (event, context, callback) => {
    var s3 = new AWS.S3();
    //改成刚刚创建的 bucket 名字，如 img201703
    var bucketName = 'image201702';
    // 从文件 URI 中截取出 S3 上的 key 和尺寸信息。
    // 稳妥起见，尺寸信息应该规定成样式名字，而不是直接把宽高参数化，因为后者会被人滥用。
    // 使用样式还有个好处，样式名字如果写错，可以有个默认的样式。
    var filepath = (undefined ===
    event.filepath ? defaultFilePath:event.filepath);
    var tmp =
    filepath.split('.');
    var fileExt = tmp[1];
    tmp = tmp[0].split('_');
    var fileName = tmp[0];
    var style = tmp.pop();
    console.log(style);
    var validStyle = false;
    for (var i in config)
    {
    if (style == i)
    {
    validStyle = true;
    break;

    }
    }
    style = validStyle ? style :
    defaultStyle;
    console.log(style);
    var fileKey =
    fileName+'.'+fileExt;
    var params = {Bucket:
    bucketName, Key: fileKey};

    // 从 S3 下载文件，成功后再回调缩图
    s3.getObject(params,
    function(err, data) {
    if (err)
    {
    console.log(err,
    err.stack);
    }
    else
    {
    resize(filepath,
    config[style], data, callback);
    }
    });
    };

注意一定要把

varbucketN am e=‘im age201702';

改成刚刚创建的bucket名字，如

varbucketN am e=‘im g201703';

这个Lambda函数就可以运行了。

Lambda function handler and role部分的Role选择Choose an existing role，然后Existing role选择之前创建的LambdaReadS3。

Advanced settings:Memory(MB)*选512, Timeout选30 sec。

其它保持默认，点Next；最后一页确认一下，点Create Function。

提示创建成功。

点击Test按钮，测试一下。第一次测试时，会弹出测试使用的参数值，这些参数其实我们都不用，也不用管它，点击Save and test按钮测试即可。以后再测试就不会弹出了。显示“Execution result: succeeded”表示测试成功了，右边的Logs链接可以点击，前往CloudWatch Logs，查看详细日志。右下方的Log output是当前测试执行的输出。

可以看到这里Execution result下面显示的结果是一个长字符串，已经不是我们以往普通Lambda函数返回的JSON结构了。想做进一步验证的，可以把这个长字符串base64解码，会看到一个尺寸变小的图片，那样可以进一步验证我们运行成功。

2.4 配置API Gateway

管理控制台

https://us-west-2.console.aws.amazon.com/apigateway/home? region=us-west-2#

2.4.1 配置

点击Create API

API name填写ImageMagick。

Description填写Endpoint for Lambda using ImageMagick to perform simple image processing operations, such as resizing.

这时左侧导航链接会显示成APIs>ImageMagick>Resources。点击Actions下拉菜单，选择Create Resource。

Resource Name* 填写filepath

Resource Path* 填写{filepath}，注意要包括大括号。然后点击Create Resource按钮。

这时刚刚创建的{filepath}应该是选中状态，再点击Actions下拉菜单，选择Create Method，在当时出现的方法菜单里选择GET，然后点后面的对号符确定。

然后在/{filepath} - GET - Setup页，Integration type保持Lambda Function不变，

Lambda Region选us-west-2，在Lambda Function格输入ImageMagick，下拉的备选菜单中点中ImageMagick，点击Save。弹出赋权限提示，点击“OK”。

这时会显示出完整的“/{filepath} - GET - Method Execution”配置页。

点击右上角“Integration Request”链接，进入配置页，点击“Body Mapping Templates”左边的三角形展开之。

Request body passthrough选择When there are no templates defined(recommended)。

点击最下面“add mapping template”链接，“Content-Type”格，注意即使这里已经有提示文字application/json，还是要自己输入application/json，然后点击右边的对勾链接，下面会弹出模板编辑输入框，输入

{“filepath”：“$input.params(‘filepath')”}

完成的效果如下图所示：

最后点击“Save”按钮。点击左上角“Method Execution”链接返回。

点击左下角“Method Response”链接，HTTP Status下点击第一行200左边的三角形展开之，“Response Headers for 200”下点击add header链接，Name格输入Content-Type，点击右边的对勾链接保存。Response Body for 200下已有一行application/json，点击其右边的笔图标编辑，把值改成image/png，点击右边的对勾链接保存。点击左上角“Method Execution”链接返回。

点击右下角“Integration Response”链接，点击第一行“-200 Yes”左边的三角形展开之，“Content handling”选择Convert to binary(if needed)，然后点击“Save”按钮。这项配置是把Lambda返回的base64编码的图片数据转换成二进制的图片数据，是此架构的另一个技术重点。

Header Mappings下已有一行Content-Type，点击其右边的笔图标编辑，在“Mapping value”格输入’image/png'，注意要带上单引号，点击右边的对勾链接保存。

点击“Body Mapping Templates”左边三角形展开之，点击“application/json”右边的减号符，把它删除掉。点击左上角“Method Execution”链接返回。

点击最左边的竖条Test链接，来到“/{filepath}-GET-Method Test”页，“{filepath}”格输入awslogo_w300.png，点击Test按钮。右侧显示类似下面的结果

Request:/awslogo_w300.png

Status:200

Latency:247 ms

Response Body是乱码是正常的，因为我们的返回内容就是图片文件本身。可以查看右下角Logs部分显示的详细执行情况，显示类似以下的日志表示执行成功。

Thu Mar 09 03:40:11 UTC 2017: Method response body<br/>after transformations: [Binary Data]

Thu Mar 09 03:40:11 UTC 2017: Method response<br/>headers:

{X-Amzn-Trace-Id=Root=1-12345678-1234567890abcdefghijlkln, <br/>

Content-Type=image/png}

Thu Mar 09 03:40:11 UTC 2017: Successfully completed<br/>execution

Thu Mar 09 03:40:11 UTC 2017: Method completed with<br/>status:200

2.4.2 部署API

点击Actions按钮，在下拉菜单中点选Deploy API, Deployment stage选择[New Stage], Stage name输入test，注意这里都是小写。

Stage description输入test stage

Deployment description输入initial deploy to test.

点击Deploy按钮。然后会跳转到Test Stage Editor页。

复制Invoke URL：后面的链接，比如

https://1234567890.execute-api.us-west-2.amazonaws.com/test

然后在后面接上awslogo_w300.png，组成形如以下的链接

https://1234567890.execute-api.us-west-2.amazonaws.com/test/awslogo_w300.png

输入浏览器地址栏里访问，可以得到一张图片，表示API Gateway已经配置成功。

2.5 配置CloudFront分发

我们在API Gateway前再加上CloudFront，通过CDN缓存生成好的图片，就可以实现不需要把缩略图额外存储，而又不用每次都为了图片处理进行计算。这里使用了CDN和其它使用CDN的思路一样，如果更新图片，不建议调用清除CloudFront的API，而是从应用程序生成新的图片标识字符串，从而生成新的URL让CloudFront成为无缓存状态从而回源重新计算。

由于API Gateway仅支持HTTPS访问，而CloudFront同时支持HTTP和HTTPS，所以我们可以配置成CloudFront前端同时支持HTTP和HTTPS，但是实测发现CloudFront前端使用HTTP而回源使用HTTPS时性能不如前端和回源同为HTTPS。所以这里我们也采用同时HTTPS的方式。

我们打开CloudFront的管理控制台

https://console.aws.amazon.com/cloudfront/home? region=us-west-2#

点击Create Distribution按钮，在Web下点击Get Started。

Origin Domain Name，输入上述部署出来的API Gateway的域名，比如

1234567890.execute-api.us-west-2.amazonaws.com

Origin Path，输入上述API Gateway的Stage名，如/test

Origin Protocol Policy选择HTTPS Only

Object Caching点选Customize，然后Maximum TTL输入86400

Alternate Domain Names(CNAMEs)栏本例使用自己的域名，比如img.myexample.com。SSL Certificate选择Custom SSL Certificate(example.com)，并从下面的证书菜单中选择一个已经通过ACM管理的证书。

注意，如果填写了自己的域名，那么下面的SSL Certificate就不建议使用默认的Default CloudFront Certificate(*.cloudfront.net)，因为很多浏览器和客户端会发现证书的域名和图片CDN的域名不一致会报警告。

其它项保持默认，点击Create Distribution按钮，然后回到CloudFront Distributions列表，

这里刚刚创建的记录Status会显示为In Progress，我们点击ID的链接，前进到详情页，

可以看到Domain Name显示一个CloudFront分发的URL，比如cloudfronttest.cloudfront.net。大约10多分钟后，等待Distribution Status变成Deployed，我们可以用上述域名来测试

一下。注意测试用的URL不要包含API Gateway的Stage名，比如

https://1234567890.execute-api.us-west-2.amazonaws.com/test/awslogo_w300.png

那么CloudFront的URL应该是

https://cloudfronttest.cloudfront.net/awslogo_w300.png

尽管我们已经配置了自己的域名，但是这时自已的域名还未生效。我们还需要到Route 53去添加域名解析。

2.6 Route 53

最后我们使用Route 53实现自定义域名关联CloudFront分发。访问Route 53管制台

https://console.aws.amazon.com/route53/home? region=us-west-2

在Hosted Zone下点击一个域名，在域名列表页，点击上方Create Record Set按钮，页面右侧会弹出创建记录集的面板。

Name栏输入img。

Type保持默认A-IP4 Address不变。

Alias点选Yes，在Alias Target输入前述创建的CloudFront分发的URL cloudfronttest.cloudfront.net。

点击右下角Create按钮完成创建。

3．效果验证

现在我们回到CloudFront控制台，等到我们的Distribution的Status变成Deployed，先用CloudFront自身的域名访问一下。

https://cloudfronttest.cloudfront.net/awslogo_w300.png

顺利的话，会看到咱们的范例图片。再以自定义域名访问一下。

http://img.myexample.com/awslogo_w300.png

还是输出这张图片，那么到此就全部部署成功了。现在可以在S3的bucket里上传更多其它图片，比如abc.png，然后访问时使用的URL就是

http://img.myexample.com/abc_w300.png

用浏览器打开调试工具，可以看到响应头里已经有

    X-Cache: Hit from cloudfront

表示已经经过CloudFront缓存。

4．监控

这个架构方案使用的服务都可以通过CloudTrail记录管理行为，使用CloudWatch记录用户访问情况。

4.1 Lambda监控

在Lambda控制台点击我们的ImageMagick函数，然后点击选项卡最末一个Monitoring，可以看到常用指标的简易图表。

点击任何一个图表，都可以前进到CloudWatch相关指标的指标详细页。然后我们还可以为各个指标配置相关的CloudWatch Alarm，用以监控和报警。

点击View logs in CloudWatch链接，可以前往CloudWatch Log，这里记录了这个Lambda函数每次执行的详细信息，包括我们的函数中自已输出的调试信息，方便我们排查问题。

4.2 API Gateway监控

在API Gateway控制台找到我们的API ImageMagick，点击它下面的Dashboard。

如果部署了多个Stage，注意左上角Stage菜单要选择相应的Stage。同样下面展示的是常用图表，点击每个图表也可以前往CloudWatch显示指标监控详情。

4.3 CloudFront日志

我们刚刚配置CloudFront时没有启用日志。如果需要日志，可以来到CloudFront控制台，点击我们刚刚创建的分发，在General选项页点击Edit按钮。在Edit Distribution页找到Logging项，选择On，然后再填写Bucket for Logs和Log Prefix，这样CloudFront的访问日志就会以文件形式存储在相应的S3的bucket里了。

5．小结

我们这样一个例子使用了Lambda和API Gateway的一些高级功能，并串联了一系列AWS全托管的服务，演示了一个无服务器架构的典型场景。虽然实现的功能比较简单，但是Lambda函数可以继续扩展，提供更丰富功能，比如截图、增加水印、定制文本等，几乎满足任何的业务需求。相比传统的的计算能力部署，不论是用EC2还是ECS容器，都要自己管理扩容，而使用Lambda无需管理扩容，只管运行代码。能够让我们从繁琐的重复工作中解脱，而把业务集中到业务开发上，这正是无服务器架构的真正理念和优势。

作者介绍：

薛峰

AWS解决方案架构师，AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内和全球的应用和推广，在大规模并发应用架构、移动应用以及无服务器架构等方面有丰富的实践经验。在加入AWS之前曾长期从事互联网应用开发，先后在新浪、唯品会等公司担任架构师、技术总监等职位。对跨平台多终端的互联网应用架构和方案有深入的研究。

上一章目录下一章