相信看了前面文章的同学，必然已经对AWS能够提供的强大服务，有了一定的了解，本章继续为大家介绍亚马逊云计算的第二部分，若是没有看到前面文章的同学，可以从这里直接跳转到前面一篇文章。

嘿咻：云计算工程师带你玩转亚马逊云服务系列-1总体介绍第一部分?

zhuanlan.zhihu.com图标

本章的只要内容如下：

  • Cloudfront
  • Elastic load balancing
  • EBS
  • Cloudwatch
  • CloudTrail
  • Config as code: troposphere/cloudformation/teraform

CloudFront:

官方介绍：

Amazon CloudFront 是一个 Web 服务，它加快将静态和动态 Web 内容（如 .html、.css、.js 和图像文件）分发到用户的速度。CloudFront 通过全球数据中心网路传输内容，这些数据中心称为边缘站点。当用户请求您用 CloudFront 提供的内容时，用户被路由到提供最低延迟 (时间延迟) 的边缘站点，从而以尽可能最佳的性能传送内容。

  • 如果该内容已经在延迟最短的边缘站点上，CloudFront 将直接提供它。
  • 如果内容没有位于边缘站点中，CloudFront 从定义的源中检索内容，例如，指定为内容最终版本来源的 Amazon S3 存储桶、MediaPackage 通道或 HTTP 伺服器（如 Web 伺服器）。—

例如，假设您要从传统的 Web 伺服器中提供图像，而不是从 CloudFront 中提供图像。例如，您可能会使用 URL http://example.com/sunsetphoto.png 提供图像 sunsetphoto.png。

您的用户可以轻松导航到该 URL 并查看图像。但他们可能不知道其请求从一个网路路由到另一个网路（通过构成 Internet 的相互连接的复杂网路集合），直到找到图像。——

CloudFront 通过 AWS 主干网路将每个用户请求传送到以最佳方式提供内容的边缘站点，从而加快分发内容的速度。通常，这是向查看器提供传输最快的 CloudFront 边缘伺服器。使用 AWS 网路可大大降低用户的请求必须经由的网路数量，从而提高性能。用户遇到的延迟（载入文件的第一个位元组所花的时间）更短，数据传输速率更高。——

您还会获得更高的可靠性和可用性，因为您的文件（也称为对象）的副本现在存储（或缓存）在全球各地的多个边缘站点上。

我个人在具体使用当中其实并没有感觉到用户方面得到了巨大的提升， 可能需要日活用户非常巨大网站使用起来会更加的合适，提升的benefit也会更加的明显。

Elastic load balancing：

Elastic Load Balancing 在多个目标（如 Amazon EC2 实例、容器、IP 地址和 Lambda 函数）之间自动分配传入的应用程序流量。它可以在单个可用区内处理不断变化的应用程序流量负载，也可以跨多个可用区处理此类负载。Elastic Load Balancing 提供三种负载均衡器，它们均能实现高可用性、自动扩展和可靠的安全性。

那么整个ELB的组成部分主要有三个

分别是：

  • application load balancer： Application Load Balancer 最适合 HTTP 和 HTTPS 流量的负载均衡，面向交付包括微服务和容器在内的现代应用程序架构，提供高级请求路由功能。Application Load Balancer 运行於单独的请求级别（第 7 层），可根据请求的内容将流量路由至 Amazon Virtual Private Cloud (Amazon VPC) 内的不同目标。
  • 网路负载均衡器： 若要对需要极高性能的传输控制协议 (TCP) 和传输层安全性协 (TLS) 流量进行负载均衡，最适合使用网路负载均衡器。网路负载均衡器运行于连接级别（第 4 层），可将流量路由至 Amazon Virtual Private Cloud (Amazon VPC) 内的不同目标，每秒能够处理数百万请求，同时能保持超低延迟。网路负载均衡器还针对处理突发和不稳定的流量模式进行了优化。
  • Classic Load Balancer： Classic Load Balancer 同时运行于请求级别和连接级别，可在多个 Amazon EC2 实例之间提供基本的负载均衡。Classic Load Balancer 适用于在 EC2-Classic 网路内构建的应用程序。

EBS:

什么是EBS， 简单的来说就是如果你想同时运行很多的ec2 instances，但是不想支付过于昂贵的存储价格，因为不同的EC2 instances之间的价格差异其实是很大的，那么在这种情况下，选择ebs就是一个明智的决定。

下面是详细的介绍：

Amazon Elastic Block Store (Amazon EBS) 可在 AWS 云中提供用于 Amazon EC2 实例的持久性块存储卷。每个 Amazon EBS 卷都会在其可用区内自动复制，以保护您免受组件故障的影响，同时提供高可用性和持久性。Amazon EBS 卷为您提供处理工作所需的稳定低延迟性能。通过 Amazon EBS，您可在几分钟内调整用量大小 - 所有这些您只需为配置的资源量支付低廉的价格。

