云基础与应用实战 课件 第6章 构建高可用公有云服务器

云基础与应用实战CloudFoundationsandApplicationPractice第6章构建高可用公有云服务器单元学习目标：理解系统高可用性的含义；了解云计算系统架构的优化原则与迁移路径；掌握如何部署高可用服务器系统；掌握如何部署高可用数据库系统。第6章构建高可用公有云服务器影响系统可用性因素⑴基本概念①故障与单点故障故障是指系统运行过程中，由于系统组成部件无法正常工作而导致系统部分或全部功能失效的事件。单点故障（SinglePointofFailure，SPoF）指系统中某个没有冗余或替代的组件出现故障，导致整个系统功能失效无法正常运行。6.1

高可用系统架构规划

影响系统可用性因素⑴基本概念②可用性可用性（Availability），又称有效性，是可修复系统在规定条件下持续正常运行的能力，通常采用系统正常运行时间与实际使用时间的百分比来衡量。高可用（HighAvailability）系统则是指系统经过专门设计，以增强其不间断正常运行能力，提高服务的可用性。。影响系统可用性的主要因素有平均无故障时间（MTBF）和平均故障修复时间（MTTR）。6.1

高可用系统架构规划

影响系统可用性因素⑴基本概念②可用性（Con.）平均故障间隔时间：MTBF（MeanTimeBetweenFailures），指相邻两次故障间的平均正常工作时间。由于系统故障修复期间没有正常提供服务，因此，不包括故障时间及系统检测和维护时间。MTBF值越大，表示系统保持正确工作的能力越强，系统越可靠。平均故障修复时间：MTTR（MeanTimeToRestoration），指可修复系统的平均修复时间，即从出现故障到故障修复中间的这段时间，包括确认失效发生所需时间和维修所需时间。6.1

高可用系统架构规划

6.1

高可用系统架构规划

图6-1平均故障间隔时间与平均故障修复时间6.1

高可用系统架构规划

用户对云服务系统可用性的需求，根据系统的应用场景不同而不同，也就是可以接受服务中断时间长度取决于应用的类型。表6-1是常见类型应用系统可用性设计目标及其在连续运行一年时间内业务的可能中断时间。影响系统可用性因素⑵高可用系统架构由于系统可用性主要取决于系统组件的平均故障间隔时间（可靠性）和平均故障修复时间（可维护性），因此，可以通过功能组件的冗余设计等手段提升系统的可用性。高可用系统架构经过专门设计以增强系统服务的可用性，使系统只要各功能组件不是同时失效就仍然可以运行，不会导致服务中断。6.1

高可用系统架构规划

影响系统可用性因素⑵高可用系统架构①容错（FaultTolerance）指当系统中一个或多个处于工作状态的组件发生故障（硬件故障或软件错误）时，系统能够自动检测、诊断并采取相应措施保证系统仍能继续正常或在可接受范围内完成指定任务的技术。容错并不解决组件故障，而是通过组件的冗余性来保持其正常运行。6.1

高可用系统架构规划

影响系统可用性因素⑵高可用系统架构②可扩展性（Scalability）指系统可以根据应用负载的变化动态添加或删除资源来保存系统性能的稳定，而资源的增加不会改变系统的结构，或者增加系统管理的复杂性。系统扩展方式包括添加或删除功能组件的横向扩展，和提升组件性能的纵向扩展两种。可扩展性有助于提高整个系统的可用性，但是并不会提升系统单个组件的可用性。6.1

高可用系统架构规划

