利用 Lambda 与 DynamoDB Streams 构建动态仪表板：第一部分

我们为什么需要强调仪表板的动态属性？

想象一下，如果在驾车行驶的时候没有时速表可查、烹饪的时候发现温度计总处在同一指数上、或者面对着总是被设定在同一时间点的闹钟，我们的生活显然无法正常推进。作为一种正常需求，我们当然希望能够根据日常生活中的具体状况实时反馈给上述工具，同样的道理也应该适用于密切监督我们应用程序的仪表板方案。

今天，借助来自 Amazon Web Serivces 的一系列新工具，我将引导大家了解如何将原本枯燥的静态仪表板带入实时化新时代。

DynamoDB Streams 与 Lambda

大家可能听说过 Amazon DynameDB，这是一项速度出众的 NoSQL 数据库服务。不久之后，我们还将迎来一项名为 DynamoDB Streams 的全新功能，并享受由此带来的出色特性。DynamoDB Streams 能够对任意 DynamoDB 表中的项目依时间顺序进行排列调整。

AWS Lambda 则是一项计算服务，能够在事件响应中运行各位的代码、并以自动化方式帮助我们管理计算资源。Lambda 的出色之处在于，作为开发人员、大家无需启动任何计算实例来处理这部分代码——Lambda 能够自动以规模化状态运行并打理相关计算容量，从而保证成千上万项功能得以并行运作，且性能表现在事件触发频率产生变化时仍能始终保持恒定。

由于 DynamoDB Streams 与 Lambda 目前都还处于预览阶段，因此在今天的第一部分文章中，我们仅仅从该应用程序的运作角度作出概览，同时提供整个执行流程中所涉及的一部分简单代码片段。当 DynamoDB Streams 与 Lambda 真正推出通用版本后，我将发布本文的第二部分，并在其中纳入更多细节信息、帮助大家了解如何将其引入自己的运作体系。

与此同时，我强烈建议大家首先对 Streams 与 Lambda 的预览版本进行体验。如果大家之前已经使用过 Streams 与 Lambda，并愿意帮助我们在第二部分文章内完善指导内容，请在评论栏中分享您的真知灼见。

• 大家可以点击以下链接申请体验 DynamoDB Streams：
  https://aws.amazon.com/dynamodb/preview/
• 大家可以点击以下链接申请体验 Lambda：
  http://aws.amazon.com/lambda/preview/

仪表板

在本演示中，我已经以一套虚构场景为基础构建起一款简单的应用程序。在该场景中，大家可以选择自己最喜爱的颜色，并将支持结果发文字选票方式发送至由 Twilio 友人们提供的电话号码处。一台运行有 Node.js 的 Amazon EC2 服务器负责接收这些票选结果，并将其列入一套 DynamoDB 表中。当 Lambda 发现表内容出现变化时，其将对数据文件内的 JSON 值作出更新，并由我们的仪表板以动态方式生成新的图表。

虽然整个过程非常简单——大家只需要为单一一种颜色投票，最终结果也会以饼状图方式显示——但我们仍然能够借此熟悉本文所探讨的这两套技术方案，并了解如何构建出适合自己特殊需要的定制化仪表板方案。

欲查看本项目的最终版本，请访问 http://voteapp.s3-website-us-east-1.amazonaws.com/ 。大家可以通过向 1-512-337-1954 号码发送“RED”、“BLUE”或者“GREEN”的方式查看仪表板对于投票内容的反应。

Twilio

作为第一步，我首先在 Twilio 上创建了一个免费账户，并从其提供的备选池中选择一个数字。如果大家也愿意，也可以采取同样的办法——而且事实上，在本文的第二部分中、相关内容将要求大家拥有 Twilio 账户，因此提早注册会让您的学习之路更加顺畅。

用于 Twilio 响应之 EC2 服务器

我需要一台 EC2 服务器负责解析来自用户的短信消息。Twilio 提供必要通道，保证全部短信消息都能由用户处被传输至该服务器端。

在启动这套实例之前，我为其创建了一个角色。角色的存在保证了该实例能够在无需明确通过访问密钥或者接受代码库验证的方式访问 DynamoDB 等 AWS 资源。大家可能会发现，这种角色机制确实非常便捷，在它的帮助下我们不再需要将验证信息保存在代码当中，而这也从侧面使我们的应用程序更加安全。

