亚马逊AWS官方博客

相信大家已经都知道，Amazon DynamoDB 是一项全托管的NoSQL 数据库服务，适合所有需要一致性且延迟低于 10 毫秒的任意规模的应用程序，支持文档和键值存储模型。使用DynamoDB，可创建数据库表来存储和检索任意量级的数据，并提供任意级别的请求流量。现在，DynamoDB还提供了Auto-Scaling的功能，即可以通过你预先设置的阈值自动扩展和缩减表的吞吐量，做到完全弹性自动伸缩的目的，真正达到让你的数据库按实际吞吐量进行付费。 这么高的并发量却依然可以保持服务器的平均延迟在个位数毫秒，这让DynamoDB受到了非常多用户的青睐。然而随着大数据时代的数据暴增，很多客户的场景比较特殊，他们对数据库的响应时间越来越苛刻，甚至需要达到微秒的级别！这无疑给DynamoDB数据库又带来了一个难题。甚至也有客户会提到，能不能在DynamoDB前面放一层类似Redis的Cache服务呢？如果这样做的话，需要自己搭建缓存数据库，并且解决DynamoDB和Redis之间的数据同步问题；同时还要重写代码实现业务逻辑，比如如果数据在缓存中，则立即返回，如果数据没有在缓存中，则必须从数据库里面读取，将数据写入到缓存中，然后再返回。 当用户还带着这样的担心时，现在，Amazon DynamoDB已经整合了这一特性，推出了一个新的功能，即Amazon DynamoDB Accelerator，简称DAX。这是一种完全托管并且高度可靠的内存缓存，即使每秒种的请求量达到数百万，却依然可以将Amazon DynamoDB的响应时间从数毫秒缩短到数微秒！其实在很多场景都可以用到DAX，比如实时竞拍、秒杀、电商、社交游戏等场景，DAX可以提供快速的内存读取性能；再比如在产品促销日，读取访问量会明显上升，但是销售日结束访问量就会回归正常，诸如此类读取密集型的工作负载但同时又对成本敏感的应用都可以使用DAX服务。像类似于Expedia、Twilio、Genesys、eyeview等客户都已经率先用上了DAX服务 目前，DAX还是处于预览版，您可以点击链接进行申请。接下来，让我们创建一个DAX集群，赶紧体验一下微秒级别的响应测试吧！ 1. DAX集群的原理 上图中可以看到，DAX起了一组缓存的节点（目前最多可以是10个节点），并将这些节点置放在VPC内部，应用程序部署在EC2上，这样EC2和DAX Cluster通过内网直接访问。关于DAX的内存缓存，主要是DynamoDB的读和写操作： （1）最终一致性的读取操作，支持GetItem、BatchGetItem、Query、Scan接口，如果读取在DAX缓存中命中，将直接从DAX集群里读取；如果是第一次读取没有命中，那就从DyanmoDB里面读取。 （2）写入操作支持BatchWriteItem、UpdateItem、DeleteItem、PutItem接口，写入的时候数据先写入到DynamoDB表，确认写入成功之后，然后再写到DAX集群（item cache），这个操作只有在DynamoDB表和DAX集群都写入了数据的时候才算成功。如果由于一些原因这个操作失败了，那么这个item将不会缓存到DAX里面，并且会抛出一个exception。这种方式可以让缓存和数据库的数据保持一致性和完整性，不会出现过期数据在缓存里面。 （3）如果DAX有多个节点时，会选取一个主节点（primary node），多个从节点（read replica node），数据最终会分布到所有节点上，但对于客户端来说，只需要关心唯一的DAX连接地址，已经内置了负载均衡和路由策略，并且自动执行故障检测、故障恢复、软件修补等管理任务。 接下去，我们将模拟这一过程，进行实际测试。 2. 启动DAX集群 首先启动一个DAX集群，指定集群的节点数（目前节点最多为10个），我们建议您在生产环节中启用两个以上的节点，并将这些节点置放在不同的可用区中，从而提高高可用。设置好相应的IAM Role和Policy。Policy可以配置“只读”权限，或者“读和写”权限。更多关于权限配置可以参考: http://s3.amazonaws.com/dynamodb-preview-dax/DAX.access-control.html 接下去设置DAX集群的子网组，DAX集群的节点会部署在这些子网里面。选定VPC和相对应的子网，并设置安全组。安全组入站需要打开DAX所用到的8111端口。 接下去配置DAX的参数组，指定Cache的Query TTL和Item TTL值。TTL的时间小到可以是“秒”，大到可以到“天”。 也可以自定义选定维护窗口，如果需要的话可以再加一个SNS通知，这样只要集群有维护就会立刻以短信，或者邮件等形式通知到您。 到这里，DAX集群就创建成功了。DAX集群会有一个唯一的endpoint地址，例如，这里是 dax-cluster-demo.bnsilv.clustercfg.dax.usw2.cache.amazonaws.com:8111 另外可以看到在这个例子中DAX集群启动了3个节点。 DAX集群具体的3个节点 3. 启动EC2 ，作为应用程序的server，同时作为DAX的client 如果仅作为测试，可以启动一台t2.micro的小型机器（Amazon Linux）。 EC2通过监控检查，启动成功。 4. 安装Java应用程序 （1）首先通过客户端连接到这台Amazon Linux EC2 （2）安装Java SDK sudo yum install […]

