AWS 架构最佳实践概述(十一)

AWS 架构最佳实践

AWS合理架构的框架支柱

  • 安全性 - 保护并监控系统

    • 能够保护信息、系统和资产
    • 通过风险评估和缓解策略
  • 可靠性 - 从故障中恢复并减少中断
    • 从基础设施或服务故障中恢复
    • 动态获取计算资源以满足需求
    • 减少配置错误和暂时性网络问题来减少中断
  • 绩效 - 谨慎使用资源
    • 高效的使用计算资源以满足系统需求
    • 在需求改变和技术发展时依旧保持效率
  • 成本优化 - 消除不必要的费用
    • 减少不必要的成本和次优资源
  • 卓越操作

合理架构设计原则

  • 停止猜想容量需求 - 传统环境存在浪费
  • 在生产层面测试系统 - 传统环境下因为高昂的测试成本,所以通常都无法真实模拟生产环境进行测试
  • 降低架构改变风险 - 传统环境中需要排队等待的测试序列化,在测试过程中的各种改变,可能影响后续测试。
  • 通过自动化让部署更简单 - 低成本通过脚本创建并复制系统,追踪变更和恢复
  • 支持架构的不断发展 - 传统环境受产品生命周期限制,前期决策也可能成为阻碍,无法响应不断变化的业务需求
  • 数据驱动型架构 - 在云环境中,可以通过CloudWatch收集相关数据,来了解架构负载情况。云基础架构以代码的形式存在,因此可以利用这些数据来改善架构。
  • 通过模拟大型流量实现改进 - 通过模拟大型流量,来改进架构中的不足之处,并且积累应对的经验和方案。

高可用和冗余

  • 发现当前架构中的单点故障,引入冗余来消除
  • 选择最适合的备份和恢复方案最高效的冗余
  • 使用不同的可用区实现地域高可用
  • 利用Route53和ELB主动切换来实现主动的冗余机制减少中断时间

弹性设计

  • 弹性系统是随时间推移或响应业务需求突然变化以应对增长的负载,随用户、流量、数据大小的增长而不会影响性能
  • 资源增长应该引入规模经济效益,成本应遵循童谣你给的维度从而使该系统创造商业价值
    • 垂直缩放

      • 通过停止实例调整更多的CPU、RAM、IO、网络等功能实现
      • 垂直缩放有其上限、且不容易实现
    • 水平缩放
    • 无状态应用程序
    • 所有操作不需要知道过去的上下文,会话也不会被存储
    • 可以进行任意的水平扩展且可随意的安全终止,因为系统资源间不会共享会话数据
    • 所有节点不需要意识到其他节点的存在,只需要处理分配给他的工作量即可
  • Autoscaling是最佳实践
    • 无状态组件

      • 大多数应用程序都需要维护某些状态信息,如登录信息等。
      • 方案一:
        • 应用程序可以通过用户会话标识存储在客户端本地(如HTTP Cookie)实现一定程度的无状态, 但是会存在两个问题:
        • 放在客户端本地Cookie的信息容易被篡改,每次都需要传送用户会话状态占用资源增加延迟
      • 方案二:
        • 用户会话信息存储在服务器关联的数据库中, 如DynamoDB,从而实现服务器组件的无状态化
    • 有状态组件
      • 很多应用程序和体系结构都无法转变成无状态的
      • 许多遗留系统设置被设计成必须依靠本地单独计算资源运行的

自动化部署

  • 公有云最大的好处就是能够利用API来自动化部署过程,建议从一开始就进行自动化部署
  • 自动化和可重复部署将有效的减少错误并促使高效的可扩展更新过程
  • Bootstrap 实例
    • 利用自动化动作Bootstrap实例

      • 在初始化过程中用于只是简单的指定如名称、角色信息,其他都有脚本自动完成,对不同的选项提供所有必要的自动化启动资源,包括code、script和configuration等。
    • 重复创建相同环境
    • 对云基础架构保持抽象
    • 减少人工部署错误机会
    • 创建一个自我发现和自我修复的环境