在本次演示中，我们设置的角色利用政策允许该实例以“put_item”方式访问至特定 DynamoDB 表。

在角色创建完成之后，我将其应用至实例并加以启动。我使用的是 t2.micro，旨在保证自身始终处于 AWS 免费层范畴内。不过在生产环境下或者预计将出现大规模流量的环境中，大家可能希望使用其它更强大、更可靠的方案，甚至遵循 AWS 最佳实践将自己的应用程序部署在负载均衡器之后、从而保证相关流量被分发至多个 EC2 实例处。

正如大家所见，仪表板本身被托管在 Amazon Simple Storage Service（简称 Amazon S3）当中，旨在确保其拥有处理大规模网络流量所必需的高弹性水平。

通过配置，我要求 Twilio 将流程发送至该服务器的公共 IP 地址。我在服务器上安装了 Node.js 以及 Express，希望借此处理回调操作。在 Node.js 当中 AWS SDK for JavaScript 的帮助下，我得以通过寥寥数行代码将适合的数据写入至 DynamoDB 表。

在本次示例中，应用程序会保存投票者的电话号码、输入时间戳以及消息内容——即 RED、GREEN 或者 BLUE 三种票选项目。

接下来，仍然借助 Twilio，应用程序会向用户发送一条确认消息，感觉他或她参与此次投票。

当应用程序将一份新的投票内容添加到表中时，Lambda 会识别到相关变更，并在一个 Lambda 事件中利用 Node.js 对 RED、GREEN 以及 BLUE 三个项目的票选结果再行分别汇总。接下来整理最终投票结果，并将其写入到 S3 上的存储桶当中。

由于 Lambda 以独立方式运行在大家所启动的任何服务器之上，因此我们无需专门为其划拨额外的处理资源。我们的 Lambda 功能以 Node.js 代码形式运行，且能够享受到由 AWS SDK 等各类内置库带来的全部便利。

Lambda 对于数据进入 DynamoDB 的具体方式并不做任何强制要求，而仅仅负责对表内容加以更新。举例来说，我们可以允许票选内容由其它多种来源提供，包括 Web 表单、电子邮件或者移动应用程序。通过利用 Lambda 监控 DynamoDB 表的方式，我排除了上述来源引发的潜在风险以及给计票工作带来的冗余代码编写难题。大家可以看到，Node.js 代码中的一个片段负责核算投票结果并将其写入 S3 存储桶当中，如下图所示：

动态仪表板

Amazon S3 提供一项有趣的功能，允许大家利用来自 S3 存储桶的数据构建静态网站。与 Lambda 类似，S3 同样提供额外功能，而且我们无需建立网络服务器或者配置任何新服务。

S3 将为大家提供一个 DNS 端点——在本次示例中为 voteapp.s3-website-us-east-1.amazonaws.com，不过我们也可以利用 Amazon Route 53 配置出一个指向对应存储桶的自定义域名。

利用 S3，我们的应用程序能够以极低延迟水平应对规模庞大的网络流量，而且完全无需分心于负载均衡或者 EC2 服务器过载问题。

尽管这套站点在技术层面看属于静态网站，但我们可以将服务器端脚本引入其中。利用部分 JavaScript 以及 Chart.js 图表库，我能够进一步构建起一套动态仪表板。

我们的应用程序会检查 Lambda 为我们生成的数据文件，识别其中的内容更新，而后将全部更新以图表方式显示出来。

敬请期待：第二部分

到 DynamoDB Streams 与 Lambda 发布通用版本时，我会推出本系列文章的第二部分。届时我们将一同深入到代码层面，帮助大家了解如何为自己构建起整套堆栈。我将继续使用 Node.js，但如果大家更倾向于 Python，好消息是各位完全可以利用 Python 完成整个实验性流程。

我希望大家能够通过本文了解到 Lambda 与 DynamoDB Streams 的强大之处。如果各位在上手这些值得赞叹的新服务时遇到了难题，请在评论栏中与我们交流。

原文链接： https://medium.com/aws-activate-startup-blog/building-dynamic-dashboards-using-lambda-and-dynamodb-streams-part-1-217e2318ae17

感谢 Raymond Zhao 对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。