亚马逊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)。在部署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有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) 这本书也给了同样的解释。总结就是：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服务。当然还有很多其他的服务，比如安全，大数据，深度学习等等相关，都没有涉及，因为自己了解不多或者根本没用过。本篇文章提供的链接均真实有效，希望提供的内容对大家有所帮助。如果有错误不当之处，麻烦指出来，我会一一改进。