AWS经历，激励自己要过掉AWS solution architect associate level certification

附上原图链接点击打开链接，并推荐大家使用Drawio这个工具绘图。以下是我为初创公司设计的架构图，多有不对，希望大家拍砖，努力学习AWS中，希望和大家分享交流，有意向过AWS认证的伙伴，请联系我。闲言少叙，进入主题。

这是一个四层结构的应用架构，其中包括网络层，web服务器层，Redis集群层，数据存储层。另外该架构图中还包括Devops和服务器运行情况指标监控组件和相关流程。

首先是网络层：通过构建VPC虚拟网络，借助VPC中可以指定iP段，路由表以及网关的配置，在一定程度上做到了内外网的安全隔离。当internet用户访问部署在AWS中的服务时，首先会通过Route53实现的DNS域名解析服务，连接到VPC内网EC2实例，确保来自各地的请求能够通过ELB访问到部署在EC2实例的web服务器。于此同时，我在每一层都设计了安全组和子网，能够更加有效提供安全保障机制。

在网络层还有一个重要的服务用来降低用户访问延迟性，那就是使用CloudFront和边缘站点实现网站内容快速分发网络 ，CloudFront能够使的边缘站点缓存静态和动态 web内容，当用户请求CloudFront提供的内容时，用户会被引导到距离最近，延迟最低的节点，以便传送的内容具有最佳性能。如果内容已经在该节点中，CloudFront会立即反馈给用户。如果内容目前不在该节点中，CloudFront 将从web 应用服务或S3存储中对内容进行检索，并反馈给用户。以上就是网络层的架构设计。

EC2安全组可作为虚拟子网和客户端防火墙的一个组合。EC2安全组中的每一个实例都共享着一个通用安全策略；类似于防火墙的规则控制着各个组之间的流量。防火墙的默认行为是拒绝流量的，而特定规则可允许出入站的连接。

—-（还需要了解，如何做到快速响应，和缓存内容，如何保持内容的最新性）以上就是网络层的架构设计

AZ

   AWS的每个区域一般由多个可用区（AZ）组成，而一个可用区一般是由多个数据中心组成。AWS引入可用区设计主要是为了提升用户应用程序的高可用性。因为可用区与可用区之间在设计上是相互独立的，也就是说它们会有独立的 供电、独立的网络等，这样假如一个可用区出现问题时也不会影响另外的可用区。在一个区域内，可用区与可用区之间是通过高速网络连接，从而保证了低延时。

网络层后，接下来就是web应用服务层，通过使用 Auto Scaling与 ELB 集成来实现应用服务的可用性和扩展性，将ELB附加到现有 Auto Scaling组实现负载均衡，它能够自动注册组内的实例，并将传入请求分配给这些实例。 在可用性方面，如果有服务失败宕机，那么auto-scaling 能够迅速发现问题机器并启动一台新的机器，持续服务。在扩展性方面使用 Auto Scaling，可以设置Min/MaX/参数实现自动扩缩 EC2 的服务实例数量。（还要看ELB和AUTOSCALING原理）。

那么在WEB应用服务层后，

Elastic Load Balancing 支持两种类型的负载均衡器：应用程序负载均衡器和传统负载均衡器。通过传统负载均衡器，在负载均衡器中注册实例。通过应用程序负载均衡器，在目标组中将实例注册为目标，并将流量路由到目标组。（还需要解释选择应用程序负载均衡器的理由）

接下来，就是 Redis 缓存集群服务层，这里我使用的是Redis已禁用集群模式（为什么选择），该层的主要职责提高生产部署的可靠性，缓解前端请求对数据库访问的压力，降低延迟，还可以起到防灾、减灾的作用。由于使用了VPC，我们可以使用VPC的安全组和子网策略来控制对缓存群集的访问，Redis 复制组包含一个应用程序可读写入的主节点和 2个只读副本节点。在向主节点写入数据时，也会在只读副本节点上异步更新数据。 这样可以有效的防止节点故障，而在两个可用区各分别部署一个集群服务，主要是为了避免可用区故障。

为什么选择

 •您需要为读取操作密集型应用程序将主群集中的数据复制到一个或多个只读副本。

•您需要在主节点出现故障的情况下执行自动故障转移。

•您需要发布和订阅 (pub/sub)功能 -向客户端通知服务器上发生的事件。

•您需要备份和还原功能。

•您需要支持多个数据库。

最后，就是数据存储层，数据库通常是系统最重要的部分，应用程序如果不能连接到数据库他们将无法工作，该层的主要职责是负责数据库的高可用和高性能的数据存储，一个高可用的数据库通常包含两个数据库实例:一个主数据库和备用数据库。当所有请求发送到主数据库时，由 RDS实例来负责响应服务器请求，完成对数据的读写操作。主和备用数据库之间的数据同步复制。如果主数据库由于硬件或网络故障而不可用时，RDS会自动侦测到故障，启动故障转移过程，备用数据库将成为了主数据库，同时DNS也会自动更新，来实现快速故障转移。

一个高性能的数据库对应用程序的反应效率是至关重要的，我们通过使用高性能的存储类型（IOPS(SSD)）保证数据库提供高性能的读写操作。与此同时，对数据进行有效的保护和存储也是至关重要的，因此考虑到数据库中的数据备份，我们可以通过RDS快照实现数据备份，除此之外，可以利用AWS Datapipeline 实现更加廉价的备份策略，定期执行数据库备份脚本进行备份，并存储在S3数据桶中，来实现数据进行有效的保护和存储。

