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

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

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

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

云测试与开发>更多

  • 云API,让应用程序“动”起来!

    随着云应用的增长,越来越多的企业尝试同时使用多个供应商。弥补服务中断的需求,使用不同服务的需求,以及基于费用选择服务的能力,都强调了对数据和应用程序可移植性的需求。

  • 容器即服务不可不知的事

    受益于容器即服务,或称为CaaS方案的大规模涌现——它们和编排、镜像存储库以及更多内建的东西直接竞争,这导致安装以及管理Docker环境,现在已经很容易了。

  • 2017云计算前景:是你主导它,还是被它主导?

    云计算不再是一个新想法。但它仍然在大幅发展着。本文介绍了一些未来趋势,这些趋势可能会主导企业在2017年对待云计算的方式。

  • 华为软件开发云:解读一站式开发的含义

    我们可以看到,软件已经无处不在,我们每天的工作、学习、生活几乎都离不开软件。我们每个人的智能手机里,也安装大量的应用软件,随着互联网技术、人工智能、大数据、云计算的发展,人类正在步入智能社会。

技术手册>更多

  • 微软三大云计算产品全概览PDF下载

    中国企业对“Azure”是既熟悉又陌生。熟悉是因为Azure平台在微软云战略中占有举足轻重的地位;陌生是因为在国内还没有任何Azure平台商用的实施案例。

  • 企业私有云选型完全手册

    虽然云计算发展的春天已经来临,但是众多企业仍然希望保持对IT环境和物理资源的控制。通常情况下,法律或法规会阻止企业实施从数据中心到公共云计算的转变。这就成全了私有云计算,它允许企业在本地管理硬件,同时又允许最终用户远程访问基础设施的下一个逻辑步骤。尽管每个IT环境都是独一无二的,但是对你的私有云计算项目实现从规划到投产有很多可供借鉴的最佳实践案例,其中包括选择正确的管理程序、软硬件以及合适的广域网和宽带技术。在这本技术手册中,我们将会关注企业私有云选型以及如何落地。

  • 云数据安全防御手册

    当云计算、云存储逐渐走入人们的工作生活时,企业在把资源迁移到云端时,不得不为其资产的安全而担忧,如何确保数据安全,他们要采取怎样的措施才能避开云中数据的泄漏,保证数据安全?

  • 云计算与数据保护:云计算加密教程

    云计算和数据保护是非常棘手的一项工作。当企业把服务迁移至云计算时,由于失去了对其敏感数据的控制而只能依赖于云计算服务供应商来确保数据的安全性,他们往往会为此担惊受怕。本云计算数据保护教程选自SearchCloudSecurity.com以及专家技术文章。它对如何在云计算中保护数据提出了建议,并可作为云计算加密技术的使用指南。在教程中,我们讨论了云计算加密的意义、介绍了实施云计算加密的挑战以及若干使用案例。

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团队需要多快来传输信息。