选择合适的存储

  • S3

    • Web需要大规模存储容量和性能
    • 高耐久性数据,以及支持灾难恢复的备份
  • Glacier
    • 数据归档和长期备份
  • Cloudfront
    • 利用内容交付网络在全球边缘位置部署静态、动态、流媒体和交互式内容
  • DynamoDB
    • 快速且灵活的NoSQL数据库,灵活的数据模型和可靠的性能
    • 可以用来解耦有状态应用,将用户状态存储在DynamoDB中使应用程序可以实现无状态组件
  • EBS
    • 可靠地块存储运行关键程序,如Oracle,SAP,Exchange等
  • RDS
    • 高可用的SQL数据库
  • Redshift
    • PB级数据仓库,支持业务分析
  • ElasticCache
    • Redis集群内存缓存
  • EFS (弹性文件系统)
    • 多个EC2实例之间共享应用程序的通用文件系统

在每一层建立安全

  • 传统的安全审计是定期和审计的,但是在云端可以提供持续监控和治理,同事利用代码将安全策略嵌入基础设施设计
  • 最佳实践
    • 对数据进行清点和优先级排序,在传输和存储时应用适当的加密级别
    • AWS功能实现多级防御
      • 网络层面: VPC 、 子网、安全组、路由控制
      • 主机层面: WAF、 IAM
    • 将安全交给AWS
      • 使用AWS 托管服务,由AWS进行补丁和安全管理
      • 减少特权访问
      • 应用程序使用临时安全令牌在EC2上运行
    • 使用IAM进行账户和权限管理
      • 使用临时令牌提供联合访问
      • 对凭据进行自动分发和轮换
      • 授予最小权限的标准安全惯例
    • 利用代码实现安全
      • 利用CloudFormation脚本进行可靠地安全部署 称为"Golden Environment"
      • 最佳安全实践将会被很容易的在不同环境中重用并且集成到CICD pipeline中
      • 可以利用安全测试自动发现与安全策略基线的偏差
      • CloudFormation 可以作为产品导入AWS Service Catalog 中进行一致性治理
    • 实时审计
      • AWS实现持续监控和控制自动化,最大限度降低安全风险
      • 借助Config Rules 可以知道某个组件是否在短时间内不合规
      • CloudWatch提供广泛的日志记录、
      • CloudTrail 实现实际的API调用
      • 所有日志可以备Lambda、EMR等自动处理

并行化处理思维

  • 云中可以轻松实现并行处理
  • 如检索和存储数据时,云被设计成处理大规模并行操作,所以为了提高性能和吞吐率,应该尽可能使用并行请求设计
  • Web应用程序,应该设计成支持ELB负载均衡的传入请求分布的并行处理
  • 批处理场景下更多的使用拥有多从属节点的hadoop架构

松耦合设计

  • 将系统设计成多个独立组建的系统体系,组件越松散,相互依赖性越低,系统规模就能更大
  • Amazon API Gateway提供了公开定义接口的方法,是完全托管的服务
  • 支持开发人员创建、发布、维护和监控以及保护各种规模API
  • 可以处理所涉及的数十万并发的API调用,包括流量管理、授权和访问控制
  • 异步集成是松耦合的常用模式,利用SQS或者Kinesis进行松耦合集成
  • 利用异步集成耦合可以引入额外的弹性,可以对处理失败的消息进行再次处理

AWS最佳实践

  • 实现扩展架构 - 以应对需求变化
  • 自动部署环境 - 消除手工操作提高系统的稳定性和一致性,并提高组织效率
  • 使用一次性资源 - 将服务器和其他组件视为临时资源
  • 松耦合组件 - 降低相互依赖,当一个组件变化或出故障时,其他组件不受影响,ELB和SQS是主要解耦解决方案
  • 设计服务而不是设计服务器 - 托管方案和无服务架构让环境实现更高的可靠性和环境 ,如Lambda, SQS,SNS,DynamoDB
  • 更合适的数据库解决方案 - 技术与工作负载相匹配,选择关系型数据库,NoSQL数据库,数据仓库以及针对搜索优化过的数据存储
  • 避免单点故障 - 实施冗余以避免单点故障破坏整个系统,可以选择停机启动的自动化解决方案或者托管服务在故障时自动对底层进行替换
  • 优化成本 - 确保资源规模适当、可以根据需求进行自动缩减和扩展,充分利用不同的定价方案. 将资本性支出转变为可变支出。
  • 使用缓存 - 尽可能减少冗余数据检索操作
  • 在各个位置保护基础设施安全 - 可以在外围和资源内部或资源之间实现安全性

