亚马逊AWS官方博客

Category: News*

Amazon AppSync 简介 – 使用实时和离线功能构建数据驱动型应用

在当今时代,我们几乎都会利用移动设备和应用来让我们的生活更加轻松惬意。随着我们对手机的依赖程度不断增加,移动应用市场已呈爆炸式增长,数百万个应用竞相吸引我们的注意力。对于移动开发人员,这意味着我们必须确保我们构建的应用能够提供应用用户所需的质量和实时体验。因此,开发包括多用户数据同步、离线网络支持和数据发现等功能的移动应用已变得至关重要。我最近通过阅读 InfoQ、DZone 等出版物和移动开发博客 AlleviateTech 上的几篇文章,了解了移动开发趋势,我认为提供上述功能的关键要素之一是云驱动型移动应用。这似乎完全正确,因为它涉及到移动数据同步和数据存储。 既然如此,我认为现在是我宣布新服务 AWS AppSync 的最佳时机,该服务用于构建由云中的数据密集型服务驱动的创新移动应用。AWS AppSync 是一项完全托管的无服务器式 GraphQL 服务,可提供实时数据查询、同步、通信和离线编程功能。对于那些不熟悉开放式 GraphQL 规范的人,让我简要分享一些相关信息。GraphQL 是一种响应式数据查询语言和服务器端运行时,用于查询可检索实时数据和执行动态查询的数据源。您可以使用 GraphQL 构建响应式 API,以便在构建客户端应用程序时使用。GraphQL 在应用程序层工作,并提供用于定义架构的类型系统。这些架构可用作规范,以定义应如何对数据执行操作,以及在检索时应如何设置数据结构。此外,GraphQL 还有一个声明性编码模型,它受许多客户端库和框架 (包括 React、React Native、iOS 和 Android) 的支持。 现在,GraphQL 开放标准查询语言的强大功能正在通过 AWS AppSync向您提供丰富的托管服务。借助 AppSync ,开发人员可以轻松简化跨多个数据源的数据检索和处理操作,从而使其能够快速建立原型,构建和创建强大的协作式多用户应用程序。AppSync 在设备处于连接状态时保持数据更新,但使开发人员能够通过在本地缓存数据并在连接可用时同步本地数据,来构建脱机工作的解决方案。 我们来讨论 AWS AppSync 的一些关键概念以及该服务的工作原理。 AppSync 概念 AWS AppSync 客户端:定义操作、封装请求的授权详细信息以及管理离线逻辑的服务客户端。 数据源:数据存储系统或用于存储数据的触发器 身份:随 GraphQL 代理的请求一起提供的一组包含权限和标识上下文的凭证 GraphQL 代理:用于处理和映射请求、处理冲突解决方法以及管理精细访问控制的 GraphQL 引擎组件 操作:AppSync 中支持的三种 GraphQL 操作之一 […]

Read More

Amazon Neptune – 完全托管的图形数据库服务

在我们用来支持现代生活的所有数据结构和算法中,图形不断改变着世界。各企业不断产生和获取关系复杂的丰富数据。然而,开发人员仍然不得不在传统数据库中对这些复杂关系进行建模。这导致查询极为复杂,并且成本高昂,随着关系的增加,性能也会不断下降。我们希望能简化这些越来越复杂的新式数据集、关系和模式的处理。 欢迎 Amazon Neptune 今天,我们要发布 Amazon Neptune 有限预览版,这是一个快速可靠的图形数据库服务,可供客户轻松洞悉高度连接的数据集之间的关系。Amazon Neptune 的核心是专门构建的高性能图形数据库引擎,它进行了优化,可存储数十亿关系并将图形查询延迟减至毫秒级。Amazon Neptune 作为完全托管的数据库提供,让客户能够腾出手来集中精力开发其应用程序,而不用忙于执行枯燥的重复性操作,如维护、修补、备份和恢复。该服务支持快速故障转移、时间点恢复以及多可用区部署,从而实现高可用性。它支持多达 15 个只读副本,您可以将查询吞吐量扩展到每秒数十万个查询。Amazon Neptune 在 Amazon Virtual Private Cloud 内运行,因此您可以加密静态数据,可完全控制传输中数据和静态数据的完整性。 这项服务有很多有趣的功能,不过可能很多人还不熟悉图形数据库,因此我们首先介绍一下概念。 图形数据库 图形数据库用于存储顶点 (节点) 和边缘 (关系或连接),这两种元素都可以键值对的形式存储其属性。对于连接的上下文关系驱动数据,图形数据库很有用。一些典型的应用包括社交媒体网络、推荐引擎、驾车路线、物流、诊断、欺诈检测以及基因测序。 Amazon Neptune 支持两种开放式图形描述和查询标准: 使用 Gremlin 查询的 Apache TinkerPop3 样式属性图。Gremlin 是一种图形遍历语言,在这种语言中,查询是由沿着边缘到节点的离散步骤组成的遍历。通过用于 TinkerPop 的现有工具和客户端,可以快速开始使用 Neptune。 使用 SPARQL 查询的资源描述框架 (RDF)。SPARQL 是一种声明式语言,它基于 W3C 的 Semantic Web 标准。它遵从“主->谓->宾”模型。具体地说,Neptune 支持以下标准:RDF 1.1、SPARQL Query 1.1、SPARQL Update […]