那么以上就是我设计应用程序架构，接着为大家介绍的是DevOPS架构：

Part 2：DevOp的实现，在我的架构中主要是通过EC2和 Auto Scaling结合，利用 CodePipeline，CodeCommit， Codebuild ，CodeDeploy  这些服务组件来实现的. 首先会使用AWS CodePipeline来构建一个工作流，定义开发人从本地开发环境提交到 CodeCommit中的代码。由Codebuild会完成编译测试工作后，将其打包成可部署的包存放在SS的数据桶中，最后又codedeploy来从数据桶中获取部署包，并按照appspec修订文件中定义好的部署规则来将包发布到部署组，每个实例上的 CodeDeploy代理将定从指定的 S3 存储中提取的内容。并按照 AppSpec文件中的说明向实例中部署内容。

那么这就是我设计得DEVOPS流程

最后，在架构中还要介绍，整个系统可以通过使用CloudWatch来监控整个系统的内存使用率、处理器利用率、缓存命中率等一系列指标来监控服务器运行状况。

此外，借助可用区实现物理隔离来确保服务的高可用，为每个实例关联弹性 IP，使得auto scaling一旦检测到的故障实例并重新加载新的实例后，EIP能够重新分配到新的实例，从而保证实例重启后IP地址不发生改变，为运行脚本和自动化提供便利。

接下来介绍的是在架构图中使用到的一些AWS服务组件以及选择他们的原因。

第一点，需要保证的就是服务的可用性，AWS有能力处理大多数web应用服务器的失败，并能够在短时间内恢复服务。因此构建高可用的服务组件我选择了：

组件1 ，多可用区:使用多可用区，能够确保如果有一个可用区发生故障，用户请求可以重定向到其他可用区中正常工作的实例，而这所有这一切用户是感觉不到的。

组件2， CloudWatch：通过检测实例运行和性能指标，可以发现潜在的问题，并将潜在的问题发送给运维团队。

组件3， Auto Scaling：使用它能够构建一组可用性很高的实例集群。当大量请求到达时,它可以自动扩大EC2实例数量，当请求降低时，它还能够自动缩小。

组件4， EL”:使用它，主要是为了实现多可用区的负载平衡。 另外，还起到容错功能，保证请求流量总是被分流到健康的EC2实例。

……………………………………………………………………………………………………………………………………………………………………………………………………………

第二点 ，高性能也是客户非常关注的，AWS几乎覆盖全世界11个主要区域，42个可用区，52个边缘站点，在提供高可用的服务同时，也能够提供高性能服务。

Route 53 是一个多区域扩展的 DNS服务，当来自各地的请求到达后，它能够重定向用户请求到距离他们最近的web服务站点中去，配合使用 CloudFront和边缘站点，S3，用户能够使静态文件的访问更快捷，高效；

S3 可用来持久化静态对象，例如，部署归档文件，脚本，数据库备份文件和日志，媒体文件等。

ElastiCache(redis集群)会更有助于性能的提升，通过缓存数据来减少数据库连接次数。从而更快的响应客户，

……………………………………………………………………………………………………………………………………………………………………………………………………………

第三点，就是安全方面: 我们认为用户的任何数据都是非常重要的，需要有效的保护。AWS通过自动监控系统可以做到保护网络和增强互联网接入的安全性，防止分布式拒绝服务(DDoS)攻击。退役的存储设备也会从物理层面上进行彻底的销毁。AWS还能够确保数据中心的物理环境安全。

我主要选择了这几个组件：

VPC : 构建虚拟网络隔离来自外部网络的资源。

安全组：允许在每个层级配置访问规则，在我的结构中，web层的安全组，我们可以定义只允许HTTPS访问服务器，我们也可以为web访问暴露特定的端口。

在数据存储层，也设有安全组，满足定义在每个级别访问底层数据的解决方案。

子网：

IAM：为所有用户提供安全访问权限控制，通常IAM用户组包括，系统管理员，开发测试组，经理组，他们分别拥有不同访问和操作的AWS EC2和AWS S3数据桶的权限。

最后是对用户的需求做的梳理，对应我所设计得架构方案：

针对满足需求的扩展能力 - 这个架构在web应用层使用了auto-scaling服务与AWS EC2实例相结合的方式是可以做到快速可伸缩的

针对缺乏灾难恢复机制 - 在我的架构中使用了由主数据库和备数据库构成的高可用数据库。

针对用户体验的低延迟 - CloudFront能够使的边缘站点缓存静态数据.  加速分配给最终用户的 Web 服务。

针对基础设施和服务实例故障失败恢复 - 通过 Cloudwatch中定义的报警指标检测auto-scaling。

针对数据在传输过程中的安全，由于VPC起到了隔离资源的作用。那么在网络层可以仅由客户使用IAM给定的特权来建立连接。数据在运输过程中可以通过SSL / TLS传输协议。

针对随着交付团队扩大确保访问环境的安全——使用IAM定义，用户，角色，和组的不同权限

针对活动对象大于6个月的归档策略 — —通过使用S3 对象生命周期规则定期向Glacier移动日志和其他数据。 

针对能够轻松地管理和复制多个环境，方便以后管理可以通过使用BeanStalk快速部署PHP应用程序。

一个是 RTO，另一个是 RPO。所谓 RTO，Recovery Time Objective，它是指灾难发生后，从 IT系统当机导致业务停顿之时开始，到 IT系统恢复至可以支持各部门运作、恢复运营之时，此两点之间的时间段称为 RTO。所谓 RPO，Recovery Point Objective，是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。