亚马逊AWS官方博客

Tag: AWS Lambda

使用AWS Lambda和AWS Step Functions轻松构建Serverless应用

作者: Vivian Zhang(张芸) Serverless(无服务器)应用可以说是当前的行业热点,用户无需预配置或管理服务器,只需要部署功能代码,AWS Lambda会在需要的时候执行代码并自动缩放, 从每天几个请求到每秒数千个请求,轻松地实现FaaS (Function as a Service)。无服务器应用的使用场景非常广阔,从微服务架构,到批处理、流处理、运维自动化和移动计算。 实现Serverless应用,除了AWS Lambda还需要什么? 我们来看一个典型的基于Lambda的无服务器应用。 当我们将作为计算和存储实体的Lambda函数、消息队列、DB去掉,可以看到下面这张图。 这张图上的箭头,就是上一张图里Lambda函数之间的流程,或者可以称为Lambda函数之间的“胶水”,它们起到了编排协调各个Lambda函数的作用。通常在应用中,我们会需要有这样的一些流程: 我想要顺序地执行方法。 我想要并行地运行这些方法。 我想要基于数据选择执行方法。 我想要重试某些方法。 我想要try/catch/finally。 我想要代码运行一定时间或者等待一段时间…… 通常我们可以通过方法调用、函数链、DB和消息队列来协调这些函数,实现流程。但是对于所采用的协调机制,我们都希望它具有以下功能: 可以自动伸缩; 不会丢失状态; 可以处理错误和超时; 可以简单的搭建和运维; 可以审计。 这里我们介绍一种方式,采用AWS Step Functions协调Lambda函数之间的流程。 AWS Step Functions AWS Step Functions是一个可视工作流服务,可用来轻松协调分布式应用程序和微服务的各个组件。用户从单个组件构建应用程序,每个组件都执行一个特定的功能,也就是Task(可以采用Lambda函数实现)。Step Functions提供了一种可靠的方法来协调这些组件并逐步完成应用程序中的这些功能,并且 提供了一个图形控制台,将应用程序的组件可视化为一系列步骤,它可以自动触发并跟踪每一个步骤,并在出现错误时重试,这样应用程序就可以每一次都按照预先设定的顺序执行。Step Functions会记录每一步的状态,因此当事情出错时,用户可以快速地诊断和调试问题。 要使用Step Functions构建应用,首先我们需要在Step Functions里创建State Machine(状态机),也就是对应每一个应用的工作流程。可以采用以下8种蓝图,包括7种预定义好的状态机和1种自定义的。创建好的状态机用JSON描述。 在每一个状态机里,我们需要定义一系列的State(状态),用来完成不同的功能: Task:在状态机中完成特定的功能,可以采用Lambda函数实现。 Choice:在各种执行分支中进行选择。 Fail和Success:停止一个执行,并设为Fail或者Success。 Pass:简单地将输入传给输出,或者注入一些数据。 Wait:提供一定时间的延迟,或者等待到特定的时间/数据。 Parallel:并行地执行分支。 可以看出,上一节中我们所需要的协调和流程在这些状态中都得到了支持。其中的Task状态是用来真正实现应用的功能,而其他状态用来处理功能之间的流程。比如说,下面是一个名为HelloWorld,执行Lambda函数的状态。 下图是一个拥有所有状态的状态机: 在Console里看到一个创建好的状态机是这样: 我们点击New Execution并且传入input数据,就可以启动该状态机的一次执行,并且可以从界面上查看执行的情况。 […]

Read More

新工具 – AWS SAM Local (Beta 版) – 在本地构建和测试无服务器应用程序

今天,我们将发布一款新工具 — SAM Local (Beta 版)。使用这款工具,您可以轻松在本地构建和测试无服务器应用程序。在本文中,我们将使用 SAM Local 快速构建、调试并部署一款应用程序,该应用程序允许我们通过对终端节点运行 curl 命令给 Tabs 或 Spaces 投票。AWS 去年推出了无服务器应用程序模式 (SAM),让开发人员能够更轻松地部署无服务器应用程序。如果您还不熟悉 SAM,请阅读我的同事 Orr 发布的一篇优秀文章,其中详细介绍了如何使用 SAM,读完该文章大约需要 5 分钟。SAM 的核心是基于 AWS CloudFormation 的强大开源规范,它可轻松将您的无服务器基础设施保持为代码并提供可爱的标识。 SAM Local 吸收了 SAM 的全部精华并将它们应用到您的本地计算机中。 它允许您使用以下命令和工具在本地开发并测试 AWS Lambda 函数: sam local 和 Docker。 它允许您模拟从已知事件源 (如 Amazon Simple Storage Service (S3)、Amazon DynamoDB、Amazon Kinesis、Amazon Simple Notification Service (SNS) 等) 进行的函数调用。 […]

