实时和接近实时应用开发之间的差异是微乎其微的，但每个人都会遭遇应用程序在构建和运行上的延迟。

　　随着微服务的出现，构建云应用的最常见方法包括拆分每个组件，使其在单独的环境中运行。这种方法从维护，可扩展性和开发的角度来看是理想的，但却会降低单个事务的处理速度。

　　开发人员可以为那些需要快速处理的工作负载构建延迟在100毫秒内的实时应用，和几秒钟内的接近实时应用程序。接近实时对于许多应用来说已经足够快了，但对于金融机构或媒体公司中运行的应用来说则可能太慢。在本文中，我们将探讨如何对一个在AWS上运行的博客平台进行实时应用的开发。

　　从用户获取输入

　　当一个用户创建一个新的帖子时，会通过一个HTML表单提交，然后通知后端应用有新的内容要处理和显示。该应用程序可能还需要做一些文本分析，识别出与帖子关联的图片类型，然后自动发布到社交媒体。

　　将应用划分为单独的几个部分以使其可网络扩展，以便数百万用户可以同时发帖。当用户点击Submit时，平台立即保存内容并通知多个服务。在实时应用开发中，这被称为一个event。

　　监听者或事件模式

　　事件驱动应用程序的使用正变得越来越普遍。随着Node.js的普及，更多的开发人员正在学习event emitters的概念。在Node.js中，许多对象在完成任务后会立即通知一部分代码。这些代码块就是所谓的listeners;开发人员使用监听器的这种模式与使用Amazon Simple Queue Service(SQS)，Amazon Simple Notification Service(SNS)或Amazon Kinesis的应用程序非常相似。

　　event.on('ready', postToTwitter);

　　event.on('ready', postToFacebook);

　　event.on('ready', postToSnapchat);

　　event.on('ready', addImage);

　　event.trigger('ready', articleData);

　　Batch processing with Amazon SQS

　　使用亚马逊SQS进行批处理

　　大多数开发人员都是用异步的方式来处理事件，这有助于应用的可扩展，但却制造了额外的管理上的挑战。在该博客平台上，如果设置了异步过程来阅读和发布故事，整个过程需要几乎立即发生。撰写和提交帖子的博主不想等着看到自己的帖子发布。在浏览器重新加载时，有一定的延迟空间，但是许多用户不能容忍任何超过500毫秒(ms)响应的操作。

　　IT团队可能会遇到实时应用开发延迟。例如，如果一个事件传递到SQS，在读取之前会有一个自动延迟——从100毫秒到几秒钟。SQS专为批处理而设计，这有助于异步操作的处理，但却难以处理实时事件。更糟糕的是，如果后端系统没有跟上SQS请求，则可能在处理消息前可能有一个延迟的延迟。

　　使用Amazon SNS来触发多操作

　　与Amazon Kinesis类似，Amazon SNS专为近实时事件处理而设计。它将输入与各个处理节点分离。但是，与Kinesis不同，SNS被设计为基于一个事件触发多个操作。在该博客平台，一个开发人员可以拥有一个SNS Topic，即Post Created。多个AWS Lambda函数可以订阅该主题，一个发布到Twitter，一个发送到Facebook，另一个处理文档以自动识别与其关联的正确图片。解耦发生在SNS内，因此当应用程序还需要发布到Snapchat时，在发布方面不需要更改任何代码。另一个监听器会附加到该SNS主题，以便在发生事件时通知Snapchat微服务。

　　SNS不构建一个队列，它并行执行所有的事件。因此，Twitter，Facebook，Snapchat和图像微服务都会同时接收通知。例如，SNS无需等待Twitter发布后再发到Facebook。

　　SNS还允许开发人员配置应用端点，以立即和定期重试，直到事件处理成功——或达到指定的尝试次数。但是SNS的初始延迟可能会超过几秒钟，因此它不是完全实时的。

　　队列vs.管道

　　Amazon SQS和Amazon Simple Workflow Service都提供队列来解耦请求和处理服务。这个模式构建起来简单，并且非常的可扩展。不幸的是，这也是一种最延迟管道的方式。队列不是为提高速度而建;它们被构建为用于扩展——增加了至少100ms的延迟 - 即使这些队列是空的，并且它们扩展的速度也不快。队列具有等待资源变得可用的事件的积压。如果应用不需要实时运行，尤其是与竞价型实例相结合时，这可能非常有用。

　　但对于实时应用开发，像Amazon Kinesis这样的管道更合适。与队列不同，管道设计用于实时流处理。不是将项目添加到一个列表中，而是以流的形式发送。虽然项目仍可在流中积压，但只有在出现问题时才会发生。队列和管道都支持容错和重试，但管道立即运行。

　　与SQS不同，消息的延迟可以达到几百毫秒，Kinesis延迟只有几十毫秒。使用Kinesis这样的管道服务的最重要的原因是它直接与AWS Lambda集成。这不只是一个更快的队列服务，它还是一个不同的设计模式。

　　使用Amazon Kinesis进行实时处理

　　Amazon Kinesis为实时处理提供了更好的选择。虽然Kinesis类似于SQS，它不直接排队，更像一个管道，允许开发人员将请求定向到一个或多个处理服务。虽然这些管道可以有积压，但启动延迟通常明显小于队列服务，并且事件可以在10ms内接收并准备就绪。

　　此外，Kinesis直接与Lambda连接，这允许服务实时动态扩展。当Auto Scaling组识别到一个SQS的待办事项时，最多可能需要一个小时才能等到其他可用的资源，以减少延迟。使用Kinesis和Lambda，管道只是对每一个输入到管道的事件触发一个Lambda函数;不需要对资源进行配置，这意味着不会把时间浪费在启动额外的弹性计算云实例。

　　其他事件也可以触发Kinesis流，例如Amazon DynamoDB写操作。在博客这个示例中，当最终用户添加一个新帖子时，会直接添加到DynamoDB中，之后通过Kinesis Stream触发一个Lambda函数。

　　将各种服务功能连接起来

　　事件和工作程序之间的连接可以造成10毫秒或10分钟的延迟之差。对于计算密集型任务，SQS允许应用处理更长时间，正确处理超时事件并构建可能具有长启动时间的自定义工作程序。这些任务需要一段时间来处理，因此来自SQS的额外的一两秒延迟是可以容忍的。这些任务也可能运行起来很昂贵，因此如果这些类型的事件的延迟可以接受，开发人员应该考虑为工作进程选择竞价型实例。

　　开发人员可以将SNS与SQS结合使用，用于需要处理多个事件的进程。 SNS可以发送其他不需要实时发生的通知(电子邮件或短信)。请记住，运营商或电子邮件提供商的延迟总是会比SNS强加的延迟更长。

　　对于博客，开发人员将使用Amazon Kinesis来实时传送到博客平台。对于Twitter，Facebook和Snapchat消息，SNS将交付给Lambda函数。对于可能需要大量计算的图像处理系统，开发人员可以添加另一个SNS监听器，但将其传递给SQS队列，以使用定制的长时间运行的进程来处理图像处理相关的计算密集型工作负载。如果其他客户端需要通过自定义的渠道接受通知，请设置额外的Kinesis流，以便这些可以实时发生，或添加监听器到用于电子邮件，短信或其他近实时通知的SNS主题。

　　在所有情况下，传输介质都必须是实时处理或接近实时处理。这只取决于IT团队需要多快来传输信息。

　　责任编辑：DJ编辑