背景 在Amazon Redshift 数据仓库为核心的用户，常常陷入一个困境，要想利用该MPP架构的云端数据仓库能力，用户通常需要利用Redshift的 copy命令将数据从S3并行拷贝到Redshift中，如果在数据量比较大的情况下，成本上的考量和业务上的诉求的矛盾会让用户犹豫不定； 尤其突出的矛盾是，客户的业务部门的需求涵盖数据范围同时包含数据仓库的数据和放在S3上的中间或者原始数据集，此时，我们能怎么做？ AWS大数据最佳实践的启示 AWS大数据最佳实践告诉我们要将数据的存储和处理、分析相分离，比如在Amazon EMR服务架构中（如下图），要分析的数据集按照一定的格式压缩存储在Amazon S3上，在EMR中通过Hive定义外表关联到S3上的数据，但不复制到EMR本地，从而实现了数据存储和分析处理的解耦；在大量的用户实践中，我们发现如此的架构优化，可以帮助客户节约大量的存储成本，同时，EMR分析集群无状态化，可以按需动态启动和停止EMR集群，从而优化了计算成本。同理，我们能否在Redshift数据仓库中引入类似的外部表的概念呢？ Amazon Redshift Spectrum简介 Amazon Redshift Spectrum是Redshift的一个新特性，它可以帮助客户将Redshift的分析能力从本地存储扩展到Amazon S3数据湖中海量的非结构化数据而不需要加载数据。通过Redshift Spectrum您可以将热数据存储到 Amazon Redshift 群集中，以获得本地磁盘性能；同时使用 Amazon Redshift Spectrum 将您的查询扩展到 Amazon S3 中存储的冷数据，以获得无限的可扩展性和低成本。 详细情况请参考官方介绍：https://aws.amazon.com/cn/redshift/spectrum/ 目标人群及应用场景 该新功能的推出完善了Redshift数据仓库用户的大数据分析的应用场景，客户可以直接利用Redshift和Redshift Spectrum的能力同时处理本地和S3上的数据集；所以，目标受众是Redshift数据仓库的用户比如金融，电商，游戏等等行业客户。 从应用场景来看，可以满足如下业务需求： 针对数据仓库本地数据和S3上的数据提供一致的、熟悉的数据仓库操作体验 提供终端用户统一的BI或者SQL客户端接入 跨数据仓库热数据和S3冷数据的复杂混合查询 满足低频的业务全数据的低成本即席查询 大数据处理示例管道 本大数据处理示例管道展示了以Redshift数据仓库为核心的典型用户场景，原始数据，中间结果和ETL处理之后的数据都保存在数据湖Amazon S3上；用户通过BI工具或者熟悉的SQL客户端通过Redshift（包括Redshift Spectrum）操作所有的业务数据，包括大数据量的原始数据和存储在数据仓库本地的热数据；客户无需专门为了某个业务的特殊需求，将数据从冷数据从S3复制到Redshift本地再作分析。 支持的数据格式 Redshift Spectrum 使用您已使用的开发数据格式在 Amazon S3 中直接查询数据，这些格式包括 文本文件如 CSV格式文件 日志文件如TSV格式 列式格式如Apache Parquet和Hive中的RCFile格式文件 二进制文件：Sequence格式文件 压缩格式支持：gzip、snappy、bz2 […]

