过去一小时内从库复制滞后量，它的峰值超过80秒。在数据库复制中存在这种程度的滞后通常意味着从属设备暂时缺少加载到主设备上的大量最新数据。如果所有用户查询都定向到从属服务器，这意味着在从服务器赶上主服务器之前，用户将无法看到最新的数据。这可能会导致各种不受欢迎的效果，例如用户注释照片，单击“提交”按钮，但不会立即看到该评论。这对用户来说是混乱的，并且可能导致各种不同步的怪异。即使您从过去的经验中知道数据库是磁盘I / O绑定的，您仍然需要通过查看磁盘利用率和I / O等待来确认

虽然磁盘利用率多次上升到100％，但只是在I / O等待超过MySQL复制延迟跳跃的40％时。

这是什么意思？只需粗略查看指标，我们就可以推断复制从属延迟是由磁盘I / O等待而不是磁盘利用率引起的。我们可以进一步推断，只有在磁盘I / O等待40％或更高时，复制延迟才会成为问题。

接下来验证我们的假设：确认40％磁盘I / O等待是数据库可以承受的上限而不会导致复制滞后。所有数据库写操作都指向主服务器;读取功能由数据库从站执行，通过复制使从站保持最新状态，通过观测指标的值的变化进行验证。

其他的例子

文章中作者还列举了缓存系统、特殊用途和多用途服务器、API使用及其对容量的影响，这里就省略了，感兴趣的同学可以阅读书本。

总结：没有系统和应用程序级的度量和历史数据，容量规划就不可能存在。如果不了解系统的高级性能边界，那么规划也是无效的，找到架构的每个部分的上限涉及过程如下：

测量并记录服务器的主要功能

示例： Apache命中，数据库查询

测量并记录服务器的基本硬件资源

示例： CPU，内存，磁盘，网络使用情况

确定服务器的主要功能与其硬件资源的关系

示例：n数据库查询导致m％的CPU使用率

通过使用以下方法之一，根据服务器的主要功能和硬件资源找到可接受的最大资源使用量（或上限）

通过操纵负载平衡或应用技术人为地增加服务器上的实际生产负载。

尽可能模拟真实世界的生产负荷

三、预测趋势

预测能回答何时加，加多少。 同样等级的硬件，等6个月之后再买，价格可以变得更便宜，因为摩尔定律是一直存在的，厂商会不断的降低硬件成本。

预测能力是一个持续的过程，需要尽可能多帮助人们做出准确的预测。即使是简单的Web应用程序，但做到有效的预测其实是很繁琐的。

尽可能多地自动化流程将帮助您保持领先的采购流程。花时间将度量收集系统连接到趋势软件即可达到预测的目的。同时，还需要容量仪表盘，可以在任何时间点参考，以告知采购，开发和运营作决策。

进行容量预测的整个过程如下：

确定，测量和绘制每种资源的关键指标（需要通过压力测试找到影响服务的关键指标）。

示例：磁盘消耗

将约束应用于每种资源。（确定资源天花板，如某一种硬件类型的数据库类的I/O的上限为40%时会影响到业务）

示例：总可用磁盘空间

使用趋势分析（曲线拟合）来说明使用何时超出约束。

示例：找到磁盘空间不足的时间

四、部署

当你知道何时购买与购买多少后，此时您需要将其部署到线上。

自动化部署理念：

尽量缩短提供新容量的时间，采用更自动化的方式实现配置、安装与管理

所有变化都在一个地方发生（拥有一个中心“控制塔”，可以管理基础设施的各个方面）

不要直接登陆到某台机器进行故障排查或者其他操作，需要集中管理，这样可以接受审计

让新服务器自动开始工作，您应该能够订购硬件，将其添加到库存管理系统，打开它，让它自动安装所有必需的软件并在监控系统中注册，然后开始工作，无需人工干预

保持一致性，以便更轻松地排除故障。同一服务器群集部署一致的操作系统和软件配置消除了配置不一致性可能导致的问题，减少了故障排查的成本，而硬件不一致性的消除，管理人员不需要为不同的硬件创建大量的特殊情况配置。

如果您无法快速将物理资源投入使用，那么了解需要多少物理资源意义不大。使用配置管理和自动安装等工具自动化基础架构可确保部署过程高效且可重复。自动化将系统管理任务从一次性工作转换为可重用的构建块。

五、自动缩容

以Amazon EC2为例说明自动缩放

亚马逊的Auto Scaling服务让您可以根据用户定义的策略，计划和运行状况检查自动启动或终止EC2实例（分别达到定义的最小值和最大值）。

亚马逊的CloudWatch用于实时监控EC2实例。CloudWatch会自动提供CPU利用率，延迟和请求计数等指标，可以使用CloudWatch访问最新的统计信息，查看图表和设置警报。

