转载

利用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表。

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

在角色创建完成之后，我将其应用至实例并加以启动。我使用的是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存储桶当中，如下图所示：

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

动态仪表板

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

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

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

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

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

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

我们的应用程序会检查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读者交流群利用Lambda与DynamoDB Streams构建动态仪表板：第一部分）。