影响系统可用性因素⑵高可用系统架构③可恢复性（Recoverability）指系统在组件发生故障并导致系统服务失效时，快速恢复正常状态的能力和速度。可恢复性包括系统故障检测（服务状态的监测与评价）和故障恢复（恢复时间、过程、策略和程度等）两个方面，是系统容错性和可扩展性的基础，对系统的可用性至关重要。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑴假定任何服务都可能失效为避免单点故障导致整个系统失效，需要假设云服务系统的任何服务组件都可能失效，并将失效组件的自动化恢复作为架构设计的组成部分，利用故障自动检测评价机制和系统冗余协同实现系统架构的自动扩展。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑴假定任何服务都可能失效（Con.）为避免冗余架构导致系统复杂度和成本过度增加，在设计时应遵循以下步骤：假定云服务系统的任何服务组件都可能出现问题；根据业务流程回溯系统架构设计，分析并确认哪些服务组件失效可能导致云服务系统单点故障；在系统架构中增加冗余设计，保障在组件发生故障时，云服务系统能够依靠冗余组件维持业务的连续性，避免导致系统单点故障。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑵多可用区设计每个可用区都是独立部署的资源集合，可用区之间相互物理隔离，一个可用区出现问题的影响范围被限制在本可用区内，不会影响其它可用区。如果将服务资源相互冗余部署在两个或以上可用区以构建具有多可用区系统架构，每个可用区都拥有系统运行所需要的全部资源。当某个可用区发生故障时，部署在其它可用区的服务资源不会受到影响仍然可以继续运行，或者仅需要非常短暂的故障恢复时间，来实施系统所承载业务的跨可用区迁移，从而保障云服务系统的高可用性，避免因底层基础设施故障导致系统服务不可用。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑶弹性自动扩展系统架构可以在某个实例（或服务组件）失效时，启用冗余实例（或服务组件）来应对需求变化，可以保障系统服务的连续性。弹性自动扩展系统架构的资源规模可以根据业务负载变化自动增加或缩减，而无需人工干预。系统基础设施资源的自动扩展，不仅可以避免额外的软、硬件资源开销（资源闲置），降低云服务系统运行成本，更重要的是当业务规模面临突发性扩张时，不会造成服务中断，从而保障系统的高可用性。云服务系统架构可以从垂直和水平两个维度弹性扩展。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑶弹性自动扩展（Con.）垂直扩展（ScaleUp）是通过提高系统现有组件的性能（如CPU性能）来增强系统服务的承载能力。垂直扩展有两种方式：增强服务组件性能。例如：增加实例CPU性能、提高内存性能、提升网络带宽，升级硬盘性能（如预配置IOPSSSD）、扩充硬盘容量等。提升架构处理性能。例如：部署Cache来减少I/O次数、调整系统结构来减少响应时间、采用异步处理模式来提升服务吞吐率等。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑶弹性自动扩展（Con.）水平扩展（ScaleOut）是通过增加现有系统中同类组件（实例）的数量，并利用负载均衡技术将应用负载平均地分布到这些组件（实例）上，使它们如同整体一样工作，在简单、快速地实现系统承载应用能力自动增加或缩减的同时，为利用冗余组件解决单点故障问题奠定基础。水平扩展不仅需要系统体系架构的支持，而且存在增加系统复杂度，推高系统运行成本等问题。因此，水平扩展适用于负载快速增长并且软件成本不高的应用场景。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑷故障自动修复故障自动修复包括故障发现、故障转移（Failover）与恢复（Failback）两个阶段，目的是通过自动检测、触发预定义脚本，来执行常见的、重复性的运维工作，以有效降低故障修复时间和系统运维人力成本。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑷故障自动修复（Con.）故障发现：通过一系列技术指标监控、日志收集与跟踪，检测分析系统的运行状况，并根据预先设置的告警阈值判断系统是否出现故障，以及应该采取的措施。例如：监控EC2实例的CPU利用率（CPUUtilization）、磁盘读取操作（DiskReadOps）、网络接收数据包数（NetworkPacketsIn）等指标。故障转移与恢复：当组件发生故障并影响系统服务时，快速启用冗余或备用组件（例如实例、存储系统、网络或其它资源）接替故障组件，将组件和系统的服务恢复到故障之前状态。故障转移通常自动完成，无需人工干预；而故障恢复可以自动完成，也可以将恢复动作预先配置为半自动选择或不恢复。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑸松耦合（Loosely-Coupled）设计耦合关系是指两个或多个对象间存在某种相互作用、相互影响的关系。在云服务系统中，“耦合”是指云服务组件或模块间相互协作的依赖性。所谓“紧耦合”，是指云服务组件或模块间存在高度依赖关系，一个服务组件或模块的改变（失效）将导致其它组件状态的变化。所谓“松耦合”则与之相反，云服务组件或模块间则基于消息通讯，一个云服务组件或模块状态的改变（失效），不会引起其它云服务组件状态的变化。6.1

高可用系统架构规划