事件驱动架构

概述

  • 云计算的优势就是快速对资源需求方面的变化作出响应,以应对变化。
  • 传统模式下,即便是在云计算平台中,当服务器满负荷也会导致无法响应访问,虽然手工扩展只需要几分钟时间,但是也是不能接受的

基于事件驱动的架构

  • 监控解决方案CloudWatch

    • 利用CloudWatch监控服务器队列,通过设置多样的阈值来触发扩展,阈值规则设置可以设定到特定的应用程序自定义指标。
  • AutoScaling
    • 通过收到CloudWatch的告警进行实例扩展,在应用服务达到全容量前就准备就绪来提供无缝体验
    • 垂直扩展
      • 对实例规格进行变化,如CPU、内存等
      • 垂直扩展始终有其天花板,而且可能会存在更多的性能问题, 如Java堆栈过大造成的回收时长,而且可能需要重启服务器
    • 水平扩展
      • 对实例数量进行变化,添加和删除实例
      • 几乎没有任何能力限制,只是应用程序设计的过程中需要考虑对水平扩展的支持

  • EC2 Auto Recovery

    • 当EC2出现问题时,对受损的实例自动恢复功能或自动替换
    • 通过CloudWatch 检测可能因为网络连接丢失、系统电源损耗、主机软硬件问题导致的EC2受损
    • 替换实例是可以保持相同的实例ID,元数据、IP地址,但是内存数据将会丢失
    • 在中国区尚不支持
    • 不能使用实例存储必须是EBS支持的存储

Web应用设计

Web应用的业务价值

基于云架构的Web托管架构实践

  • Route53 提供DNS服务
  • Cloudfront 为高容量内容提供边缘缓存
  • 前端ELB将流量分不到Web服务器的AutoScaling组
  • Web服务器安全组 实现外部防火墙的安全策略
  • 后端服务器安全组实现后端防火墙的安全策略
  • 后端ELB将流量分布到后端应用程序集群中
  • ElastiCache 为应用程序提供缓存服务,从而减少数据库层的负载
  • 通过S3存储和提供静态资产

原文地址:https://blog.51cto.com/wzlinux/2431244

时间: 2024-10-11 12:27:43

AWS 架构最佳实践概述(十一)的相关文章

基于AWS的云服务架构最佳实践

ZZ from: http://blog.csdn.net/wireless_com/article/details/43305701 近年来,对于打造高度可扩展的应用程序,软件架构师们挖掘了若干相关理念,并以最佳实践的方式加以实施.在今天的"信息时代",这些理念更加适用于不断增长的数据集,不可预知的流量模式,以及快速响应时间的需求.本文将强调并重申其中的一些传统观念,并讨论他们如何在融合云计算的发展,还将讨论由于云计算的动态性而产生的一些前所未有的概念(如弹性). 本文的目标是面向云

docker安全最佳实践概述