Read More

AWS Marketplace 中的 Box 平台 – Lambda 蓝图和示例代码

Box 是一个基于云的文件共享和内容管理系统,具有一个最近已在 AWS Marketplace 中提供的 API (Box 平台 – 云内容管理 API)。凭借一系列协作相关功能的推出,以及对安全性的重视,Box 已经在许多企业中得到了广泛应用 (请参见其成功案例页面中的列表)。 Box API 允许开发人员将内容体验构建到 Web 和移动应用程序中。今天我想向您介绍一些 [lambda] 蓝图和模板,这些蓝图和模板将可以帮助您在构建 AWS 应用程序时使用此 API 来简化用户身份验证和将元数据添加到新上传的内容中。这些模板基于 Box 节点 Lambda 示例而创建,可作为您开发工作的一个强大起点。我们来看一看这些蓝图,顺便查看一些我们在 Box 的好友所撰写的博客文章。 适用于 Lambda 的 Box 蓝图 蓝图显示了您如何通过 [apigateway] 调用 Box API 和将 Box webhook 连接到 Lambda 函数。要找到它们,请直接打开 Lambda 控制台,搜索 box: 第一个蓝图使用存储在 BOX_CONFIG 环境变量中的安全凭证。您可以从 Lambda 控制台内设置此变量: 此蓝图中的代码会检索并记录通过凭证确定的用户的 […]

Read More

利用Kong及AWS Lambda构建无服务器的后端逻辑

Kong是一个开源的API GW及微服务管理层,基于Nginx, Cassandra或者PostgreSQL构建,最初由Mashape开发,用于为其API Marketplace管理超过15,000个API和微服务,并于2015年开源。Kong具有如下优点: 可扩展性:通过简单地添加更多的机器,Kong可以轻松地水平缩放,这意味着您的平台可以处理几乎任何负载,同时保持低延迟。 模块化:可以通过添加新的插件来扩展,并通过RESTful Admin API轻松配置所有插件。 平台无关性:Kong可以运行在任何地方,包括本地数据中心及公有云,支持物理机,虚机及容器部署。 目前Kong的最新版本为0.10.2,支持的插件如下: 认证:Basic Authentication, Key Authentication, OAuth2.0 Authentication, OAuth 2.0 Introspection, HMAC Authentication, JWT, LDAP Authentication 安全:ACL, CORS, Dynamic SSL, IP Restriction, Bot Detection 流控:Rate Limiting, Response Rate Limiting, Request Size Limiting 无服务器架构:AWS Lambda, OpenWhisk 分析监控:Galileo, Datadog, Runscope 内容转换:Request Transformer, Response Transformer, Correlation ID 日志:TCP/UDP/HTTP Logging, File […]

Read More

Lambda@Edge – 在边缘智能地处理 HTTP 请求

去年年底,我宣布推出预览版 Lambda@Edge,并谈论了如何使用它在靠近客户的位置 (低延迟) 智能地处理 HTTP 请求。申请并获得预览版访问权的开发人员一直在很好地使用它,并为我们提供了大量非常有用的反馈意见。在预览期间,我们添加了生成 HTTP 响应和支持 CloudWatch Logs 的功能,并根据反馈意见更新了路线图。 现已正式发布 今天我很高兴地宣布 Lambda@Edge 现已正式发布!您可以使用它来: 检查 Cookie 并重写 URL 以执行 A/B 测试。 根据 User-Agent 标头将特定对象发送给用户。 通过在将请求传递到源之前查找特定标头来实现访问控制。 添加、删除或修改标头以将用户指引到不同的缓存对象。 生成新的 HTTP 响应。 干净利落地支持旧 URL。 修改或缩减标头或 URL 以提高缓存利用率。 向其他 Internet 资源发出 HTTP 请求,并使用结果自定义响应。 Lambda@Edge 允许您创建基于 Web 的丰富且个性化的用户体验。由于它正迅速成为当今世界的常态,因此您不需要配置或管理任何服务器。您可以直接上传代码 (在Node.js 中编写的 Lambda 函数),并选择您为分发版创建的其中一个 CloudFront 行为以及所需的 CloudFront 事件: 在本例中,我的函数 (假设名为 EdgeFunc1) […]