2.高可用系统架构设计原则⑸松耦合设计（Con.）云服务系统架构耦合度越高，系统的灵活性就越低。为降低系统架构耦合度，服务组件或模块间的交互应尽可能采用消息协商机制，以降低服务组件或模块间的相互依赖，提高组件或模块的独立性，通过“解耦”来提高系统的可用性。此外，松耦合系统架构服务组件或模块的更新，不需要修改或重构系统架构，从而使云计算系统开发环境可以更为敏捷，通过快速、灵活的业务处理流程变化，更好的适应业务场景的快速变化。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务①负载均衡原理Amazon弹性负载均衡（ElasticLoadBalancing，ELB）接受来自客户端的传入流量并在一个或多个可用区中的已注册目标（如EC2实例、容器、IP地址、Lambda函数等）间自动分配该访问流量。弹性负载均衡通过一个或多个侦听器检查连接请求使用的协议和端口号，并监控注册目标的运行状况，以确保只将连接请求发送给运行状态良好的目标（实例）。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务①负载均衡原理（Con.）用户可以在多个可用区启用负载均衡器，来增强系统容错能力。弹性负载均衡将为每个启用的可用区创建一个网络接口，每个可用区的负载均衡器节点通过该网络接口获取一个静态IP地址，并在每个启用的可用区里确保每个目标组至少有一个目标。例如，如果一个或多个目标组在可用区中没有运行状况良好的目标，亚马逊云科技将从DNS中删除相应子网的IP地址，但是其它可用区的负载均衡器节点仍可用于路由流量。6.1

高可用系统架构规划

6.1

高可用系统架构规划

图6-2弹性负载均衡与实例的水平扩展3.构建弹性系统架构的服务⑴弹性负载均衡服务①负载均衡原理（Con.）在创建目标组时，需要指定目标类型，该类型将确定用户如何注册此目标。例如，用户是使用实例ID、IP地址或是应用负载均衡器注册。如果用户使用实例ID注册目标，则客户端的源IP地址将保留并提供给用户的应用程序；如果用户使用IP地址注册目标，则源IP地址是负载均衡器节点的私有IP地址；如果用户将应用负载均衡器ALB注册为目标，则客户端的源IP地址将保留并提供给用户的应用程序。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务①负载均衡原理（Con.）弹性负载均衡基于用户定义对VPC的不同应用程序流量在多个目标间进行分配。负载均衡器可以根据应用程序流量的变化及时增减目标（实例），用户也可以根据需求变化在弹性负载均衡器中添加和删除目标，而不会中断所有到应用程序的请求流量。弹性负载均衡不仅为应用程序工作负载提供自动扩展，使其获得持续提供均衡分配应用程序流量负载所需的能力，而且通过消除单点故障提升应用系统的可用性，使用户在较高层次实现应用程序性能容错。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务②类型与功能应用负载均衡器应用负载均衡器（ApplicationLoadBalancer，ALB）运行在开放系统互连模型（OSI）的应用层（第七层），支持HTTP/HTTPS/WebSocket协议，而不支持TCP

（传输控制协议）/UDP