数据分析特别是实时数据分析，已经越来越多的成为各行各业的分析要求与标准 – 例如，（新）零售行业可能希望通过­­线下POS数据与实时门店客流流量的进行实时结合与分析，实现商品销售，销量，总类等等的实时预测； 在线广告平台期望通过广告(Impression)总类，数据量以及基于时间的点击（Click）量，计算实时的广告转化率(Conversion Rate)；物联网的用户想通过实时分析线下的状态设备与设备采集的数据，进行后台的计算与预判 – 例如做一些设备维修的提前预警(Predicative Failure Analysis)与线下用户的使用习惯；电商平台或者是在线媒体需要给终端用户提供个性化的实时推荐等等。 纵观这些业务系统，从数据流的角­­度看，往往数据架构可以分为前后端两个部分 – 前端的业务数据与日志收集系统（其中业务数据系统一般都是利用关系型数据库实现 –  例如 MySQL，PostgreSQL）与后端的数据分析与处理系统 （例如ElasticSearch 搜索引擎，Redshift数据仓库，基于S3的Hadoop系统 等等，或者基于Spark Stream的实时分析后端）。 “巧妇难为无米炊”，实时数据分析的首要条件是实现实时数据同步，即从上述前端系统到后端系统的数据同步。具体来讲包含两个要求（根据业务场景的不同，实时性会有差异）- 1) 实时 2) 异构数据源的增量同步。实时的要求容易理解 – 无非是前后端系统的实时数据ETL的过程，需要根据业务需求，越快越好。所谓异构数据源的增量同步是指，前端产生的增量数据（例如新增数据，删除数据，更新数据 – 主要是基于业务数据库的场景，日志相对简单，主要是随时间的增量数据）可以无缝的同步到后端的数据系统 – 例如ElasticSearch，S3或者Redshift等。 显然，这里的挑战主要是来自于异构数据源的数据ETL – 直白一点，就是怎么把MySQL（或者其他RDBMS）实时的同步到后端的各类异构数据系统。因为，MySQL的表结构的存储不能简单的通过复制操作实现数据同步。  业界典型的做法大概可以归纳为两类 – 1）通过应用程序双写的架构 (application dual-writes)  2) 利用流式架构实现数据同步，即基于流式数据的Change Data Caputre (CDC) 。 双写架构实现简单，利用应用逻辑实现，但是要保证数据一致性相对复杂（需要通过二阶段提交实现 – two phase commit），而且，架构扩展相对比较困难 – 例如增加新的数据源，数据库等。 利用流式数据重构数据，越来越成为很多用户与公司的实时数据处理的架构演化方向。 MySQL的Binlog，以日志方式记录数据变化，使这种异构数据源的实时同步成为可能。 今天，我们主要讨论的是如何利用MySQL的binlog实现流式数据同步。 MySQL […]

