程序员做个网站要多少钱呢,html制作音乐网站代码,免费小程序商城,军用网站建设背景 现代业务系统受到越来越多的韧性相关的挑战#xff0c;特别是客户要求他们的业务系统 724 不间断的运行。因此#xff0c;韧性对于云的基础设施和应用系统有着至关重要的作用。 亚马逊云科技把韧性视为一项最基本的工作#xff0c;为了让我们的业务系统能持续优雅地提供… 背景 现代业务系统受到越来越多的韧性相关的挑战特别是客户要求他们的业务系统 7×24 不间断的运行。因此韧性对于云的基础设施和应用系统有着至关重要的作用。 亚马逊云科技把韧性视为一项最基本的工作为了让我们的业务系统能持续优雅地提供服务从各种故障和灾难中迅速恢复亚马逊云科技不仅提供了全球高可用的基础设施也提供了构建韧性系统的最佳实践和方法。 可靠性是工作负载按预期正确且一致地执行其预期功能的能力为了实现这一目标必须构建韧性架构。韧性是工作负载从基础设施、服务或应用程序中断中恢复、动态获取计算资源以满足需求以及减轻中断例如配置错误或短暂的网络问题的能力。 亚马逊云科技高可靠揭秘 亚马逊云科技韧性的技术实现 分区、区域和可用区隔离机制 分区 第一层隔离机制叫分区。每个分区是一组不同的区域其中每个区域都位于一个分区中并且大多数分区都有多个区域。亚马逊云科技总共包含三个分区商业海外分区、中国分区和美国政府分区。每个分区包含账户、数据和资源每个分区都有自己独立的 IAM 用户您无法使用一个分区中的 IAM 凭证与另一分区中的资源进行交互。另外某些云服务提供跨区域功能例如 Amazon S3 跨区域复制或 Amazon Transit Gateway 区域间对等连接这些类型的功能仅在同一分区中的区域之间受支持。 区域和可用区 截止到 2023 年 12 月亚马逊云科技的服务横跨全球 32 个地理区域。每个区域由同一地理区域内多个物理上独立的可用区组成。所有区域目前都有 3 个以上的可用区。每个区域都是独立于其他区域 区域之间的这种隔离机制确保单个区域发生服务故障时其他区域的能正常运营不受影响。32 个区域共有 102 个可用区区域中的每个可用区彼此相隔几十公里到 100 公里这样既能防止关联故障又能实现数据的同步复制。可用区的这种隔离机制确保它们不会同时受到公用电力或水中断、光纤中断、地震、火灾、龙卷风或洪水的影响。每个可用区都是由一个或多个独立的数据中心组成具有独立且冗余的电力基础设施和网络连接。亚马逊云科技拥的区域和可用区模型已得到认可并被 Gartner 列为运行高可用企业应用程序的推荐方法。 控制平面和数据平面隔离 亚马逊云科技服务分为控制平面和数据平面两部分。控制平面提供用于创建、读取/描述、更新、删除和列出CRUDL资源的管理 API例如启动新的 Amazon EC2 实例、创建 Amazon S3 存储桶以及描述 Amazon SQS 队列。数据平面是提供服务的主要功能。例如正在运行的 EC2 实例本身、读取和写入 EBS 卷、在 S3 存储桶中获取和放置对象以及回答 DNS 查询和执行运行状况检查的 Route 53。 控制平面往往是复杂的协调和聚合系统。当您启动 EC2 实例时控制平面必须执行多项任务例如查找具有容量的物理主机、分配网络接口、准备 Amazon EBS卷、生成 IAM 证书、添加安全组规则等。与控制平面相比数据平面没有那么复杂从统计学上讲数据平面中发生故障事件的可能性较小。尽管数据平面和控制平面都有助于服务的整体运行和成功但我们将它们视为不同的组件即控制平面和数据平面是独立设计的这种隔离既有性能方面的好处又有可用性方面的好处。 亚马逊云科技提供的三种服务类型 根据区域和可用区的隔离机制以及控制平面和数据平面分离的原则亚马逊云科技提供三种服务类型全局Global服务、区域级Region服务、可用区级AZ服务。 全局Global服务 全局服务的控制平面和数据平面不是在每个区域中独立存在的由于它们的资源不属于特定于区域的因此将其称为全局服务。全局服务遵循传统的设计模式即分离控制平面和数据平面以实现静态稳定性它们的控制平面托管在单个区域而其数据平面是全球分布的。所谓静态稳定性是指系统在依赖项故障或不可用期间无需进行任何更改在静态状态下继续正常运行。 让我们以 IAM 为例以更深入地了解全球服务的架构。在下图中我们可以看到 IAM 的数据平面是独立存在于每个区域该区域中的每个云服务都直接与 IAM 数据平面交互以对它们收到的请求进行身份验证和授权。IAM 有独立的控制平面您可以使用它来管理身份和策略等 IAM 资源因此当您调用 CreateRole 时它会流经控制平面控制平面还负责将这些更改传播到它们需要去的任何地方在本例中是分区中的每个区域。当更改传播到数据平面后数据平面将不再依赖控制平面而独立运行实现静态稳定性。当 IAM 控制平面故障的情况下无需任何更改每个区域的身份验证和授权都可以继续正常运行。 区域级Region服务 区域级服务是建立在多个可用区域之上的服务数据平面和控制平面都是区域级别。Amazon S3 、Amazon SQS 和 Amazon DynamoDB 是区域级服务的示例它们利用可用区的独立性和冗余性来最大限度地减少基础设施故障带来的影响例如Amazon S3 将请求和数据分布在多个可用区之间可以自动从可用区故障中恢复。客户可以通过使用区域服务实现其韧性目标您只需要与区域终端节点进行交互。 可用区级AZ服务 可用区独立的特性使我们可以提供可用区级别的服务例如 Amazon EC2 和 Amazon EBS可用区服务可以指定将资源部署到哪个可用区。这些服务在一个区域内的每个可用区中独立运行不依赖于其他可用区中的组件之所以可以这样做是因为有可用区级别的数据平面。在某些情况下例如 EC2还提供了区域级控制平面端点以便于与服务交互。您可以通过部署多可用区架构运行具有更高可用性、容错能力和可扩展性的生产级工作负载当工作负载使用多个可用区架构时可以更好地隔离和保护客户免受影响单个可用区物理基础设施问题的影响如果架构正确即使一个可用区出现故障工作负载也能保持运行。 单元架构 单元架构是一种设计模式该模式将服务切分为多个部署堆栈每个部署堆栈称为“单元” 每个单元之间都是互相独立的不共享任何内容包括数据库每个单元服务一个或多个客户。 对于可用区级别的服务如果没有单元架构服务的爆炸半径是整个可用区如果采用了单元架构理论爆炸半径已从整个可用区减少到仅该可用区中的单元。对于区域级别的服务也是一样的道理有了单元架构服务的故障限制在单元内。因此影响是 1/n其中 n 是单元的数量1/n 可能只占您支持的总客户的一小部分实际上单元的数量远高于下图中显示的 3 个。 随机分片Shuffle Sharding 随机分片已成为一种核心设计模式使我们可以提供具有高性价比的多租户服务为每个客户提供单租户体验。随机分片简单而不失强大功能它的强大远超我们最初的设想。我们以 Route 53 为例说明随机分片的工作原理。 Route 53 是全局服务其服务可用性至关重要采用随机分片的方法保证其架构韧性。对于 Route 53亚马逊将流量分配到 2048 个虚拟名称服务器中这些服务器是虚拟的每个客户域由四个虚拟名称服务器组成的分片承载可能的分片组合达到 7300 亿个。因为我们有很多可能的随机分片因此我们可以为每个客户域分配一个唯一的分片。实际上我们可以更进一步确保没有任何客户域与任何其他客户域共享两个以上的虚拟名称服务器。 亚马逊云科技韧性的运营实现 服务责任模型 我们采用服务责任模型激励团队不断改进其运营。我们的工程和产品管理工作由小型多学科团队领导他们对所提供的服务拥有强大的所有权。这种所有权不仅负责设计和启动服务还负责在生产过程中运营服务并在出现问题时随时待命。 运营准备情况审核 在启动之前还需要使用运营准备审核ORR流程来审核所有新服务的运营准备情况。启动团队回答一系列有关韧性的问题以及其他已知的最佳实践并使用标准化的运行手册来确保他们的服务符合标准。服务部署后每周召开运营会议检查系统的运营性能以及任何未解决的问题。 安全、持续部署 当对部署软件进行服务更新或推出新服务时我们使用安全、持续的部署管道。通过使用广泛的预生产测试、自动回滚和交错生产部署将自动化部署安全构建到发布过程中使我们能够最大限度地减少错误部署对生产造成的潜在影响。例如服务的更新从小处开始该更新首先部署到可用区内的单个最小单元OneBox 阶段并经过指定的等待期以验证没有出现问题。从那里开始更新将部署到整个可用区的其余部分然后部署到其他可用区然后部署到单个区域最后部署到其余区域。 错误流程纠正如果出现任何问题我们会利用错误纠正CoE流程等事件管理机制来帮助我们的团队了解根本原因。问题得到缓解后我们会推动全公司范围内的工程冲刺以确保所有服务中的问题得到解决从而减少未来类似事件影响其他服务的可能性。这些经验教训会被记录下来并成为运营准备情况审核ORR流程的一部分从而确保类似的问题不会再次发生。 依托亚马逊云科技构建韧性应用 云上高可用系统 当我们考虑在亚马逊云科技上部署具有高可用能力的应用时我们第一个可以依赖的就是可用区可用区设计权衡考虑了延迟、可用性、成本方便客户构建高可用的应用。我们以下图一个非常标准的 Web 三层架构来展示了如何使用多可用区实现高可用性。 首先是网络层我们将 ELB 的多个 endpoint 部署在每个可用区建议启用 cross-zone load balancing从而让 ELB 能够容忍任意 endpoint 的故障。ELB 还通过 TargetGroup 为其背后的应用实例提供健康检查功能及时摘除异常的应用实例或增加可用的应用实例。建议为应用 health check 设计一个专门页面能够判断应用是否能够真正处理业务流量readiness。NAT Gateway 为 private subnet 主动访问外部提供了网关服务在设计部署架构时应该为 VPC 内的每个可用区AZ创建 NAT Gateway并将映射到该 AZ 的所有 subnet 默认路由指向该 AZ 的 NAT Gateway不仅能够实现 AZ 级别的网络高可用同时能避免到 Internet 的流量产生 Cross AZ 费用。 其次在部署时应将应用 stateless 优化后部署在跨 3 个可用区的 Auto Scaling GroupASG中并结合 ELB 实现应用的负载均衡。当应用实例故障ASG 将自动替换故障的节点帮助系统恢复正常。ASG 能应对一般的高可用需求但对于关键业务场景使用 ASG 应对 AZ 级别的故障并不能实现静态稳定性的最佳实践因为 ASG 依赖控制面来获取计算资源。因此对于核心的关键业务还需要考虑冗余保证在故障时 ASG 失效的极端情况下仍然有足够的资源应对 100% 的业务流量实现静态稳定性。 最后在 Web 三层架构里用户往往使用 MySQL/PostgreSQL 等关系数据库用于用户数据的访问存取。针对这些开源数据库软件用户往往需要花费大量的时间精力设计数据库的高可用以及确保高可用情况下的数据一致性。亚马逊云科技为用户提供 RDS 服务为这些开源数据库提供内建的跨 AZ 高可用能力在 RDS MySQL 中开启 Multi-AZ 情况下当数据库实例故障RDS 将自动为用户故障转移数据库到其他的 AZ。RDS 还为用户提供自动备份能力通过 snapshot 快速备份数据库数据用于应对误删除等操作。对于关键的业务场景往往需要更高的可用性和性能亚马逊云科技为用户提供了 Aurora 数据库服务Aurora 支持 MySQL 和 PostgreSQL内建跨多 AZ 的高可用能力。其数据跨 3 个 AZ共 6 个副本提供数据层的高度冗余。Aurora 还提供读写和只读的 endpoint 用于帮助客户实现读写分离和更短的故障切换时间。我们看到该架构还使用了一些区域级的服务 Amazon DynamoDB 和 Amazon S3这些服务不会向用户公开其可用区配置但会跨多个可用区运行计算和存储我们依靠区域服务来消除单个可用区故障的的影响。 当我们考虑在亚马逊云科技上部署具有高可用能力的应用时我们第二个可以依赖的是托管服务来满足各式各样的业务需求帮助用户减少使用这些技术自身的高可用设计和维护工作。亚马逊云科技提供的托管服务几乎都实现了跨AZ的高可用能力。在标准的 Web 三层架构中使用的常见服务如 Amazon Elastic Kubernetes Service、Amazon Elastic Container Service、Amazon ElastiCache、Amazon Managed Streaming for Apache Kafka、Amazon DocumentDB、Amazon Keyspaces 等托管服务都提供了跨 AZ 的高可用能力。 以 Amazon EKS 为例亚马逊云科技在设计此类服务时充分考虑了组件的跨 AZ 冗余。 EKS 服务分为控制平面和数据平面。其中控制平面完全托管在 EKS-managed VPC 内核心的 etcd 服务部署在 3 个 AZ通过至少 3 个奇数节点进行选举 leader遵循少数服从多数原则因此跨 AZ 的隔离对于 etcd 非常重要需要保障单一 AZ 的运行实例异常情况下仍然有超过 1/2 的运行实例处于健康状态。kube-apiserver 是无状态的服务可随着负载的增大自动的扩展节点并提升实例的规格。kube-scheduler、kube-controller 服务自身支持高可用通过 leader 选举只有一个服务实例处于工作状态故障时重新选举 leader 切换到健康运行实例因此也需要部署多个确保高可用这些在 EKS 服务中都是由亚马逊云科技托管和实现高可用的用户只需关注 Worker 节点的高可用。 Worker 节点由 Auto Scaling Group 维护可针对自身的业务需要将单个 Auto Scaling Group 跨多个 AZ 实现高可用或者为每个 AZ 创建单独的 Auto Scaling Group。因此Worker 可轻松地实现高可用。 最后针对用户的应用部署应充分的考虑 Pod Disruption Budget、Affinity and anti-affinity、Readiness 和 Liveness 以及 Startup 探针、Graceful Shutdown、PreStop hooks、SIGTERM 等设计配合 EKS 的机制实现应用的 Zero Downtime 运行。 云上灾难恢复系统 灾难恢复DR是韧性策略的重要组成部分涉及灾难发生时工作负载如何响应灾难是对您的业务造成严重负面影响的事件如自然灾害、技术故障、人为错误。灾难恢复必须基于业务目标设定 RTO称为恢复时间目标和 RPO称为恢复点目标并制定相应的灾难恢复策略以避免数据丢失并减少停机时间。 亚马逊云科技可供您使用的灾难恢复策略大致可分为四种方法从低成本、低复杂性的备份与恢复策略到使用多个区域的更复杂的策略。对于高可用的工作负载您可能只需要备份和恢复方法来进行灾难恢复如果您对灾难的定义超出了区域破坏或受损的范围或者如果您需要遵守法规要求那么您应该考虑守夜灯、温备/热备或多区域多活的策略。 备份与恢复 备份和恢复是减少数据丢失或损坏的合适方法此方法还可用于通过将数据复制到其他区域来缓解区域灾难或者缓解工作负载只部署到单个可用区缺乏冗余的情况。除了数据之外您还必须在恢复区域中重新部署基础设施、配置和应用程序代码。为了能够快速重新部署基础设施而不会出现错误您可以使用 CloudFormation 或云开发工具包Amazon CDK等服务使用基础设施即代码IaC进行部署。除了用户数据之外还请务必备份代码和配置包括用于创建 Amazon EC2 实例的 Amazon 系统映像AMI。Amazon Backup 提供一个集中位置来配置、计划和监控备份的功能。对于 Amazon S3您可以使用 Amazon S3 跨区域复制功能CRR。 守夜灯 守夜灯方案将数据从一个区域复制到另一个区域数据例如数据库和对象存储始终处于开启状态但应用程序代码和配置处于“关闭”状态并且仅在测试期间或灾难恢复故障转移时使用配置、代码更改同时部署到每个区域。守夜灯方法通过最大限度地减少活动资源来减少灾难恢复的持续成本并简化灾难发生时的恢复流程。 温备/热备 温备方案确保在另一个区域中存在生产环境的缩小热备是和生产环境 1:1 配置但功能齐全的副本此方案扩展了守夜灯概念并缩短了恢复时间因为您的工作负载在另一个区域始终处于开启状态。此方法还允许您更轻松地实施灾难恢复测试以增强您从灾难中恢复能力的信心。 多区域多活 多区域多活方案可以在多个区域同时运行工作负载。通过多区域多活方案用户可以访问任何区域的工作负载。这种方法是最复杂、成本最高的灾难恢复方法但通过正确的技术选择和实施它可以将大多数灾难的恢复时间和数据丢失减少到接近于零。下图是以两个区域为例并可扩展到多个区域。 使用混沌工程测试韧性 混沌工程是在生产环境或尽可能接近生产的环境中定期进行实验的学科, 目的是建立抵御生产环境故障的能力及信心。利用混沌工程您的团队能够在基础设施、工作负载和组件级别以可控的方式不断注入真实世界的故障而对最终客户的影响极小甚至没有影响。混沌工程使您的团队能够从故障中学习观察、测量和提高工作负载的韧性并验证在发生事件时系统会发出警报并通知团队。如果您的系统能够经受住这些故障那么应将混沌实验作为自动回归测试的一部分这样一来将混沌实验作为系统开发生命周期SDLC的一部分以及作为 CI/CD 管道的一部分来执行持续提高系统韧性。但需要强调混沌工程不是一个孤立的系统实验它需要系统本身的韧性、可靠性设计以及可观测性的实现是一个系统整体的设计实践。 总结 亚马逊云科技把韧性视为一项最基本的工作在设计之初就通过技术手段包括分区、区域和可用区的隔离机制、控制平面和数据平面隔离机制、单元架构和随机分片等保证了云平台的韧性并通过运营模型和机制包括服务责任模型、运营准备情况审核、安全持续部署、错误流程纠正等保证持续的韧性。客户可以依托亚马逊云科技根据自身的业务目标构建韧性的架构包括云上高可用系统和云上灾难恢复系统并通过混沌工程进行持续提高。 参考文档 Amazon 故障隔离边界-区域隔离https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/partitions.html Amazon 故障隔离边界-静态稳定设计 https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html Amazon 故障隔离边界-服务类别https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html 单元架构https://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html 使用随机分区进行工作负载隔离https://aws.amazon.com/cn/builders-library/workload-isolation-using-shuffle-sharding/ Amazon 运营就绪审查和纠错流程https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html Amazon 自动化、安全的持续部署https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/ Amazon Two-Pizza Teamshttps://docs.aws.amazon.com/zh_cn/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html 在亚马逊云科技上构建灾难恢复系统https://docs.aws.amazon.com/zh_cn/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html 使用混沌工程测试系统韧性https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html 上下滑动获取完整信息 本篇作者 廖良茂 亚马逊云科技解决方案架构师负责基于亚马逊云科技云计算方案架构的咨询和设计在国内推广亚马逊云科技云平台技术和各种解决方案目前专注于韧性和数据库领域。在加入亚马逊云科技之前就职于微软、甲骨文公司熟悉数据库、备份和容灾等解决方案。 谷雨 亚马逊云科技资深解决方案架构师专注于迁移上云、云上业务连续性的实现等技术方向。 李俊杰 亚马逊云解决方案架构师负责云计算方案的咨询与架构设计同时致力于容器方面研究和推广。在加入亚马逊云科技之前曾在金融行业 IT 部门负责传统金融系统的现代化改造对传统应用的改造容器化具有丰富经验。 林旭芳 亚马逊云科技解决方案架构师主要负责亚马逊云科技云技术和解决方案的推广工作在 Container、主机、存储、容灾等方向有丰富实践经验。 星标不迷路开发更极速 关注后记得星标「亚马逊云开发者」 听说点完下面4个按钮 就不会碰到bug了