（用户数据报协议）（第四层）。ALB根据请求的内容将流量路由给目标，例如：AmazonEC2实例、容器、互联网协议（IP）地址或Lambda函数。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务②类型与功能应用负载均衡器（Con.）ALB允许用户编写侦听器规则，根据应用程序流量的内容（HTTP主机标头字段）将流量路由给AmazonVPC内的不同目标组。每个目标组的路由都是单独进行的，即使某个目标已在多个目标组中注册，用户可以配置目标组级别使用的路由算法。ALB在收到请求后，将按照侦听器规则的优先级顺序确定应用哪条规则，然后从目标组中选择该规则的操作目标。。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务②类型与功能网络负载均衡器网络负载均衡器（NetworkLoadBalancer，NLB）运行在OSI的传输层（第四层），每秒能够处理数以百万计的请求，并保持超低延迟，适合于需要更高性能的TCP、UDP和TLS（传输层安全性协议）流量的负载均衡。NLB允许用户在侦听器中配置检查连接请求的协议和端口，例如，TCP、UDP流量的协议，源、目标IP地址，源、目标端口，甚至TCP序列号。NLB在收到连接请求后，会从默认规则的目标组中选择一个目标，并尝试在侦听器配置所指定的端口上打开一个到该选定目标的TCP连接。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务②类型与功能网络负载均衡器（Con.）对于TCP连接，负载均衡器根据其源端口和序列号，使用哈希算法选择目标。具有不同源端口和序列号的TCP连接，可以路由到不同目标。每个独立的TCP连接在其生命周期内，只被路由到唯一一个目标。对于UDP流量，具有相同源和目的地址的UDP流量，将在整个生命周期内始终被路由到某个目标；对具有不同源IP地址和端口的UDP流量，则可以被路由到不同目标。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务②类型与功能网关负载均衡器网关负载均衡器（GateWayLoadBalancer，GWLB）运行在OSI的网络层（第三层），是透明网络网关（即所有流量都使用的单一进出口）与负载均衡器的结合。用户可以通过修改VPC路由表配置，将流量发送到GWLB，借助GWLB在一组虚拟设备之间实现流量负载均衡的同时，根据需求弹性扩展虚拟设备。例如，防火墙、入侵检测和防御系统、深度数据包检测系统等，进行健康检查、负载调度等管理。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务②类型与功能网关负载均衡器（Con.）GWLB监听所有端口上的所有IP数据包，并使用网络虚拟化基础协议（GenericNetworkVirtualizationEncapsulation，Geneve）和GWLBmetadata将流量转发给监听程序规则中指定的执行扫描的虚拟设备。GWLB使用五元组（对于TCP/UDP流量）或三元组（对于非TCP/UDP流量）来保持流向特定目标设备的黏性。GWLB通过在正常运行的虚拟设备之间路由流量来提高系统可用性，并在设备运行状况不佳时重新路由流量。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务②类型与功能网关负载均衡器（Con.）GWLB使用GWLB终端节点实现流量安全的跨VPC边界交换。GWLB终端节点是一种为服务供应商VPC中的虚拟设备与服务使用者VPC中的应用服务器之间提供私有连接的VPC终端节点。进出GWLB终端节点的流量使用路由表进行配置。流量从服务使用者VPC通过GWLB终端节点流向服务提供商VPC中的GWLB，然后再返回服务使用者VPC。用户需要在不同子网中创建GWLB终端节点和应用程序服务器，确保用户可以将GWLB终端节点配置为应用程序子网路由表中的下一跳。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务③比较与选择不同类型负载均衡器特性比较弹性负载均衡器是构建高可用、可扩展系统架构的重要组成部分。用户需要根据不同类型负载均衡器的特性按需选择。6.1

高可用系统架构规划

6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务③比较与选择根据应用场景按需选择应用负载均衡器：主要在包括微服务、容器在内的应用程序架构中为应用程序流量提供负载均衡。在优化基于HTTP/HTTPS/Websocket的应用层业务时，如果用户需要灵活管理应用程序，建议选择使用ALB。网络负载均衡器：主要在网络层为基于TCP的应用程序流量提供负载均衡。在优化高性能、低延时、会话保持的应用服务，需要应用服务实现极致性能，特别是需要静态IP地址时，建议选择使用NLB。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑴弹性负载均衡服务③比较与选择根据应用场景按需选择（Con.）网关负载均衡器：主要在网络层提供托管型负载均衡服务，将需要扫描的流量转发到一组虚拟设备上。在部署、扩展和管理第三方虚拟设备（如防火墙、入侵检测和防御系统、云中的深度数据包检测系统）扫描互联网IGW流量或虚拟私有网关VGW流量，建议选择使用GWLB。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑵AmazonCloudWatchAmazonCloudWatch是一种实时监控和管理亚马逊云科技资源及用户在其上运行的应用程序的服务，用户（开发运营工程师、开发人员、站点可靠性工程师和IT经理等）可以使用CloudWatch收集和跟踪相关资源、服务和应用程序的度量指标，帮助其统一管理和维护这些服务资源和应用程序。AmazonCloudWatch本质上是一个指标存储库，用户可以使用CloudWatch监控其账户的亚马逊云科技资源的特定指标，收集并监控日志文件。6.1

高可用系统架构规划

6.1

高可用系统架构规划

图6-3AmazonCloudWatch对资源的监控3.构建弹性系统架构的服务⑵AmazonCloudWatch（Con.）用户可以根据这些指标全面地了解资源使用率、应用程序性能和运行状况，并在根据指标数据解读出相应业务异常波动或者检测到指定异常时，使用告警服务将告警邮件自动发送到AmazonSimpleNotificationService（AmazonSNS）主题，或是调用AmazonAutoScaling操作AmazonEC2实例，以自动化应对各种异常情况。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务①基本功能亚马逊云科技AutoScaling帮助用户轻松、安全地扩展资源（EC2实例或应用程序），在优化应用程序性能，维持服务稳定的同时，尽可能降低系统运行的成本。AmazonEC2AutoScaling服务通过维护名为AutoScaling组的EC2实例集合，并根据策略、计划和运行状况检查帮助用户自动增加或缩减AmazonEC2实例数量，保障其资源能够满足应用程序负载的变化，获得所期望的性能并节约基础设施成本。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务①基本功能（Con.）在EC2AutoScaling组中，用户可以将EC2实例视为可扩展的逻辑组件，通过手动方式或定义EC2AutoScaling服务扩展策略和计划加以管理和使用。例如，设置指标阀值，并根据实例运行状况监控来自动调整EC2实例数量。当指标达到预设阀值时，EC2AutoScaling向EC2AutoScaling组中自动添加或删除实例，并确保新增EC2实例可以无缝地添加到业务系统以及时满足负载增加的需求。而当负载下降至低于预设阀值时，EC2AutoScaling通过终止EC2AutoScaling组中的实例，来缩减实例数量以降低系统运行成本。EC2AutoScaling组的容量取决于用户设置，并且可以EC2实例部署到不同可用区以进一步增强可用性。6.1

