实时应用开发让延迟最小化

日期:2016-12-23作者:Chris Moyer

【TechTarget中国原创】实时和接近实时应用开发之间的差异是微乎其微的,但每个人都会遭遇应用程序在构建和运行上的延迟。
随着微服务的出现,构建云应用的最常见方法包括拆分每个组件,使其在单独的环境中运行。这种方法从维护,可扩展性和开发的角度来看是理想的,但却会降低单个事务的处理速度。
开发人员可以为那些需要快速处理的工作负载构建延迟在100毫秒内的实时应用,和几秒钟内的接近实时应用程序。接近实时对于许多应用来说已经足够快了,但对于金融机构或媒体公司中运行的应用来说则可能太慢。在本文中,我们将探讨如何对一个在AWS上运行的博客平台进行实时应用的开发。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

云测试与开发>更多

技术手册>更多

  • 云计算网络安全电子书

    不管你选择软件即服务、平台即服务还是基础架构即服务,有一件事是不可避免的:你需要良好的、可靠的网络连接到云。 网络很可能成为一个障碍,因为云大大改变了网络的作用以及与之配套的硬件和软件。在这本技术手册中,我们将主要介绍云网络安全的相关内容。

  • 亚马逊IaaS服务解析

    亚马逊的web服务(AWS)在云计算领域一直处于不可撼动的地位。AWS是一个典型的IaaS服务,提供了一组服务,包括存储(S3)、计算能力(EC2)等

  • IaaS参考完全手册

    基础架构即服务是云计算服务模型三支柱之一。但是你是否对于IaaS有足够的了解?你可能知道IaaS是交付设备,比如通过网络交付服务器和虚拟机,但是不同的云提供商之间有什么不同?企业对于IaaS到底是什么态度,这本IaaS参考完全手册将协助你整理一下IaaS提供商的背景和一些有帮助的技巧。

  • 云存储市场求生指南

    云存储对于一系列的存储需求是一种有效的选择。理解各种云存储系统的关键特性有助于识别合适的用例,并避免潜在且昂贵的错误。在这本技术手册中,我们将着重关注云存储市场动态,以及目前的价格情况,同时关注企业在选择云存储服务时需要注意哪些问题,有哪些可供参考的内容。

TechTarget

最新资源
  • 安全
  • CIO
  • SOA
  • 虚拟化
  • 网络
  • 数据中心
【TechTarget中国原创】

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

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

开发人员可以为那些需要快速处理的工作负载构建延迟在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团队需要多快来传输信息。