/************************************************* * Author : Samson * Date : 08/07/2015 * Test platform: * gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 * GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu) * Nginx version: * Nginx 1.6.2 * Nginx 1.8.0 * ********

App 后台架构设计方案 设计思想与最佳实践

转载请注明出处:http://blog.csdn.net/smartbetter/article/details/53933096 做App做的久了,就想研究一下与之相关的App后台,发现也是蛮有趣的.App后台的两个重要作用就是 远程存储数据 和 消息中转.这里面的知识体系也是相当复杂,做好一个App后台也是需要长期锤炼的.本篇文章从 App 后台架构 的角度介绍.好了,下面进入正题: 说起架构,我们先看一下何为架构,百度百科是这样说的:架构,又名软件架构,是有关软件整体结构与组件的抽象描述,

开发者最佳实践日·第 13 期-实践微服务架构

随着Docker及以移动化浪潮的冲击,系统的架构与设计成为系统构建中重要环节,微服务架构这一全新的企业架构模式也越来越受到关注,使用容器技术实施微服务架构转变,如何更好的利用计算资源,以及更方便的维护越来越复杂的应用程序,微服务作为一种更灵活.可靠.开放的架构的应用实践也越来越多. 微服务架构如何让应用程序的代码库更加敏捷?如何快速迭代和扩充一个代码库并大幅提升开发者生产效率?微服务架构可以让开发团队在研发过程中更加的敏捷和灵活.想要知道更多关于微服务架构的知识,这一场沙龙你不可错过. 开发者最

微服务架构的两大解耦利器与最佳实践

这几年,微服务架构这个术语渐成热门词汇,但它不是一个全新架构,更不是一个包治百病的架构.那么,微服务架构究竟能够解决什么问题,又带来哪些痛点? 本文将与大家谈谈这个问题,以及微服务架构的两大解耦利器配置中心和消息总线的最佳实践. 微服务架构解决的问题与带来的痛点 一 互联网高可用架构为什么要服务化? 上图是互联网典型的高可用架构,大部分公司如果没有使用微服务,正在使用这样的架构: 用户端是浏览器 browser,APP 客户端 后端入口是高可用的 nginx 集群,用于做反向代理 中间核心是高可

一位云架构师用服务打动客户的故事之六(阿里云上的MSP最佳实践项目分享)

最近找了一个典型的云服务客户的案例对内进行分享,今天把核心内容脱敏后分享出来.希望能给目前在路上(做云服务MSP)的同行,有一些借鉴意义或者帮助. 该用户据全年跟进情况,目前该客户距正式启用我们公司云服务(运维服务)的日子已经有半年有余了,目前整体趋于稳定,故将目前用户进行深度复盘剖析,让各位伙伴更好的从该客户案例中提取一些有用的"武器"."售前技巧". 云产商:阿里云 企业背景-日企上来的终极三问~ > 为什么选择我们做云服务商?PS:此云服务并非指的是阿里

软件需求分、架构设计与建模最佳实践

软件需求分.架构设计与建模最佳实践 cxx 2019-04-13 一.为什么要详细设计,价值? 在多人团队环境中,详细设计驱动开发可实现明确交付的目标和标准 可复用的设计成果 提高代码的可维护性 可对交付进行工作量和质量的评估 实现知识传承,提高软件生命周期 二.控制软件复杂性的基本方法 分解法 抽象法 三.UML有哪些元素 结构 行为 四.基于用户目标的需求组织形式 交互式需求 清晰的责任 场景化 文档的五大功效 有助于编写使用手册 测试用例转化:帮助开发人员设计测试用例 需求用例 利于详细设

Artifactory 仓库架构和命名最佳实践(下)

在上篇文章中,我们已经建立了基本的仓库命名结构,在 JFrog Artifactory 中,仓库管理的最佳实践应该考虑三个因素:安全性,性能和可操作性.大多数情况下,这些因素跟你的团队规模密切相关,在较小程度上跟仓库成熟度等级的粒度划分有一定的关系. 安全 Artifactory 允许通过包含/排除模式在单个文件夹甚至文件级别进行管理权限.一般来说,这里的最佳做法是在仓库级别管理权限.对于具有高度结构化的仓库(如 Maven 和 RPM),可以在文件夹级别实现细粒度的控制.但是,对于管理员来说,

《开源安全运维平台-OSSIM最佳实践》已经上市

<开源安全运维平台-OSSIM最佳实践>已上市 经多年潜心研究开源技术,历时三年创作的<开源安全运维平台OSSIM最佳实践>一书即将出版.该书用100多万字记录了作者10多年的OSSIM研究应用成果,重点展示了开源安全管理平台OSSIM在大型企业网运维管理中的实践.国内目前也有各式各样的运维系统,经过笔者对比分析得出这些工具无论在功能上.性能上还是在安全和稳定性易用性上都无法跟OSSIM系统想媲美,而且很多国内的开源安全运维项目在发布几年后就逐步淡出了舞台,而OSSIM持续发展了十