高可用系统架构规划

6.1

高可用系统架构规划

图6-4AutoScaling组容量3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务①基本功能（Con.）当用户设置了EC2AutoScaling组的最小实例容量，AmazonEC2AutoScaling将确保EC2AutoScaling组的实例数量始终不低于该容量；对于EC2AutoScaling组的最大实例容量，EC2AutoScaling将确保EC2AutoScaling组的实例数量始终不超过该容量。如果用户在创建EC2AutoScaling组时或在其后任何时间指定所需容量，EC2AutoScaling将调整EC2AutoScaling组容量，使组内实例保持指定数量。如果用户指定扩展策略，EC2AutoScaling可以根据指定条件，在实例容量范围内调整实例数量。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件EC2AutoScaling可以根据CloudWatch指标动态扩展，或者根据用户自定义计划，以可预测的方式扩展，或者将动态扩展与预测扩展结合使用，以响应需求的不断变化。。6.1

高可用系统架构规划

6.1

高可用系统架构规划

图6-5EC2AutoScaling功能组件及其协作关系3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件启动配置（LaunchConfiguration）是EC2AutoScaling启动EC2实例时使用的模板，用来定义EC2实例的启动参数，包括：实例类型规格、启动实例映像文件AMI的ID、密钥对、一个或多个安全组以及挂载的储存设备映射。如果此前已启动过EC2实例，可以指定相同信息来启动实例。用户可以为多个EC2AutoScaling组指定启动配置，但是一个EC2AutoScaling组一次只能与一个启动配置关联，并且启动配置在创建后不能修改。用户只能创建新的启动配置，再使用该配置更新相关EC2AutoScaling组。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件启动配置（LaunchConfiguration）是EC2AutoScaling启动EC2实例时使用的模板，用来定义EC2实例的启动参数，包括：实例类型规格、启动实例映像文件AMI的ID、密钥对、一个或多个安全组以及挂载的储存设备映射。如果此前已启动过EC2实例，可以指定相同信息来启动实例。用户可以为多个EC2AutoScaling组指定启动配置，但是一个EC2AutoScaling组一次只能与一个启动配置关联，并且启动配置在创建后不能修改。用户只能创建新的启动配置，再使用该配置更新相关EC2AutoScaling组。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件启动配置（LaunchConfiguration）（Con.）用户在创建或更新EC2AutoScaling组时，必须指定启动配置、启动模板或EC2实例，用来配置EC2实例所需的信息。当用户使用指定EC2实例创建EC2AutoScaling组时，EC2AutoScaling将自动为其创建启动配置并与EC2AutoScaling组关联。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件启动模板启动模板的作用与启动配置相同，也是用于指定实例配置信息，包括实例映像文件AMI的ID、实例类型规格、密钥对、安全组以及用于启动EC2实例的其它参数。与启动配置不同，启动模板允许用户配置多个版本，利用版本控制创建完整参数的一组子集，再通过重复使用创建其它模板或模板版本。例如，用户可以创建一个定义常用配置参数的默认模板，同时允许将其它参数指定为同一模板另一个版本的一部分。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件EC2AutoScaling组是一组拥有相似配置的EC2实例的集合，这些实例是AutoScaling组用于管理和自动扩展的逻辑组件。EC2AutoScaling组需要配置并预置：实例的启动配置，实例最小和最大容量、所需容量，可用区和子网，健康状态检查及其参数。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件运行状态检查EC2AutoScaling定期检查EC2实例运行状态，如果某个实例未通过其运行状态检查，该实例将被标记为运行状况不佳。EC2AutoScaling将终止该EC2实例并启动一个新EC2实例加以替代。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件扩展选项在发生指定扩展事件时，EC2AutoScaling为用户提供多种方式用来选择如何扩展和收缩EC2AutoScaling组。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件扩展选项（Con.）保持当前实例容量：例如，EC2AutoScaling组始终保持拥有3个健康的实例。手动扩展：手动更改最小容量、最大容量或者所需容量参数来控制EC2AutoScaling组的实例数量。计划扩展：通过设定具体的日期和时间来自动调整EC2AutoScaling组实例数量。例如：某Web应用程序访问流量每周星期三开始增加，星期四仍然维持较高水平，而星期五开始下降。用户可以根据该Web应用程序可预测的流量模式来计划并实施扩展操作。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件扩展选项（Con.）按需动态扩展：基于CloudWatch监控和参数设置来控制扩展。例如：当CPU利用率持续10分钟高于70%就自动进行扩展，即增加EC2实例数量；而当CPU利用率持续10分钟低于30%则自动进行缩减，则减少EC2实例数量。6.1