Read More

Amazon MQ – 用于 ActiveMQ 的托管消息代理服务

消息收发将分布式应用程序的各个部分组合在一起,同时还提高了弹性,支持实现高度可扩展的架构。例如,今年早些时候,Amazon Simple Queue Service (SQS) 和 Amazon Simple Notification Service (SNS) 提供了针对 Prime Day 客户订单处理的支持,共处理 400 亿条消息,速度为每秒 1000 万条,没有出现客户可觉察到的问题。 SQS 和 SNS 已广泛用于云原生应用程序。不过,我们的许多大客户都已经在使用开源或商业授权的消息代理。他们的应用程序是关键任务型的,因而提供后台支持的消息收发同样如此。我们的客户将消息收发基础设施的设置和持续维护描述为一个“非常痛苦的”过程,并声称他们每周至少花费 10 个人工小时来处理该事宜。 新的 Amazon MQ 今天,我们发布了 Amazon MQ,这是一项用于 Apache ActiveMQ 的托管消息代理服务,它让您只需三次单击,即可在数分钟内开始使用!您可能知道,ActiveMQ 是一个流行的开源消息代理,速度非常快且功能丰富。它提供了队列和主题、持久和非持久订阅、基于推送和基于轮询的消息收发以及筛选功能。 作为一项托管服务,Amazon MQ 负责 ActiveMQ 的管理和维护。这包括代理预配置、修补、高可用性的故障检测和恢复以及消息持久性等各项职责。借助 Amazon MQ,您可以直接访问 ActiveMQ 控制台以及用于消息收发的行业标准 API 和协议,包括 JMS、NMS、AMQP、STOMP、MQTT 和 WebSocket。这样您就可以从任何使用这些标准的消息代理迁移到 Amazon MQ – 随同支持的应用程序一起,而无需重写代码。 您可以创建一个单实例 Amazon […]

Read More

AWS Media Services – 处理和存储云端视频并通过其获利

