亚马逊 AWS 有什么用呢？

在 Amazon 工作的四年间，有幸在 AWS 呆过两年。在此之前，对云一直很感兴趣，但没有具体的概念，也没有详细地了解过。日常听到的都是阿里云，腾讯云，国外的也就是 AWS。来到 AWS 后，真正深入的去用云、做云、了解云服务的特性，才认识到云的博大精深。就行业现状，AWS 当然是业界 No.1，跟随其后就是 Azure、GCP，国内以阿里云为龙头，后面就是腾讯云。虽然市场份额有差别，但我相信各个云厂商提供的服务都大同小异。

在 AWS 两年所学甚多，这里我想从一个资深用户的角度去讲解下 AWS。云的基础是计算、存储、网络，这三部分涵盖了互联网应用的各个方面，所有的云服务也是围绕这三部分去展开。把这三部分完全展开是不现实的，而且我也没有资深到了解 AWS 服务的各个方面。所以我打算从如何建立一个通用的互联网应用出发，去分解 AWS 的各个部分。

AWS 的服务是按照 region 来划分的，在部署自己的应用之前，需要选择 region，比如美国有 us-west, us-east regions, 中国有 cn-north, cn-west regions。基本上按照服务用户所在的区域来选择 region，服务中国的用户就选择中国的 region，服务美国的用户就选择美国的 region。否则这个网络传输的成本就非常高，而且中国区其独有的网络环境，导致其他地区的服务是无法访问的。一个 region 又划分为多个 AZ (availability zone), 一般情况下，我们需要把服务器均匀分布在多个 AZ，为了避免单点故障，也就是我们所说的灾备多活。