Read More

AWS Lambda 对 AWS X-Ray 的支持

今天,我们宣布全面推出 AWS Lambda 对 AWS X-Ray 的支持。您可能已经从 Jeff 的 GA 文章中了解到,X-Ray 是 AWS 推出的一项服务,用于分析分布式应用程序的执行和性能行为。传统调试方法对于基于微服务的应用程序效果不佳,在这些应用程序中,有多个独立的组件在不同的服务上运行。利用 X-Ray,您可以通过对应用程序中的延迟进行细分,来快速诊断错误、速度下降和超时问题。稍后我将详细介绍如何构建和分析一个基于 Lambda 的简单应用程序,以演示您如何能够在自己的应用程序中使用 X-Ray。如果您想立即开始使用,可以通过导航到现有 Lambda 函数的配置页面并启用跟踪,来轻松地为函数启用 X-Ray: 或者在 AWS 命令行界面 (CLI) 中更新函数的 tracing-config (请务必同时传入 –function-name ): $ aws lambda update-function-configuration –tracing-config ‘{“Mode”: “Active”}’ 如果激活跟踪模式,Lambda 将尝试跟踪您的函数 (除非上游服务明确说明不跟踪)。如果不激活跟踪模式,仅当上游服务明确说明需要跟踪时,才跟踪您的函数。一旦启用跟踪,您将开始生成跟踪,并将获得应用程序中资源的可视化表示形式以及它们之间的联系 (边缘)。需要注意的一点是,X-Ray 守护进程会占用 Lambda 函数的一些资源。如果您已接近内存限制,Lambda 将尝试终止 X-Ray 守护程序,以免引发内存不足错误。 下面让我们通过快速构建一个使用几种不同服务的应用程序来测试这种新的集成。 作为一个二十多岁且拥有智能手机的年轻人,我有大量 图片 自拍照 (一万多张!),我想如果能够分析所有这些照片,那就太棒了。我们将使用 Java 8 运行时编写一个简单的 […]

Read More

AWS Greengrass – 在互连设备上运行 AWS Lambda 函数

在 re:Invent 大会期间发布的文章 (AWS Greengrass – 无处不在的现实世界计算) 中,我首次介绍了 AWS Greengrass。当时我们推出了 AWS Greengrass 的有限预览版,并邀请您注册。 正如我当时指出的那样,许多 AWS 客户希望在现场收集和处理数据,而现场的网络连接通常很慢,有时还时断时续,并不可靠。利用 Greengrass,他们可以在基于现场的小型简单设备上应用 AWS 编程模型。它建立在 AWS IoT 和 AWS Lambda 的基础上,支持访问 AWS Cloud 中不断增加的各种服务。 利用 Greengrass,您可以访问在现场运行的计算、消息收发、数据缓存和同步服务,这些服务并不依赖与 AWS 区域的稳定高带宽连接。您可以在 Python 2.7 中编写 Lambda 函数,并将其从云部署到 Greengrass 设备,同时使用 Device Shadows 来维护状态。您的设备和外设可以使用本地消息收发互相通信,后者并不通过云进行传递。 现已公开发布 今天我们将在US East (Northern Virginia) 和 US West (Oregon) 区域公开发布 Greengrass。在预览版本中,AWS 客户已成功获得 Greengrass […]

Read More

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

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 […]

Read More

使用AWS Lambda和Amazon DynamoDB自动管理AWS CloudFormation模板中的Parameters和Mappings