您还记得早期的网络视频是什么样子吗?就在不到二十年前,独立播放器、邮票大小的视频、缓慢卡顿的连接、过载的服务器和不断出现的正在缓冲消息还是常态。 如今,技术进步和一系列标准的问世,使得这种情况有了很大改观。视频消费者现在拥有掌控权。他们使用各种形状、尺寸和不同年份制造的设备欣赏通过无线电播放的、流式传输的或在网络之上 (即 OTT) 发送的直播和录制内容,并期望立即访问吸引并牢牢抓住其注意力的内容。满足这些期望给内容创作者和发行商带来难题。他们 (或其媒体服务器) 必须准备好制作覆盖各种尺寸、格式和比特率的视频,并随时准备应对计划内或计划外的需求高峰,而不是生成通用格式的视频。面对所有这些复杂情况,他们必须采用一种支持内容和基础设施的盈利模式来帮助他们交付内容。 新的 AWS Media Services 我们目前推出了一系列广播品质的媒体服务,每项服务都旨在处理上述难题的一个或多个方面。您可以结合使用这些服务以构建完整的端到端视频解决方案,也可以使用其中一项或多项服务来构建数据块样式。利用真正的 AWS 风格,您可以花费更多时间来创新,减少设置和运行基础实施的时间,从而让您集中精力创建、交付您的内容并从中获利。这些服务全都具有弹性,可让您提高处理能力、加快连接和存储速度,并使您能够轻松处理数百万用户 (甚至更多) 峰值。 下面介绍了这些服务 (可通过一组交互式控制台以及一组全面的 API 访问所有服务): AWS Elemental MediaConvert – 基于文件的 OTT 转码、广播或存档,支持一长串格式和编解码器。具体功能包括多声道音频、图形覆盖、隐藏式字幕和多个 DRM 选项。 AWS Elemental MediaLive – 通过即时编码向电视和多屏幕设备实时提供视频流。可让您在数分钟内部署高度可靠的直播通道,并完全控制编码参数。该服务支持广告插播、多声道音频、图形覆盖和隐藏式字幕。 AWS Elemental MediaPackage – 原创视频和即时包装。从单个输入开始,为代表一长串当前和传统格式的多台设备生成输出。支持多种盈利模式、时间变换实时流、广告插播、DRM 和支持管理。 AWS Elemental MediaStore – 针对媒体优化的存储服务,可为高性能和低延迟应用程序 (例如实时流) 提供支持,同时充分利用 Amazon Simple Storage Service (S3) 的扩展性和持久性。 AWS Elemental […]

Read More

H1 实例 – 适合大数据应用程序的快速密集型存储

AWS 的规模和我们客户群的多样性,使得我们有机会创建专用于许多不同类型工作负载的 EC2 实例类型。例如,许多流行的大数据用例依赖于对若干 TB 数据的高速顺序访问。我们的客户希望构建和运行超大型 MapReduce 集群,托管分布式文件系统,使用 Apache Kafka 来处理海量的日志文件等等。 新的 H1 实例 新的 H1 实例专为此类用例而设计。与现有的 D2 (密集型存储) 实例相比,H1 实例针对每 TB 本地磁盘存储容量提供了更多的 vCPU 和更高的内存,同时增加了网络带宽,使您能够通过良好平衡的资源组合来应对更加复杂的挑战。 这些实例基于以 2.3 GHz 基本时钟频率运行的 Intel Xeon E5-2686 v4 处理器,并且提供四种实例大小 (所有实例均仅限 VPC 和仅限 HVM): 实例名称 vCPU RAM 本地存储 网络带宽 h1.2xlarge 8 32 GiB 2 TB 最高 10 Gbps h1.4xlarge 16 64 […]

Read More

Amazon EC2 更新 – 简化对竞价型容量的访问、平稳的价格变化、实例休眠

EC2 竞价型实例可让您使用 AWS 云中的多余计算容量。我们的客户使用竞价型实例队列来支持 CI/CD 环境和流量生成程序、托管 Web 服务器和微服务、渲染电影以及运行众多类型的分析作业,所有这些实例的价格相比按需实例都节省了可观的成本。 新的简化访问 今天,我们为竞价型实例推出了新的简化访问模式。您只需在通过 RunInstances 函数、 run-instances 命令或 AWS 管理控制台启动实例时指明您希望使用竞价型容量,即可提交一个请求,只要有相应的容量可用,就会满足该请求。您无需完成额外的工作,即可为实例类型节省高达 90% 的按需使用费用;在相同预算下,整体应用程序吞吐量最多可提高 10 倍。以这种方式启动的实例将会一直运行,直至您终止它们,或者 EC2 需要将它们回收以便按需使用这些实例。在这种情况下,通常会提前 2 分钟针对实例发出警告,然后再回收,这非常适合提供容错功能的应用程序。 与需要了解竞价市场、出价以及调用独立异步 API 的旧模式不同,新模式是同步的,并且与按需实例一样简单易用。您的代码或脚本会立即收到一个实例 ID,不需要检查是否已处理和接受请求。 我们已经清楚地说明这一点,尽可能地简单化,许多当前的脚本和应用程序应该很容易地修改即可请求和利用竞价型容量。如果您想对竞价型实例预算执行额外的控制,则可以选择在发出容量请求时指定最高价格。如果您希望使用竞价型容量来支持 Amazon EMR、Amazon ECS 或 AWS Batch 集群,或者您通过 AWS CloudFormation 模板或 Auto Scaling 组的方式启动竞价型实例,您将会从这个新模式受益,而不需要做出任何改变。 根据 RequestSpotInstances 或 RequestSpotFleet 构建的应用程序将会继续正常工作,没有任何变化。不过,您现在可以选择发出不包括 SpotPrice 参数的请求。 平稳的价格变化 作为今天发布的一部分,我们还改变了现货价格发生变化的方式,转为采用根据长期供求趋势逐步调整价格的模式。正如我前面提到的那样,您将继续享受到相比按需价格平均节省 70-90% 的优势,并且您将继续按照实例运行时间段内的现货价格支付费用。对于依托于我们的竞价型队列功能构建的应用程序,将继续根据您在创建队列时所指定的配置,自动将其竞价型实例分散放置到最经济实惠的池中。 竞价实际操作 要从命令行启动竞价型实例,只需指定 […]