Amazon S3是互联网存储解决方案，能让所有开发人员访问同一个具备可扩展性、可靠性、安全性和快速价廉的数据存储基础设施。Amazon S3 提供了一个简单 Web 服务接口，可用于随时在 互联网上的任何位置存储和检索任何数量的数据。开发人员可以利用Amazon提供的REST API接口，命令行接口或者支持不同语言的SDK访问S3服务. 同时S3对于上传功能的API提供也是非常丰富的，与此同时，很多客户对于S3的断点续传也有了很深入的需求，本篇博客将会介绍如何使用S3的Javascript SDK来实现客户端浏览器到S3的断点续传功能. 安全考量 首先我们需要度量在浏览器客户端直连上传到S3这个场景下的安全问题，我们是一定不能把我们的AccessKey暴露到客户端浏览器的，但是上传到S3的API一定要提供AccessKey和SecretKey，因此这里我们将会利用生成临时的AccessKey和SecretKey（结合有效期）的方式来保证客户端的上传，这里介绍一篇关于利用TVM (Token Vending Machine)来生成临时Key并上传S3的文章，本文主要探讨关于S3的分片上传和断点续传的知识点. Javascript SDK和S3 API简介 从整体编程语言架构的层面上来讲，AWS的各个语言的SDK都主要划分为上层和下层的API, 上层API主要是针对一些用户必要的功能利用下层API所作的一层封装，掌握了这个原则之后我们就可以合理的利用AWS的上层API看能否实现自身的需求. Javascript SDK文档总结 在掌握SDK之前，我们应该先对SDK的文档和大致的结构有一个了解，这样才能方便我们更好的使用SDK, 下面列出了SDK的官网入门连接和API参考文档. API参考文档: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/index.html S3 API参考文档: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html 构建SDK中的S3对象 首先，AWS的SDK都是先需要利用Credentials来构建对象的，这里我们构建S3的对象也是如此，但是请注意一定不能将自己的Key暴露在客户端或者提交到代码中，应该使用 TVM获取了Key之后再利用AWS.Credentials对象来构建S3的对象. 在构建S3对象时，也需要同时指定AWS的Region. 利用上层Javascript API构建简单的分片断点续传功能 接下来，我们一步一步的来创建上层API构建断点续传的实践. 1. 创建工程 这里我们以node.js平台的express来提供简单的静态服务. 本文不会涉及如何安装node.js，关于安装指南，可以参考官网nodejs.org 首先利用npm包管理器安装express模版生成器: npm install express-generator -g 完成后我们利用命令行生成项目： mkdir s3upload express –view=ejs 这里的–view=ejs主要指定ejs作为express的html模版引擎，方便我们的测试. 创建好之后的工程结构如下图： 2. 编写页面UI 这里我们通过引入<script […]

作为DevOps和微服务的深入践行者，Amazon在内部积累了许多持续集成、交付和部署的自动化工具和平台。其中， Apollo作为代码部署的自动化平台，每年进行超过5000万次部署。 为了能够让广大开发者和企业用户使用到功能丰富且久经考验的代码部署平台，在Apollo的经验基础上，AWS发布了自动化部署服务——CodeDeploy。 平台介绍 AWS CodeDeploy旨在帮助用户完成应用的快速部署，按照用户指定的策略将代码部署在一组EC2服务器上。用户策略可以包括集群部署速度、部署事件通知、警报处理策略等。此外，CodeDeploy还可以和弹性负载均衡（Elastic Load Balancer）、自动扩展组（Auto Scaling Group）等服务结合，完成无缝升级和动态部署。 为方便有效地组织部署任务，CodeDeploy设立了三个概念：应用（Application）、部署（Deployment），以及部署配置（Deployment Configuration）。 1）应用程序（Application） 应用程序是部署的核心，由部署组（Deployment Group）和代码修订（Revisions）组成。一个应用可以包含多个部署组，一个部署组又可以包含多台EC2服务器。同时，一个服务器也可以属于多个部署组，因为一个服务器可能同时运行多个应用。 1.1）部署组 创建或修改部署组时，如果添加EC2服务器，可以通过标签（Tag）对已有的EC2服务器进行筛选。所以，在创建EC2时一定要打上标签（Tag），便于在创建应用的部署组时找到对应业务的服务器。 此外，部署组还可以添加自动扩展组（Auto Scaling Group），以及用户自己机房的主机（On-Premise Instance）。 1.2）代码修订 代码修订保存了当前应用涉及到得所有代码，代码的存放位置可以在S3或Github。 如果用户自建代码托管，当需要部署时，可以在工作机上同步代码到本地，然后使用AWS命令行进行打包上传。 aws deploy push –application-name <MyAppName> \       –s3-location s3://<MyBucketName>/<MyNewAppBundleName> \       –source <PathToMyBundle> 上面的命令可以将运行目录下得代码打包上传到S3，同时显示在关联应用的代码修订一栏中。 2）部署（Deployment） 每一次部署都有唯一的ID标记，并保存所有信息，如代码来源、部署时间、目标服务器、部署结果等。并且针对每一台服务器，都可以详细查看部署过程中的事件（如下载程序、安装前检查、 程序启动、安装后检查等7个事件），以便追踪部署的各个步骤。当部署出错时，可以快速定位和排查。 3）部署配置（Deployment Configuration） 部署配置存放了一次部署的服务器台数或百分比，在发起部署时需要指定所需配置。CodeDeploy默认提供了三种配置：一次部署一台、一次部署一半数量的服务器，以及一次完成全部部署。部署发起后，CodeDeploy会按照上述策略进行工作，指导完成部署组内全部服务器的更新。 如果用户要自定义部署策略，建议使用命令行完成。比如下面的例子创建的配置就是一次完成20%的服务器部署。 aws deploy create-deployment-config –deployment-config-name ThreeQuartersHealthy –minimum-healthy-hosts type=FLEET_PERCENT,value=20 此外，CodeDeploy还可以管理物理主机（或第三方主机）。只要在物理主机上安装和配置CodeDeploy Agent，Agent向CodeDeploy注册完成后，CodeDeploy就可以像管理 EC2服务器一样在物理服务器上部署应用。 […]