选择好 region 后，就需要部署自己的VPC (virtual private cloud)，一个 VPC 定义了一个私有隔离的网络环境。在 VPC 里面，我们部署所有的计算、网络资源。计算资源就是我们的服务器，AWS 最出名的就是EC2 ([elastic compute cloud](<https://www.zhihu.com/search?q=elastic compute cloud&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={"sourceType":"answer","sourceId":2333079486}>))。在部署 EC2 时，我们首先预估应用需要消耗的计算资源(cpu，磁盘，带宽等等)，选择 EC2 的型号和数量。然后将所有的 EC2 分割成多个ASG (auto scaling group), 一个 ASG 就相当于一个可弹性收缩的机器群，只要定义好扩容和缩容的指标，ASG 就可以自己分配机器的数量。比如我们要求在 EC2 CPU 升到 40%就扩容一倍，在 CPU 降到 10%就缩容一倍，这样一个 ASG 里面机器 CPU 的消耗就一直均衡地保持在 20%左右。具体分割成几个 ASG，一般依据这个 region 有几个 AZ 来定，比如[us-east-1 region](<https://www.zhihu.com/search?q=us-east-1 region&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={"sourceType":"answer","sourceId":2333079486}>)有 3 个 AZ，就分割成三个 ASG，一个 AZ 部署一个 ASG，这三个 ASG 在接受流量方面没有任何区别。接下来就是网络资源，每个 VPC 都有自己的 ACL(acess control list)，一个 ACL 定义了 inbound rules 和 outbound rules，分别限制了访问 IP 的限制和访出 IP 的限制。VPC 的网络资源被划分成多个子网 subnets，一个 subnet 是一组 IP 地址的集合，前面说到的 ASG 就部署在subnet里面。一般来说 subnet 的数据量跟 region AZ 的数据成正比，每个 AZ 分配一个 public subnet 和一个 private subnet，那么 us-east-1 的 VPC 就会有 6 个 subnets。我们将 ASG 部署在 private subnet 里面，只允许 vpc 内部的 IP 访问，用于保护机器资源。因为 public subnet 是对外的，所以我们在 public subnet 里面部署 ELB (elastic load balancer)，用于接受 vpc 外的请求。有人会问如果我们想登录到 ASG 的 EC2 上面，应该怎么做？解决办法是在 public subnet 里面 launch 一个跳板机，我们先登录到跳板机，然后从跳板机里面登录到 EC2 上面。

接下来就是存储资源，AWS 提供多种选择，我们最熟悉的应该就是S3 (simple storage service)。S3 是面向对象存储的服务，可以用来做数据归档、备份、恢复，或者作为数据分析、AI、Machine learning 的数据湖来使用。通俗的理解就是我们的磁盘，它存储的 key 就是一个目录路径，相当于磁盘的目录，value 是一个 object，相当于文件或者子目录。在线的存储根据功能的不同也有很多选择，比较出名的而且是我用过的有三个。第一个是DynamoDB，它是 document-based NoSQL DB。DynamoDB 是 Amazon 内部使用最频繁的数据，几乎 90%的存储都会选择 DynamoDB，绝对地超过 RDS。这个现象的原因在这篇文章Dynamo: Amazon’s Highly Available Key-value Store里面有解释，同时 DDIA (Design [data-intensive application](<https://www.zhihu.com/search?q=data-intensive application&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={"sourceType":"answer","sourceId":2333079486}>)) 这本书也给了同样的解释。总结就是：Amazon 内部的存储 90%以上都是单对多的关系，DynamoDB 作为一个分布式的key-value DB，在可用性、扩展性方面非常适合这种单对多的存储结构。而且 DynamoDB 是最终一致性，进一步增加了它的可用性。关于 DynamoDB 我后面会单独出一篇介绍它的 blog。而对于多对多的存储，我们就会用RDS (relational database service)，RDS 字面理解就是关系型数据库。AWS RDS 上面托管了多种关系型数据库，包括 mysql、oracle、MS SQL、aurora、MariaDB 和 PostgreSQL 这六种数据库，其中我使用过 mysql 和 aurora。在 Amazon 内部，aurora使用的更频繁，它是兼容 mysql 和 PostgreSQL 的结合体，具体内容可见这篇文章Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases。我使用的最后一种存储是AWS elasticsearch ，当时为了实现一个搜索功能，因为涉及到模糊匹配，全文搜索，就采用了 aws es。aws es 跟主流的 es 已经分道扬镳，目前在 aws 上面称为 openSearch service。

介绍完计算、网络、存储，接下来我想从应用的角度，讲讲在实际应用中，我们应该怎样使用 AWS 的服务。首先说消息队列，这个广泛应用的基础功能，AWS 提供了SQS和SNS。SQS 是一个分布式的队列消息 service，SNS 是一个分布式的发布-订阅消息 service。具体有人会问这两者有什么区别，这里给出了回答: What is the difference between Amazon SNS and Amazon SQS?。 在我的实践中，SQS 和 SNS 会结合起来使用，首先应用发布消息到 SQS 的 queue 里面，然后 SNS 消费这个 queue 的消息，放到自身的 topic 里面持久保存，然后其他的应用订阅这个 topic，消费里面的消息。

建设完一个应用，然后就是 DevOps。AWS 在托管代码、编译代码、部署应用、监控应用方面也提供了一整套服务，从前到后，codeCommit -> codeArtifact -> codeBuild -> codeDeploy -> codePipeline。这一套实现了应用的 continuous integration 和 continuous deployment。在监控方面，AWS 提供了cloudWatch，可以以应用维度收集日志，视图化监控指标。AWS 还提供了一个服务叫 cloudFormation，这个服务在应用迁移的过程中，非常有用。Amazon 内部很多都是国际化业务，应用需要部署到各个 region。cloudFormation 以 yaml 文本的形式记录下一个应用涉及到的各个服务资源配置，放在一个 template 里面。迁移到不同的 region 时，只需要一键 run coudFormation template, 就可以部署好所有的 AWS 资源。

最近比较火的 serverless function，AWS 在这方面也有很深入的实践。大家最熟悉的应该是lamda，可以让用户在不提供服务器的情况下，将应用 run 起来。用户除了提供代码，其他的资源计算、网络、存储，devOps 一概不需要关心，lambda 会根据流量的大小自动扩缩容。在计费方面，lambda 会根据请求消耗的计算资源来收费，当没有请求进来的时候，就不会收费。Serverless 的另一个服务是stepFunction，它是一个任务状态管理服务，每一个 step 表示一个任务，上个 step 的输出是下个 step 的输入。使用者将输入传递给 stepFunction，经历过所有 step 的处理后，将输出返回给使用者。step 可以是 lambda function，也可以是自己定义的代码。在我的实践中，stepfunction 在异步计算任务中用的比较多。

以上内容，我从搭建一个互联网应用的角度出发，从计算，网络，存储三个方面大概介绍了我所接触的 AWS 服务。当然还有很多其他的服务，比如安全，大数据，深度学习等等相关，都没有涉及，因为自己了解不多或者根本没用过。本篇文章提供的链接均真实有效，希望提供的内容对大家有所帮助。如果有错误不当之处，麻烦指出来，我会一一改进。