高可用系统架构规划

3.构建弹性系统架构的服务⑶AmazonEC2AutoScaling服务②EC2AutoScaling功能构件扩展选项（Con.）预测性扩展（PredictiveScaling）：根据收集的EC2实例实际使用历史数据，运用机器学习算法挖掘流量的每日和每周变化模式，用来预测未来流量，并在所预测变化之前预置适当数量的EC2实例而不是被动地做出适应性调整。预测性扩展可以更为快捷、准确的预置EC2AutoScaling组容量，从而降低成本并提高应用程序响应速度。6.1

高可用系统架构规划

4.高可用系统架构设计⑴任务分析①服务资源冗余部署根据假定任何服务都可能失效原则，WordPress系统的Web服务器、数据库服务器、WordPress博客服务器不但要分别部署在不同EC2实例上，而且需要冗余部署，以避免因服务组件故障而导致整个系统失效。6.1

高可用系统架构规划

4.高可用系统架构设计⑴任务分析②多可用区设计根据多可用区设计原则，将服务资源相互冗余部署到多个可用区中运行，既可以避免因底层基础设施故障导致系统服务失效，又可以实现资源负载的跨可用区平衡。需要注意的是，云服务系统的多可用区部署可能会导致传输延迟，特别是多可用区部署数据库，其副本间为维护数据一致性而进行同步时，可能会导致系统性能下降，甚至服务中断。6.1

高可用系统架构规划

4.高可用系统架构设计⑴任务分析③系统架构自动弹性扩展根据弹性自动扩展设计原则，部署自动扩展和负载均衡服务，并利用服务状态监控机制触发扩展规则，自动增加或缩减系统服务资源。系统利用CloudWatch监控实例运行状态，在技术指标显示实例性能不足或服务组件失效时，触发预定义的扩展规则自动扩展或缩减AutoScaling组的EC2实例数量，或在实例失效时启动新实例替换不健康实例。ElasticLoadBalancing则将业务负载自动均衡分配到新增实例上，保证服务的连续性。6.1

高可用系统架构规划

4.高可用系统架构设计⑴任务分析④故障自动修复根据故障自动修复设计原则，在系统中部署监控服务，监控和跟踪EC2实例CPU利用率、磁盘读取操作、网络接收数据包数等常用指标，收集和监控日志文件，检测实例及业务系统运行状况，诊断系统是否出现问题，以及应该采取的措施。CloudWatch在相关指标达到告警阈值时发布警报，警报触发预定义脚本自动执行常见故障的发现、转移和恢复等运维工作，快速修复失效服务组件，提高运维效率，降低人力成本。6.1

高可用系统架构规划

6.1

高可用系统架构规划

图6-6基于CPU利用率的系统架构自动扩展4.高可用系统架构设计⑴任务分析⑤解耦存在的紧耦合关系根据松耦合设计原则，需要对WordPress博客网站系统架构进行解耦，将Web服务器、数据库服务器分别部署到不同实例上，并使用消息协商机制进行通讯，以解耦服务组件间的紧耦合依赖关系。6.1

高可用系统架构规划

6.1

高可用系统架构规划

图6-7解耦Web服务器与数据库服务器信息交互4.高可用系统架构设计⑵架构说明Route53（DNS）解析弹性负载均衡器ELB的URL，ELB将用户的访问请求转发给某个部署有WordPress博客网站服务器的EC2实例，该博客网站服务器通过3309端口远程访问MySQLR