前言 在4月19号的旧金山AWS技术峰会上，亚马逊CTO Werner Vogels宣布了多项AWS新功能，其中就包括众人期待已久的FPGA实例F1。 F1 实例配有最新的 16 nm Xilinx UltraScale Plus FPGA，目前有f1.2xlarge和f1.16xlarge两种类型，其中f1.2xlarge配备有1个FPGA卡， f1.16xlarge配备有8个FPGA卡。 使用 F1 实例部署硬件加速在许多高性能计算 (HPC) 应用程序中非常有用，可解决需要高带宽、增强型联网和较高计算能力的复杂科学、工程和业务问题。F1 实例尤其适用于有时间要求的应用程序，如临床基因组学、实时视频处理和财务风险分析。 因为这段时间都在学习神经网络，所以F1实例最吸引我的是在FPGA上部署神经网络模型，神经网络的前向计算以高频脉冲的方式同时发生在门电路构成的神经网络单元上，想想都让人激动。 不过FPGA这个东西确实太专业了，入门学习曲线不是一般的陡，启动F1实例运行一个简单的Hello World都需要折腾一番。 所以在这里记录一下自己启动F1实例运行Hello World的过程，供各位参考，希望可以让大家开始开始FPGA的旅程。 启动f1实例 f1实例的启动过程和一般的EC2启动过程类似，有关AWS账号的准备，EC2创建过程的细节请大家参考相关技术文档。以下只列出一些需要注意的地方。 测试时我选择了“弗吉尼亚北部”这个区域，也就是us-east-1区域。 启动f1实例时强烈推荐使用 AWS FPGA Developer AMI 镜像， FPGA Developer AMI 包括一个预先打包的工具开发环境，其中含有用于模拟 FPGA 设计、编译代码及构建和注册 AFI 的脚本和工具。 在启动实例的第一步，选择系统镜像的时候选择“AWS Marketplace”，然后搜索“FPGA”就可以找到FPGA Developer AMI, 该镜像在弗吉尼亚北部区域的ID为：ami-3afc6f2c,镜像选择界面截图如下。 启动过程中注意给你的实例指定一个IAM Role, 后续使用AWS CLI命令行工具的时候就需要配置静态的Access Key和Secret Key了。 还有就是安全组配置，缺省的22号端口保留打开状态，另外建议开3389端口，后续如果你希望使用远程连接的方式使用图形化界面需要用到这个端口。 还有一个不需要再强调的就是你启动的f1实例需要有公有IP。 系统登录 […]

