SQS (Simple Queue Service)简介
Amazon Simple Queue Service (SQS)是一种完全托管的消息队列服务，可以让你分离和扩展微服务、分布式系统和无服务应用程序。
在讲解SQS之前，首先让我们了解一下什么是消息队列。
消息队列
还是举一个电商的例子，一个用户在电商网站下单后付款后，应用服务器马上查询/更新数据库，连接支付网关并查询支付状态，通知短信/邮件网关发送相关短信/邮件，更新库存系统，更新物流系统……最后返回信息给用户，“您的下单已成功”。
但是如果网站的访问数很大，或者正值促销活动（比如淘宝双11，京东618）呢？
这个时候每一个流程都是一个瓶颈，一旦某一个地方达到了瓶颈或者出现故障，又或者用户下单的时间比程序处理订单的时间还要久的情况下，都会让用户得不到成功下单的结果，或者得到结果的时间非常长，导致用户体验不好。
这个时候，我们就要考虑到应用程序的解耦（decouple）。
我们可以引入消息队列，让不同的应用程序之间打断强连接的关系，互不干扰。
应用服务器在接收到用户付款的订单之后，就把相关的信息丢到消息队列，并且返回用户“您的下单已成功，请稍后查看详细订单状态”。
而支付网关、短信/邮件网关、库存系统、物流系统等等可以到消息队列里面拉取信息，并且进行相关的数据更新和操作。
这些操作可能不需要是实时的，但是至少能保证这些队列里的信息最终都会被执行。比如下单后我不一定马上能收到短信/邮件的通知，我可能5分钟/10分钟之后才收到这些信息通知，但这个并不影响正常的业务。
这样子，消息队列就起到了连接上层业务和下层业务的作用。
Amazon SQS相当于提供了一个分布式、高可用、高性能的消息队列服务。
SQS特点
SQS有两种不同类型的队列，它们分别是：
- 标准队列（Standard Queue）
- FIFO队列（先进先出队列）
标准队列
标准队列拥有无限的吞吐量，所有消息都会至少传递一次，并且它会尽最大努力进行排序。
标准队列是默认的队列类型。
FIFO队列
FIFO (First-in-first-out)队列在不使用批处理的情况下，最多支持300TPS（每秒300个发送、接受或删除操作）。
在队列中的消息都只会不多不少地被处理一次。
FIFO队列严格保持消息的发送和接收顺序。
更多关于标准队列和FIFO队列的区别，可以查看我需要哪种类型的队列？
SQS的其他特点
- SQS是靠应用程序去拉取的，而不能主动推送给应用程序，推送服务我们使用SNS（Simple Notification Service）
- 消息会以256 KB的大小存放
- 消息会在队列中保存1分钟~14天，默认时间是4天
- 可见性超时（Visibility Timeout）
- 即当SQS队列收到新的消息并且被拉取走进行处理时，会触发Visibility Timeout的时间。这个消息不会被删除，而是会被设置为不可见，用来防止该消息在处理的过程中再一次被拉取
- 当这个消息被处理完成后，这个消息会在SQS中被删除，表示这个任务已经处理完毕
- 如果这个消息在Visibility Timeout时间结束之后还没有被处理完，则这个消息会设置为可见状态，等待另一个程序来进行处理
- 因此同一个消息可能会被处理两次（或以上）
- 这个超时时间最大可以设置为12小时
- 标准SQS队列保证了每一个在队列内的消息都至少会被处理一次
- 长轮询（Long Polling）
- 默认情况下，Amazon SQS使用短轮询（Short Polling），即应用程序每次去查询SQS队列，SQS都会做回应（哪怕队列一直是空的）
- 使用了长轮训，应用程序每次去查询SQS队列，SQS队列不会马上做回应。而是等到队列里有消息可处理时，或者等到设定的超时时间再做出回应。
- 长轮询可以一定程度减少SQS的花销
SNS (Simple Notification Service)简介
SNS (Simple Notification Service) 是一种完全托管的发布/订阅消息收发和移动通知服务，用于协调向订阅终端节点和客户端的消息分发。
和SQS (Simple Queue Service)一样，SNS也可以轻松分离和扩展微服务，分布式系统和无服务应用程序，对程序进行解耦。
我们可以使用SNS将消息推送到SQS消息队列中、AWS Lambda函数或者HTTP终端节点上。
SNS通知还可以发送推送通知到IOS，安卓，Windows和基于百度的设备，也可以通过电子邮箱或者SMS短信的形式发送到各种不同类型的设备上。
SNS的一些特点
- SNS是实时的推送服务（Push），有别于SQS的拉取服务（Pull/Poll）
- 拥有简单的API，可以和其他应用程序兼容
- 可以通过多种不同的传输协议进行集成
- 便宜、用多少付费多少的服务模型
- 在AWS管理控制台上就可以进行简单的操作
SNS能推送的目标
- HTTP
- HTTPS
- Email-JSON
- SQS
- Application
- Lambda
SWF (Simple Workflow Service)简介
Amazon Simple Workflow Service (Amazon SWF) 提供了给应用程序异步、分布式处理的流程工具。
SWF可以用在媒体处理、网站应用程序后端、商业流程、数据分析和一系列定义好的任务上。
举个例子，下图表明了一个电商网站的工作流程，其中涉及了程序执行的过程和人工执行的过程（第三步）。
当用户在电商网站上下单后，即启动了该流程，该流程包含了4个任务（tasks）：
- SWF验证用户订单信息
- 如果订单有效，则进行信用卡付款流程
- 如果付款完毕，则进行人工发货
- 如果发货完成，则保存订单信息到数据库，并结束流程
在这个流程中，每一个任务都是按顺序执行的，只有当上一个任务成功完成后才能执行下一个任务。
SWF除了支持顺序执行的流程之外，也支持并行处理的流程，即一个任务的完成可以触发多个任务同时执行。
基本的SWF概念
- SWF发起者（Starter）
- 可以激活一个工作流的应用程序，可能是电商网站上下单的行为，或者是在手机APP上点击某个按钮
- SWF决策者（ Decider）
- SWF Decider决定了任务之间的协调，处理的顺序，并发性和任务的逻辑控制
- SWF参与者（Worker）
- SWF Worker可以在SWF中获取新的任务，处理任务，并且返回结果
- SWF域（Domains）
- 域包含了工作流的所有组成部分，比如工作流类型和活动类型
SWF决策者和参与者可以是运行在AWS上的EC2实例或者其他计算资源，SWF只是保存不同的任务，把这些任务分配给worker，并且监控他们的任务处理进展。
SWF和SQS的区别
- SWF是面向任务的；SQS是面向消息的；
- SWF保证了每一个任务都只执行一次而不会重复；标准的SQS消息可能会被处理多次
- SWF保证了程序内所有任务都正常被处理，并且追踪工作流；而SQS只能在应用程序的层面追踪工作流
- SWF内的任务最长可以保存1年；SQS内的消息最长只能保存14天
更多关于SWF的内容可以查看官方文档Amazon SWF 简介
API Gateway简介
Amazon API Gateway可以让开发人员创建、发布、维护、监控和保护任何规模的API。你可以创建能够访问 AWS、其他 Web 服务以及存储在 AWS 云中的数据的API。
API Gateway没有最低使用成本，我们用多少服务内容就花费多少。
比如在最新的A Cloud Guru的serverless 会议上面提到了，他们整个网站都是基于API Gateway和Lambda的，并没有任何计算服务器（EC2，ECS等），永远不用担心性能和扩容的问题。并且他们每个月的花销只是580美金！
API Gateway和Lambda的结合可以构成如下图所示的无服务（Serverless）架构。
关于API Gateway，我们需要了解这些
- 理解什么是API Gateway，它能用来做什么
- API Gateway可以缓存内容，从而更快地将一些常用内容发送给用户
- API Gateway是一种低成本的无服务（serverless）方案，而且它可以自动弹性伸缩（类似ELB，NAT网关）
- 可以对API Gateway进行节流，以防止恶意攻击
- 可以将API Gateway的日志放到CloudWatch中
- 如果你使用JavaScript/AJAX来跨域访问资源，那么你需要保证在API Gateway上已经开启了CORS (Corss-Origin Resource Sharing)功能
- 如果没有开启CORS功能，在使用API Gateway做跨域访问的时候，可能会出现错误 “Origin policy cannot be read at the remote resource?”
- 我们在S3的课程中也介绍过CORS的功能，可以参见S3的课程
Elastic Transcoder简介
Amazon Elastic Transcoder是一种在线媒体转码的工具，使用它我们可以很容易地将我们的视频从源格式转换到其他的格式和分辨率，以便在手机、平板、PC等设备上播放。
一般来说，我们会将需要转码的媒体文件放在AWS S3的存储桶上，创建相应的管道和任务将文件转码为特定的格式，最后将文件输出到另一个S3的存储桶上面去。
我们也可以使用一些预设的模板来转换我们的媒体格式。
另外，我们也可以配合Lambda函数，在有新的文件上传到S3后触发函数代码，执行Elastic Transcoder并自动进行媒体文件的转码。
Kinesis简介
Amazon Kinesis可以让你轻松收集、处理和分析实时流数据。利用Amazon Kinesis，你可以在收到数据的同时对数据进行处理和分析，无需等到数据全部收集完成才进行处理。
在深入了解Kinesis之前，我们先来看看什么是数据流。
数据流
数据流是从成千上万的数据源上持续产生的数据，并且这些数据都很小（KB级别），它们可能是：
- 电商网站上的订单信息（比如京东，淘宝）
- 股票信息
- 游戏信息
- 社交网络信息（微信/微博的信息流）
- 地理位置信息（滴滴）
- 物联网数据
Kinesis服务
Kinesis目前有不同的功能服务，我们需要了解每一个服务有什么不同。这些服务分别是：
- Kinesis Data Streams (Kinesis Streams)：使用自定义的应用程序分析数据流
- Kinesis Video Streams：捕获、处理并存储视频流用于分析和机器学习（Machine Learning）
- Kinesis Data Firehose：将数据加载到AWS数据存储上
- Kinesis Data Analytics：使用SQL分析数据流
Kinesis Data Streams
Amazon Kinesis Data Streams可以实时收集和处理大型数据流，这些数据会被处理并且发送到多种AWS服务中去，也可以生成报警、动态更改定价和广告战略等。
如图所示，创建者（Producer）会持续将数据推送到Kinesis Data Streams中，这些创建者包括了EC2实例、用户的PC终端、移动终端，服务器等。
Kinesis Data Streams由一组分片（Shards）组成，每个shards都有一系列的数据记录，每一个数据记录都有一个分配好的序列号。
数据记录在添加到流之后会保存一定的时间，这个保留周期（Retention Period）默认是24小时，但可以手动设置为最多7天。
使用者（Comsumer）会实时地对Kinesis Streams里的内容进行处理，并将最终结果推送到AWS服务，例如Amazon S3，DynamoDB，Redshift，Amazon EMR或者Kinesis Firehose。
Kinesis Video Streams
Kinesis Video Streams主要用来进行实时的视频处理，或者批量进行视频分析。
Kinesis Video Streams可以捕获来自多种设备类型的视频流数据（比如智能手机、网络摄像头、车载摄像头、无人机等）。
其工作的流程和Data Streams类似，如下图所示。
Kinesis Data Firehose
Kinesis Data Firehose可以让我们的实时数据流传输到我们定义的目标，包括Amazon S3，Amazon Redshift，Amazon Elasticsearch Service (ES)和Splunk。
如下图所示，通过Kinesis Firehose，我们可以将数据流经过转换之后传输到S3存储桶上去，并且另外将源数据备份一份到另一个S3存储桶。
Kinesis Data Analytics
使用Kinesis Data Analytics，我们可以使用标准的SQL语句来处理和分析我们的数据流。这个服务可以让我们使用强大的SQL代码来做实时的数据流分析、创建实时的参数。