定义1

Amazon CloudWatch 警报是一个监视单个指标的对象。警报可以根据度量标准的值更改状态。当警报改变状态并且在该状态中保持若干时间段时，将调用操作。您可以配置CloudWatch警报，以便在特定指标达到阈值时将消息发送到自动缩放。当警报发送消息时，自动调节执行ASG上的相关政策可以向上或向下扩展组。

请注意，当指定的度量标准在多个时间段内保持高于阈值时，将调用Auto Scaling操作。（与我们的持续异常多少分钟再报警有相似的意思）

定义2

一个政策是一组自动缩放的指令，指示该服务如何对CloudWatch的警报消息作出回应。为自动扩展和自动缩小设置了单独的策略。与Auto Scaling策略关联的两个关键参数如下：

ScalingAdjustment：要扩展的实例数。正增量会增加当前容量，负值会从当前容量中消除。

AdjustmentType：指定ScalingAdjustment当前容量的绝对数量还是百分比。

自动缩放操作（例如向上扩展）通常需要一段时间才能生效。鉴于此，您可以指定冷却时间（暂时定义）以确保在完成上一个自动缩放事件后，才触发新的自动缩放事件。

定义3

冷却时间是启动缩放活动之后的一段时间，在此期间不会发生其他缩放活动。

冷却时间是可配置的，并为系统提供时间去执行和调整任何影响容量的新扩展活动（如放大和缩小）。

在AWS上，也可以进行时间性的自动缩放，称为预定缩放。特别是，基于计划的扩展允许您扩展应用程序以响应可预测的负载变化。例如，游戏做活动，流量在周五晚上开始增加并且一直持续到周日晚上，您可以根据Web应用程序的可预测流量模式来扩展容量。

要创建计划的缩放操作，您必须指定缩放操作的开始时间以及缩放操作的最小、最大和所需大小。在指定的时间，自动缩放将使用缩放操作来指定最小值、最大值和所需大小的值来更新组。

Netflix公司采用了政策扩展，基于每秒传入请求数（RPS）对集群进行扩展/缩小容量。为什么使用RPS作为驱动自动缩放的度量？因为它与吞吐量直接相关。

自动扩缩容的原则

避免乒乓效应，比如扩容后量下来的，但是立马触发了缩容的阈值，像乒乓球一样回来扩缩容，需要满足扩容后每个ASG的关键指标高于缩容阈值，而缩容后每个ASG的关键指标低于扩容阈值

积极主动，而不是反应，特别是针对启动较慢的应用。例如，加载Netflix订阅者的元数据和预先计算某些功能需要花30分钟。对于此类应用，以主动方式触发放大事件至关重要，而非反应性。

积极向上，保守向下。提供最佳用户体验对业务至关重要。因此，您可能希望采用积极的扩展策略，以便能够处理超出预期的流量增长。此外，积极的放大方法为冷却期间的流量增加提供了缓冲。相反，采用缩减策略时，建议小于流量减慢（比历史趋势更慢）的速度。积极的缩减可能会意外地导致供应不足，从而业务体验产生负面影响。

可伸缩性分析。确定扩大规模的门槛是定义自动扩展策略的一个不可或缺的步骤。低阈值将导致ASG中的实例利用不足;相反，高阈值可导致更高的等待时间，从而降低用户体验。需要找到两者之间的平衡（如第2､3章提到的，明确业务的体验标准和影响业务的关键指标并找到它的天花板）

细数文章中提到的扩缩容的算法

固定金额自动缩放：其实就是按固定量自动调节，按固定数量的实例向上/向下扩展ASG。比如当流量达到阈值时，自动加5个实例

按百分比缩放：按照当前容量的百分比向上或向下扩展ASG

启动时感知缩放：应用程序启动时间长可归因于多种原因，例如，加载元数据。如前所述，在启动时间较长的情况下，需要主动扩容。按当前容量的百分比向上/向下自动调标。如果启动时间过长，则按算法加大ASG的比例。对于缩容则不需要考虑动态因子，与向上扩展不同，缩小D的阈值不需要调整，因为应用程序在实例终止期间不会引起长时间的延迟。

同时，AWS也针对扩缩容提了一些新的玩法

您可以使用AWS提供的实例保护功能，比如一些中心节点，不能被随意下线的，则可以开启实例保护

针对同一个资源达到不同的阈值会有不同的扩缩容策略。例如<50％，[50％，60％]，[60％，80％]和≥80％分别创建扩展策略，并且它们两者大约同时触发，则自动缩放将查看这两个策略并选择导致变化幅度最大的策略。

Last update: 2024-7-30