Amazon CTO Werner Vogels曾经在AWS re:Invent大会上提到: 如果把云计算理解成一个执行环境，那么，在这个环境里，函数（即业务逻辑的载体）+数据（即跟业务相关的输入与输出）就是应用的核心，有了Functions、Data、Event这三者，其它任何代码和框架，无非是整个应用的胶水和UI罢了。那么，最理想的情况就是用最少的时间写胶水，将更多的时间投入到核心应用的开发中，甚至，彻底实现整个软件栈的微服务化。 那么能不能做到呢？答案是肯定的。AWS Lambda也在这样的背景下应运而生了，其实在很多人眼里，Lambda是一个具有“革命性”的服务，我本人也非常喜欢Lambda这个服务，因为它给我的感觉是: 轻、快、高可用！能够快速将想法写成代码，并应用到生产，不需要关心底层基础设施的运维。接下来，让我们一起搭建一个serverless的后台！ 【1】AWS Lambda怎么用？ 怎么学习Lambda呢？让我们从一个简单的数学问题开始，10以内乘法和加法运算，获得随机的一个数字。代码有注释，如下: //Node.js尽量全使用严格模式 ‘use strict’; //利用console.log可以将日志自动打到CloudWatch里面 console.log(‘Loading function’); exports.handler = (event, context, callback) => {     //定义一个最小值为2     var min = 2;     //定义一个最大值为10     var max = 10;     //生成一个随机数，乘以最大值，再加上一个最小值     var generatedNumber = Math.floor(Math.random() * max) + min;     //利用callback回调，得到结果。     callback(null, generatedNumber); […]

希腊有一个著名的谷堆悖论。“如果１粒谷子落地不能形成谷堆，２粒谷子落地不能形成谷堆，３粒谷子落地也不能形成谷堆，依此类推，无论多少粒谷子落地都不能形成谷堆。但是，事实并非如此。” 这个悖论说的，就是告诉我们量变产生质变，需要一个明显的分割线。如果说，量是一个量化的数据，质是一个结论的话。那么，数据分析做的，就是要分析量，从而引向“定性”、”定质”。定量的了解历史的规律（“质”），从而预测未来。 近几年，大数据风靡全球，越来越多的企业利用MapReduce，Hive，Spark等计算框架和工具来为自身的业务提供帮助，在AWS上，我们也提供了诸多的服务，帮助用户能够快速地构建起适合自身需求的大数据分析架构，其中，Amazon Redshift是性能优异并且完全托管的PB级别数据仓库服务，提供了标准SQL数据库访问接口，并且可以十分方便地与现有的主流商业智能数据分析工具整合，构建企业级数据仓库。 然而，大部分企业的核心数据都存储在关系型数据库中，如何能够有效地将这部分存量数据以及后续的增量数据导入Redshift中呢？本文介绍一种使用开源的Apache Sqoop工具，帮助我们轻松实现这一过程。 配置步骤: 第一步 准备工作 1.1 修改MySQL中的表结构 为了能够实现增量同步，需要在MySQL表中增加一列时间戳，该列能够自动记录行被插入更新的时间 为了能够实现同步删除操作，需要在MySQL表中增加一列删除记号列，应用对数据库的删除通过标记该列完成，而不是通过传统的delete语句，因为通常对于曾经存在过的数据，也有分析的意义 本例需要同步的表为country，orders，user，其中country表为Mycat中的全局表，在两台RDS mysql1和mysql2中都有全部信息，orders和user表为Mycat中的分片表，信息分布在RDS mysql1和mysql2中 mycat_sequence表是用于记录其他表自增字段信息的功能表，无需同步到Redshift中分析 执行如下语句添加两列 alter table country add ifdelete boolean NOT NULL default 0; alter table country add lastmodified TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMEST AMP; 1.2 创建EMR集群 注意勾选上Hive和Sqoop，同时目前AWS EMR最新的版本为5.4.0，其中对一些组件的版本进行了更新，不过Hive和Sqoop的版本与本文一致 注意选择相应的VPC和子网，子网需要有internet的路由方便之后ssh登入 选择登入的密钥对，Master安全组使用默认的ElasticMapReduce-master，不用修改 启动EMR集群后，修改Master节点的安全组，添加允许公网ssh访问 在EMR界面获取master节点ssh登入的信息 1.3 创建Redshift数据仓库 首先创建Redshift使用的安全组，放行所有源访问5439端口的权限 分别在cn-north-1a和cn-north-1b两个可用区中创建两个子网给Redshift使 用，由于之后会通过公网连接Redshift，这两个子网需要有到internet的路由 在Redshift中创建子网组，选上之前创建的两个子网组 创建Redshift参数组 […]

