才发现简书有每日更新挑战，可以试着参加呦！！！
参加简书每日更新

场景：

一家公司再具有Amazon EBS存储的单个m4.2xlarge Amazon EC2实例上运行遗留系统Web服务器。
还有自我管理的Oracle数据库，每12小时对EBS卷进行一次快照。
并从完全配置的EC2实例间建AMI。
最近终止EC2实例的事件导致数小时的停机时间。
该应用程序已从AMI成功启动，但EBS快照的存续时间和数据库的修复导致丢失了8个小时的数据。
在系统操作员手动执行这些过程的同事，系统也停机了4个小时
问：哪些体系结构更改将最大程度地减少停机时间并减少丢失数据的机会？

解决方案

• A
  创建一个Amazon Cloud Watch警报，以自动恢复实例，创建一个脚本，该脚本将在重新启动后检车并修复数据库，将Operations团队订阅到Cloud Watch警报生成的Amazon SNS消息
• B
  在Elastic Load Balance[ELB]/Application Load Balancer[ALB]之后的m4.xlarge EC2实例上运行应用程序，跨多个可用区Auto Scaling组中运行EC2实例，实例数量最少为2。将数据库迁移到Amazon RDS Oracle Multi-AZ数据库实例中
• C
  在Elastic Load Balance[ELB]/Application Load Balancer[ALB]之后的m4.2xlarge EC2实例上运行应用程序。在Auto Scaling组中运行EC2实例，以最少一个实例数访问多个可用区。将数据迁移到Amazon RDS Oracle Multi-AZ数据库实例
• D
  将Web服务器实例数增加到两个m4.xlarge实例，并使用Amazon Route 53 循环负载均衡分散负载在Web服务器上，启用Route 53健康检查，将数据迁移到Amazon Oracle Multi-AZ数据库实例

知识点分析

Amazon EBS

Amazon Elastic Block Store (EBS) ，是一种易于使用的高性能的块存储服务。旨在与Amazon Elastic Compute Cloud (EC2) 一起使用，适用于任何规模的吞吐量和事务密集型工作负载

卷类型

• SSD卷：
  适用于数据库、虚拟桌面和启动卷等事务型工作负载
  包括的类型：io1、io2、gp3、gp2
  io(Provisioned IOPS)类型：事务型应用程序
  gp(General Purpose)：通用性卷
• HDD卷：
  适用于 MapReduce 和日志处理等吞吐量密集型工作负载
  包括的类型：st1、sc1
  st(throughput) :吞吐量优化型
  sc(Cold):冷数据（访问频次小）

EC2实例

Amazon Elastic Compute Cloud.是一种 Web 服务，能在云中提供安全且可调整大小的计算能力

m4.2xlarge

m4是EC2类型中的通用型，xlarge与2xlarge硬件二倍关系，数越大性能越好，还有4xlarge\10xlarge\16xlarge

AMI

Amazon 系统映像 (AMI) 提供启动实例所需的信息。在启动实例时，您必须指定 AMI。在需要具有相同配置的多个实例时，您可以从单个 AMI 启动多个实例。

Amazon Cloud Watch

收集：日志、内置指标、自定义指标、容器指标和日志、Lambda指标和日志
监控：控制面板、复合报警、高精度报警、关联日志与指标、容器Lambda检测、异常检测

ELB

自动分配传入的应用程序流量。它可以在单个可用区内处理不断变化的应用程序流量负载，也可以跨多个可用区处理此类负载。
四种类型：

Application Load Balancer (ALB)
Network Load Balancer
Gateway Load Balancer
Classic Load Balancer

Auto Scaling

可以监控您的应用程序并自动调整容量，从而以尽可能低的成本来保持稳定、可预测的性能。

Amazon RDS

是一项适用于 MySQL PostgreSQL MariaDB Oracle BYOL 或 SQL Server 的托管关系数据库服务。

Multi-AZ

多可用区。Availability Zone

Route 53

是一种高可用、高扩展性的云DNS服务。

Route 53健康检查

当响应查询时，Route 53 可忽略未通过运行状况检查的资源

分析场景

要求1：最大程度地减少停机时间。引申为架构需要高可用
要求2：并减少丢失数据的机会。

分析解决方案

• A.
  不是高可用架构
• B.
  有负载均衡，有2个EC2实例
• C.
  至少一个EC2实例， 如果是一个就不是高可用架构了
• D.
  Route53不能循环负载均衡，Route53有加权路由可设置50/50的权重，但是没有自动扩展，Auto Scaling支持自动扩展
  所以最后选择解决方案B来满足。

尾巴

不要害怕学习，知识没有重量，它是你随时可以获取的又随时可以携带的宝库。