背景介绍 相信AWS的用户对AWS CloudFormation都不会陌生。AWS CloudFormation是实现IAC(Infrastructure as Code)自动化运维的一项重要服务,可以帮助用户对 AWS资源进行建模和设置,以便能花较少的时间管理这些资源。CloudFormation中有两个重要选项:Mappings段和Parameters段,可以帮助用户组织模板里的参数和映射,让用户更好地自定义堆栈,以实现模板的重用和复用。比方说可以用Mappings管理对应AWS上不同region的AMI ID,或者管理企业内部的不同部门。 但是当用户所在的组织越来越多地采用IAC自动化时,mappings和parameters的数量也会急剧增长,给CloudFormation模板的编写和维护带来复杂度。 解决方案 本文里我们介绍一种方法:用当前流行的Serverless计算AWS Lambda 和Amazon DynamoDB自动地管理AWS CloudFormation模板中的Parameters和Mappings。 本文中主要用到了以下几种 AWS服务: 1、DynamoDB表:Amazon DynamoDB是一个NoSQL数据库,这里我们采用它保存CloudFormation模板中所有的mappings和parameters。不仅可以实现集中存放,而且可以依赖DynamoDB的接口实现方便快速地增删和查找。比方说在我们的sample code中,整个企业采用这样一张表:partition key包括组名(比如说team1、team2等)和环境(比如说development、test、production等),sort key保存应用的名字。这个表里的数据类似这样: 当我们把这些数据都insert到DynamoDB中后,可以在AWS console里看到表中的内容是这样的: 2、Lambda方法:AWS Lambda又称为Serverless的计算,通过它你可以运行你的code而不需要预配置或者管理任何服务器。这里我们采用Lambda方法实现CloudFormation和DynamoDB之间的关联,它从CloudFormation模板接收primary key和sort key作为输入,查找DynamoDB表,并且返回所有的key-value数据。 3、Custom lookup resource:这是CloudFormation里的一个自定义资源,与一个Lambda方法绑定。CloudFormation除了可以定义已有的AWS资源,还支持几种自定义资源,包括这种以Lambda方法作为后端的自定义资源。当这种自定义资源创建、更新或者删除时,CloudFormation自动地向Lambda API发起请求,引发方法并将请求的数据传给Lambda方法,本例中所请求的数据是primary key,返回的数据是key-value数据。通常在一个组织中只需要建立这一个custom resource,所有的CloudFormation模板都可以复用它。下图是sample code里建立的custom resource: 让我们将这几种服务组合起来,并且定义好它们之间的交互顺序,整个解决方案就是下图展示的这样: 那么整个的交互顺序如下: 1、用户创建DynamoDB表,插入所需的mappings和parameters数据。 2、CloudFormation模板中的custom resource调用Lambda方法,用组名和环境名称(“teamname-environment”)作为partition key,用应用名称(”appname”)作为sort key。 3、Lambda方法用partition key和sort key作为输入查询DynamoDB表。 4、DyanamoDB将结果返回给Lambda方法。 5、Lambda方法将这些key-value数据作为结果返回给模板中的custom resource。 6、custom resource拿到数据后,堆栈里的其他资源可以通过Fn::GetAtt的方式获得这些数据。 结论 通过这种方式,可以将我们创建堆栈所需的固定部分保存在模板中,而将可变部分mappings和parameters保存在方便增删改查的DynamoDB中,用Lambda实现两者之间的关联。对于大型组织来说,这样可以提高运维效率,也是使用CloudFormation的一种最佳实践。 参考 可以在我们的网站上下载到相关的sample […]

Read More

带您玩转Lambda,轻松构建Serverless后台!

Amazon CTO Werner Vogels曾经在AWS re:Invent大会上提到: 如果把云计算理解成一个执行环境,那么,在这个环境里,函数(即业务逻辑的载体)+数据(即跟业务相关的输入与输出)就是应用的核心,有了Functions、Data、Event这三者,其它任何代码和框架,无非是整个应用的胶水和UI罢了。那么,最理想的情况就是用最少的时间写胶水,将更多的时间投入到核心应用的开发中,甚至,彻底实现整个软件栈的微服务化。 那么能不能做到呢?答案是肯定的。AWS Lambda也在这样的背景下应运而生了,其实在很多人眼里,Lambda是一个具有“革命性”的服务,我本人也非常喜欢Lambda这个服务,因为它给我的感觉是: 轻、快、高可用!能够快速将想法写成代码,并应用到生产,不需要关心底层基础设施的运维。接下来,让我们一起搭建一个serverless的后台! 【1】AWS Lambda怎么用? 怎么学习Lambda呢?让我们从一个简单的数学问题开始,10以内乘法和加法运算,获得随机的一个数字。代码有注释,如下: //Node.js尽量全使用严格模式 ‘use strict’; //利用console.log可以将日志自动打到CloudWatch里面 console.log(‘Loading function’); exports.handler = (event, context, callback) => {     //定义一个最小值为2     var min = 2;     //定义一个最大值为10     var max = 10;     //生成一个随机数,乘以最大值,再加上一个最小值     var generatedNumber = Math.floor(Math.random() * max) + min;     //利用callback回调,得到结果。     callback(null, generatedNumber); […]

Read More