作为一个开发运维人员，您是否还在为： 1.    如何快速地将新版本应用部署到大批量服务器，无论其是云服务器EC2还是本地服务器？ 2.    如何在部署过程中消除停机时间？ 3.    如何规避易于出错的手工操作？ 4.    在遇到问题时，如何快速回滚？并及时向您发送通知？ 今天，我们很高兴地宣布：AWS的CodeDeploy服务能够助您一臂之力！它能够协助您将应用程序部署到 Amazon EC2 实例和/或非 Amazon EC2 实例的物理或虚拟设备。应用程序包扩：代码、Web 和配置文件、可执行文件、程序包、脚本等可部署的内容。AWS CodeDeploy 支持从 Amazon S3 存储桶和 GitHub 存储库部署应用程序。 您无需更改现有代码即可使用 AWS CodeDeploy。您可以使用 AWS CodeDeploy 控制跨 Amazon EC2 实例部署的速度，并定义要在每个阶段采取的操作。 AWS CodeDeploy 具备下列优势： 自动部署。AWS CodeDeploy 可完全自动部署应用程序，并随您的基础设施进行扩展，让您能够部署到数千个实例。 最大程度减少停机时间。AWS CodeDeploy 可以最大程度地提高应用程序的可用性。支持滚动部署和蓝/绿部署模式。并根据您配置的规则跟踪应用程序运行状况。 停止并回滚。出现错误时，您可以自动或手动停止和回滚部署。 易于采用。AWS CodeDeploy 与平台无关，适用于任何应用程序。您可以轻松重用设置代码。AWS CodeDeploy 还能与您的软件发布过程或持续交付工具链集成。 AWS CodeDeploy 支持如下2种部署模式 就地部署：对部署组中的实例依次执行脱机操作/更新应用/恢复联机的操作，完成滚动部署。 蓝绿部署：创建一组新的替换实例，并安装新版本的应用程序。成功后，切换流量到这些新实例，删除旧实例，完成部署。AWS CodeDeploy 运行您在切换流量之前，对新版本应用程序进行测试。如果发现问题，您可以快速回滚到旧版本。 […]