Amazon EBS 设计用于优化性能、成本和容量即可受益的应用程序工作负载。典型使用案例包括：大数据分析引擎（如 Hadoop/HDFS 生态系统和 Amazon EMR 集群）、关系和 NoSQL 资料库（如 Microsoft SQL Server 和 MySQL 或 Cassandra 和 MongoDB）、流和日志处理应用程序（如 Kafka 和 Splunk），以及数据仓库应用程序（如 Vertica 和 Teradata）。

个人的一些想法：

我在使用EBS的时候，是直接mount在对应的ASG，也就是auto scaling group里面的，那么每一个autoscaling group里面所spin up起来的instances/asg都会拥有相同的EBS，不仅仅是相同的performance，并且拥有相同的大小和价格。并且EBS也可以通过直接在terraform或者cloudformation中进行定义，config as code deployment非常方便。最令人惊喜的是它的价格，确实足够低廉。对EBS感兴趣的朋友可以直接搜索了解。

Cloudwatch：

官方定义：

Amazon CloudWatch 是一种面向开发人员、系统操作员、网站可靠性工程师 (SRE) 和 IT 经理的监控和管理服务。CloudWatch 为您提供相关数据和切实见解，以监控应用程序、了解和响应系统范围的性能变化、优化资源利用率，并在统一视图中查看运营状况。CloudWatch 以日志、指标和事件的形式收集监控和运营数据，让您能够在统一视图中查看 AWS 资源以及在 AWS 和本地伺服器上运行的应用程序和服务。您可以使用 CloudWatch 来设置高精度警报、并排显示日志和指标、采取自动化操作、排查问题，以及发现能够优化应用程序并确保其正常运行的见解。

我的理解：

Cloudwatch可以说是我在和aws打交道的过程中使用最为频繁的一个服务，因为所有的lambda function，sqs，sns的log（日志）都会存储在这个cloudwatch服务里面。每一个lambda function执行完之后，都会列印对应的log到cloudwatch下面，只需要直接去cloudwatch-》log->lambda function里面寻找，就可以找的到对应的log.

除了日志之外，cloudwatch还提供了alarm功能，不仅仅可以检测目前的特定ASG-auto scaling group中instances的状态，同时还可以trigger ASG中相应的action。

举个例子，比如说小张想要让特定的ASG在所有的instances cpu平均用量超过50%的时候scale out instance，这样的话，就可以有效的避免当用户的访问量明显上升的时候，对应的server供应量却没上去的尴尬。而且每个ASG可以通过cloudwatch alarm给出的值的不同，进行不同范围或者说力度的调整，在ASG中被称为step scaling。更为强大的是，cloudwatch的alarm不仅仅只限于Cpu 用量，平均空闲时长等default的值，还可以通过Boto3（一种aws支持的python library）去定制你所需要的任意metric作为alarm。

Cloudtrail：

官方介绍：

AWS CloudTrail 是一项支持对您的 AWS 账户进行监管、合规性检查、操作审核和风险审核的服务。借助 CloudTrail，您可以记录日志、持续监控并保留与整个 AWS 基础设施中的操作相关的账户活动。CloudTrail 提供 AWS 账户活动的事件历史记录，这些活动包括通过 AWS 管理控制台、AWS 开发工具包、命令行工具和其他 AWS 服务执行的操作。这一事件历史记录可以简化安全性分析、资源更改跟踪和问题排查工作。

个人感觉Cloudtrail一个相较于cloudwatch更为强大但是更为复杂的服务，在之后的系列文章中，我会邀请在亚马逊cloudtrail组的朋友介绍cloudtrail的架构和服务特点。

Config as code: troposphere/cloudformation/teraform:

官方介绍：

AWS CloudFormation 为您提供了一种通用语言来描述和预配置您的云环境中的所有基础设施资源。CloudFormation 使您可以跨所有地区和账户使用简单的文本文件以自动化的安全方式为您的应用程序需要的所有资源建模并对其进行预配置。该文件是您的云环境的单一信任源。

我的理解：

首先，cloudformation是完全免费的。你可以放心大胆的在上面创建stack，无数次的deploy

那么究竟为什么要使用cloudformation，或者terraform来进行deployment呢？

如果说你现在有一个start up只有十几台ec2 instance server，可能还有几个lambda function还有一个API gate way作为后端，前段甚至是hosting在S3的static host 上面，在这种情况下，的确，没有必要config as code或者进行自动化部署。

但是如果你有了五六个autoscaling gourp， 每个里面有一百台instances以上，同时你还有这几百个lambdafunction以及sqs queue，这种情况下，每次update可能都会要了你的半条命。

所以说，config as code是整个infra做大做强，乃至是整个公司做大做强的必要条件。

如果说你问我我推荐troposphere或者cloudformation和terraform中的哪一个。我会推荐troposphere。有以下的几个原因。

  1. troposphere是完全免费，开源的第三方的python lib，你不必为其付费
  2. troposphere本质上是为cloudformation 生产出其所需的文本，只不过通过自动化的方式实现，因为如此，troposphere和aws的兼容性个好一些

请永远记住，config as code如同写unit test一样，是开发效率提升的一个关键，请先实现了config as code再继续扩张你的项目规模。

我们在之后会有一个专门的文章介绍troposphere一个小项目来帮助大家熟悉和了解使用的方法。


推荐阅读：
相关文章