Read More

M5 – 最新一代的通用型 EC2 实例

我总是建议新的 EC2 用户从我们的通用型实例入手,运行一些压力测试,并对他们的应用程序的计算、内存和联网情况有一个非常详细的真实感受,然后再尝试其他实例类型。借助针对计算、内存和存储进行优化的各种实例,我们的客户可以有多种选择,并且可以灵活地选择最适合他们需求的实例类型。 正如您可以从我的 EC2 实例历史帖子中看到的,通用型 (M) 实例的历史可以追溯到 2006 年,那年我们推出了 m1.small 实例。我们沿着这个系列分支不断地发展,推出了 M2 (2009 年)、M3 (2012 年) 和 M4 (2015 年) 实例。我们的客户使用通用型实例来运行 Web 和应用程序服务器,托管企业应用程序,支持在线游戏以及构建缓存机群。 新的 M5 实例 今天我们推出了新的 M5 实例,又向前迈出了一大步。这些实例得益于我们对持续创新的坚定承诺,可提供比以前实例更高的性价比。M5 实例采用自定义的 Intel® Xeon® Platinum 8175M 系列处理器,运行频率为 2.5 GHz;这些实例设计用于高要求的工作负载,相比基于每内核的 M4 实例,性价比可提高 14%。对于使用 AVX-512 指令的应用程序,启动速度将是每内核 FLOPS 的两倍。我们还为高端实例增加了一个新的大小,让您有更多的选择。 下面列出了 M5 实例 (所有实例均仅限 VPC、仅限 HVM 以及 EBS 优化): 实例名称 […]

Read More

能够直接访问硬件的 Amazon EC2 裸机实例