马曾经是种极为重要的交通工具。 如果大家打算在150年前提供信使服务，就会意味着使用马匹作为交通工具能够带来远超步行的交付效率。当然，大家也必须雇专人照顾马匹、购买饲料并清理马厩——但这一切在马匹带来的速度优势面前简直不值一提。随着时间的推移，饲养马匹带来的相关技能将使得大家建立起自己的完整业务系统，从而更为高效地处理各类突发事件。 然而接下来汽车出现了，马匹作为交通工具的使命开始逐步被历史所淘汰。 当然，这一过程并非一蹴而就。第一辆行驶在街头的汽车并不会让您立刻破产。而且尽管汽车已经越来越多被主流所接受，大家仍然拥有一定的比较优势，证明并无转投汽车邮递方向的必要。然而，一旦以车辆为主要工具的同类企业开始出现，您的大麻烦将很快由可能变为现实。 在CrowdTangle公司，我们构建起一系列全球领先的工具选项，旨在帮助人们对社交媒体中的信息动态加以追踪。我们拥有一支工程师与才会人员团队，负责引导各大媒体企业、大联盟队伍以及其他用户找到其最关心的实时信息。更重要的是，我们的公司建立于2011年，并在过去五年中一直在使用AWS。我们过去曾经、未来也将坚信AWS能够作为我们建立完整业务的稳固基石。 AWS对我们而言就如汽车一般。 这样的比喻看似夸张，但其实非常客观。立足于AWS，我们得以建立起一套完全不同于以往五年的组织形式。具体来讲，AWS在四大主要方面对我们产生了影响：业务模式、人员聘用、规划以及速度——当然，这一切总结起来都可以归纳为“成本”二字，进而推衍为“生存”。 首先是商业模式。当最初建立这家企业时，我们并没有考虑利用物理介质承载我们的软件，亦没有考虑建立自己的基础设施。相反，我们选择了软件即服务（简称SaaS）这一模式，并借此获得了大量直接性收益：我们能够允许用户单纯通过访问网站的方式试用我们的产品; 我们能够在一天之内发布数十项功能与修复方案; 我们亦能够确保每位用户皆具备同样的受控使用体验。不过更重要的是，要交付业务产品，我们过去必须在起步时即承担沉重的资本支出。但在AWS的帮助下，我们无需此类初始成本即可让SaaS成为一种可行的发展选择，并在业务增长的同时不断扩大规模。 其次是人员招聘。AWS提供Amazon关系数据库服务（简称Amazon RDS），这是一项托管数据库服务，意味着我们不再需要雇用数据库管理员即可将该服务直接交付开发者使用（且使用英特尔至强E5处理器，代表性能质量亦可得到保证）。另外，AWS还拥有Elastic Beanstalk，这项服务允许我们更为轻松地在AWS之上部署自有应用程序，从而为前端及后端服务器设置独立环境并以一键式操作对其分别加以扩展。再有，AWS的托管NoSQL数据库服务Amazon DynamoDB使得我们不再需要四名全职工程师专门负责数据库的连接与运转。我们拥有TB级别的实时数据，可在个位数毫秒之内完成响应，而且在我个人看来该服务完全能够实现自我维护。在此基础之上，我的团队能够专注于考量如何推动业务发展，而不再需要为保持系统正常运作而分神。 第三项为规划。如果大家仍然生活在以马匹作为主要交通工具的时代，那么资源采购模式无疑是根据自身能力尽可能多地进行设备买入，直到您清楚地发现当前资本支出已经超过企业的承受能力。另外，大家需要研究各类新型设备、联系供应商、投入大量资金、等待设备发货、进行现场安装，并在其性能无法满足需求时尝试转售以收回一点成本。但在汽车时代下，如果我认为企业需要更多设备资源，则可在很短时间之内申请一项实例，并按小时为这一立即可用的资源支付成本。在相关任务完成之后，我可以关闭该实例并不再承担任何后续成本。更重要的是，实例本身的具体规模并不重要——我们完全可以根据需求申请与之匹配的资源容量。 最后，我想聊聊速度这个话题。由于我们选择在AWS之上建立自己的解决方案，因此我们得以拥有一支敏捷、能够快速交付资源并主要关注项目本身而非被迫思考系统维护工作的团队。我们不仅能够在业务范围内的项目进行快速转换，同时亦可以低成本方式实现探索性思路的实验性实施。每个新项目既可能中途失败，亦可能成为我们的下一款百万美元级产品——且二者在初始阶段完全相同，包括建立设想、克隆现有环境、建立项目分支、以实验性方式向客户交付并在获得好评后全面推向市场。 我们最近发现系统聚合部分的处理速度比预期更慢，因此我们开始尝试将其转移至Amazon Redshift。为了实现这一目标，我们首先申请了一个小型Redshift实例（注：未进行规划），并在完成初步测试之后将整体生产数据库复制到Redshift当中（注：研发速度）。“生产”性实验证明这一举措确实能够带来可观收益，因此我们为自己的系统建立起一整套辅助Amazon Kinesis-Redshift托管通道（注：尽管新增系统，但未招聘任何额外人员），而此举最终让我们获得了此前根本无法想象的新产品研发能力。那么这一切在传统模式下需要耗费多少成本？需要采取怎样的执行方式？项目中的各项因素能否拥有受控规模以保证不致造成巨大损失？我们总是从小笔投入着手，而正是这一点让我们能够保持所在业务领域的领导地位。 毫无疑问，未来的竞争对手必然同样借助汽车作为业务基础——在这样的历史背景下，单凭马匹如何在对抗中取胜？ 欲了解更多关于CrowdTangle公司的信息，请点击此处参阅我们的官方网站。