当客户向我们提出有关 AWS 的新的独特要求时,我们会仔细聆听,询问许多问题,并尽力理解和满足他们的需求。当我们这样做时,我们会公开发布此类服务或功能;我们不会为单个客户构建一次性或“用过即弃”的服务或功能。因为这种模式很混乱,难以扩展,不符合我们的工作方式。 相反,每个 AWS 客户都可以访问我们构建的任何内容,而且每个人都可以从中受益。VMware Cloud on AWS 就是此战略实际运用的一个很好的例子。他们告诉我们,他们希望直接在硬件上运行虚拟化堆栈,在 AWS 云中为客户提供 AWS 带来的弹性、安全性和可靠性 (以及种类繁多的服务)。 我们知道其他客户对于裸机硬件也有一些有趣的使用案例,并且不希望嵌套虚拟化的性能受到影响。对于利用性能计数器和 Intel® VT 等低级别硬件特性 (这些特性在虚拟化环境中并非始终可用或完全受支持) 的应用程序,以及旨在直接在硬件上运行或者获得许可并支持在非虚拟化环境中使用的应用程序,他们希望能够访问物理资源。 多年来,我们一直在开展将网络、存储和其他 EC2 功能从我们的虚拟化平台转移到专用硬件的工作,并为可能的解决方案奠定了坚实的基础。正如我在现已推出 – Amazon EC2 的计算密集型 C5 实例中描述的那样,这项工作包括一组专用硬件加速器。 现在我们已经为 VMware 提供了他们要求的裸机访问,并且正在面向所有 AWS 客户推出此功能。我非常期待看到您利用它们来实现相关目标! 新的裸机实例 今天,我们开始公开预览 i3.metal 实例,这是 EC2 实例系列中的第一个实例,提供了两全其美的功能,允许操作系统直接在底层硬件上运行,同时仍然提供云的所有优势。该实例让您能够直接访问处理器和其他硬件,并具有以下规格: 处理 – 以 2.3 GHz 速度运行的两个 Intel Xeon E5-2686 v4 处理器,总共 36 个超线程内核 (72 […]

Read More

re:Invent 大会期间的 AWS 云幕后故事

当您漫步在 AWS re:Invent 大会现场时,不妨花点时间来思考一下,对于需要整合在一起的所有要素,您有哪些期望… 从会议地点开始,我的同事们选择最合适的场馆,精心设计各种研讨会,挑选发言嘉宾,制定日程表,选择色彩方案,准备电子或印刷的所有指示牌等等,我们所有这些努力的目标是,希望为您和成千上万的其他 AWS 客户创造一个优良的学习环境。 不过,通常情况下,您看到的只是表面的那一部分而已。在幕后,我们将人员、流程、计划和系统有机地组织起来,将所有这些基础设施安排到位,让各个部分都运作得如此顺利,以至于您通常不会注意到这些细节。 今天我想说的是,re:Invent 大会基础设施的关键部分实际上位于地下。除了为您的手机、平板电脑、相机、笔记本电脑和其他设备提供一流的 Wi-Fi 连接之外,我们还需要确保在从现场直播主题演讲到 WorkSpaces 支持的动手实验室等各项活动中,彼此之间的连接以及互联网连接正常工作。要确保在沿着拉斯维加斯大道上各个酒店中举办的各项活动正常开展,可靠、低延迟的连接至关重要! 感谢 CenturyLink/Level3 的大力支持 多年以来,我们一直在与 Level3 的优秀员工合作,共同实现这一目标。他们最近成为了 CenturyLink 的一份子;CenturyLink 现在是 re:Invent 大会的官方网络赞助商,负责提供将各个 re:Invent 会场连接在一起的光纤网络和线路等服务。 为了让大会顺利举办,他们在大道下面埋设了两英里的暗光纤,路由到两个独立的 AWS 区域中的多个可用区。金沙博览中心配备了 10 Gb 冗余连接,其他场馆 (Aria、MGM、Mirage 和 Wynn) 分别预配置了 2 到 10 Gb 连接,这意味着大道半数以上的区域都支持 Direct Connect。根据某处设施 IT 经理的说法,这可能是拉斯维加斯有史以来配置的最大临时混合网络。 在 Wi-Fi 方面,showNets 接通到同一个网络;您的设备可以直接与 Direct Connect 接入点通信 (这太酷了!)。 下图概要说明了这些功能如何结合在一起: […]

Read More

98、99、100 个 CloudFront 接入点!

九年前,我向您展示了如何使用 Amazon CloudFront 分发内容。2008 年我们推出 CloudFront 时它有 14 个接入点,然后就快速扩展。CloudFront 现在有 89 个边缘站点和 11 个区域边缘缓存,能够为世界各地数百万查看者生成的流量提供支持。 23 个国家/地区,50 个城市,并且还在不断增长 这 100 个接入点遍布全球,站点分布在 23 个国家/地区的 50 个城市。在过去 12 个月中,我们的网络扩大了约 58%,增加了 37 个接入点,其中 9 个位于以下新增城市: 德国,柏林 美国明尼苏达州,明尼阿波利斯 捷克共和国,布拉格 美国马萨诸塞州,波士顿 德国,慕尼黑 奥地利,维也纳 马来西亚,吉隆坡 美国宾夕法尼亚州,费城 瑞士,苏黎世 还有更多接入点正在筹划中,包括阿拉伯联合酋长国的一个边缘站点,目前计划在 2018 年第一季度开放。 为客户创新 如前所述,我们的网络由边缘站点和区域边缘缓存组成。区域边缘缓存是在 re:Invent 2016 大会上首次发布的,它位于我们的边缘站点和您的来源服务器之间,内存量甚至高于边缘站点,使用它,我们可以将内容存储在查看者附近以便提高传输速度,同时减小来源服务器的负担。 虽然位置很重要,但位置只是我们的出发点。我们继续关注安全性,最近发布了 Security Policies 功能,并宣布 CloudFront 是一项 符合 […]

Read More