多年来，我一直在亚马逊服务平台团队工作。我们的团队开发的工具，帮助我们的服务所有者，如Amazon Route 53和Elastic Load Balancing，快速创建服务，和客户-呼叫他们。其他Amazon命令提供的功能，如指标测量，认证和监测服务的所有者，以及建立客户图书馆和文件。为了使服务管理员不必手动添加这些功能，服务平台开发团队实现了一体化一次，然后他们可以通过配置访问每个服务。

然而，也有一些困难，例如，我们无法确定如何提供适当的默认设置，特别是选项，（a）在生产或可获得性方面：例如，很难确定标准的客户等待时间，因为我们的平台不知道API延迟的特点。服务的所有者和客户也会遇到类似的问题，所以我们继续开发，做了一些有用的发现过程中。

此外，很难确定可以同时向服务器上的客户开放的标准连接数量。此设置有助于防止服务器超载。特别是，我们想为服务器配置最大的连接量与一个类似的负载平衡指数。这是在Elastic Load Balancing出现之前，所以硬件的负载平衡是广泛应用的。

我们决定帮助亚马逊服务的主人和客户确定最大的连接量的理想值为平衡负载，它也与我们提供的平台相关。大家一致认为，如果我们能够根据自己的推理作出选择，就可以写模拟这些推理的软件。

理想值的定义是一个非常困难的任务。如果连接的最大数量太低，负载平衡器可能会拒绝多余的请求时，增加他们的数量，即使服务有足够的资源。如果设置太大，服务器可能会减慢或拒绝。如果您指定一个特定的工作负荷的最大连接量为最佳，可能会改变依赖性的生产率或工作量本身。在这种情况下，该值将再次出现错误，导致无法避免的断开和过载。

最后，我们发现，最大连接率太不准确，无法完全解决问题。这篇文章描述了其他办法，例如减轻负担，这些办法给我们带来了良好的结果。

过载解剖学

Amazon系统使用预测的缩放，以防止超载。然而，系统保护必须是多层次的。它从自动缩放开始，并包括安全释放剩余负荷的机制，最重要的是，连续测试。

我们的服务负荷测试表明，服务器在低负荷时的延迟比在高负荷时低。压力很大的问题，如流量冲突，背景变化，删除不必要的数据和输入-输出冲突。随着时间的推移，关键时刻的到来，服务的生产率开始下降得更快。

这种观察所依据的理论叫做普遍尺度定律。这是amdala法的结果。这一理论认为，虽然网络的带宽可以通过平行化提高，但最终它局限于批处理点的通过能力）（也就是说，要完成的任务，）不能平行的

不幸的是，通过能力不仅受到系统资源的限制，而且在系统超载时也常常受到影响。当系统的工作量超过其资源能力时，工作就会放慢。计算机即使在超载时也会接受任务，但在切换上下文时也会花费更多的时间。他们变得太慢，为自己的利益。

在客户与服务器互动的分布式系统中，这通常会导致客户在一段时间内失去耐心，并停止等待服务器的响应。这段时间称为等待时间。当服务器超载达到最大，超时超时，请求失败。下表显示随着服务器响应时间的增加，所需的处理能力（每秒）的提高，并随着时间的推移，达到了一个转折点，当它的性能开始迅速下降。

当回答时间超过了客户等待时间时，可以理解的是，情况并不好，但上图所示时间并不明显。为了说明这一点，可以从客户的角度制定一个访问时间表，视延误而定。而不是使用总的答复时间指标，我们可以用平均答复时间作为指导。请注意，50%的请求得到处理的速度比平均延迟时间快。如果服务的平均延迟与客户等待时间相等，则半数请求的有效期将届满，因此可供利用率为50%。在这种情况下，如果延误增加，就出现了可利用性问题。这是在下面的图表。

遗憾的是，这个时间表很难阅读。为简单起见，可将无障碍环境问题归结为有效通过能力的定义。通过能力是每秒发往服务器的请求总数。有效通过能力-这是一个请求的一部分，处理无错误和相当短的延迟，以使客户能够利用反馈。

正反馈循环

这是一个棘手的问题，他们加强了自己的反馈。如果客户的等待时间已经过期，这将不是我们唯一的问题。更糟糕的是，服务器已经完成的所有工作，这将是徒劳的。在资源有限的情况下，当系统超载时，它不能浪费它的时间。

此外，客户经常重复要求。这将增加系统负荷。如果以服务为导向的建筑呼叫图很深）（也就是说客户呼叫服务，会引起其他服务，而这些呼叫又会引起其他服务的调用），那么服务的质量是很高的。每一级都会有几次重复尝试，下一级的超载将导致其数量的级联增加和工作量的指数增加。

在将这些因素结合起来的情况下，超载形成一个固有的反馈循环，导致在稳定状态下超载。

防止无用工作

乍一看，卸下负荷很简单。当服务器接近超载，它开始拒绝多余的请求，专注于已经通过的。降压目标-支持低延迟的请求服务器决定接受服务发送响应之前，客户超时。在这种情况下，服务器支持很高的访问请求。超载只影响超载流量的可用性。

通过消除剩余负荷控制延迟使系统更容易操作。然而，这一办法的好处难以在上一个时间表中说明。公共可用性线继续向下移动，这看起来很糟糕。不同的是，服务器接受的查询仍然是可用的，由于它们已被快速处理。负载复位允许服务器保持有效的容量和处理尽可能多的请求，即使在增加负荷。然而，卸载程序也涉及到成本，因此，随着时间的推移，服务器受amdala法律的约束，有效的传输能力下降。

测试

当我与其他工程师讨论降压时，我常常说：如果服务没有通过负荷试验，到故障点以后，应准备好这将导致最不恰当的故障。在亚马逊公司，我们花了很多时间来测试我们的服务负荷。如本文章中所介绍的图形，可以帮助我们评估在过载的基本性能，并随着服务的修改跟踪变化。

有许多类型的负载试验。一些负荷试验确保了车队的自动缩放，以适应负荷的增加，而有些人则保持了固定的车场尺寸。如果在过载测试时服务的可用性随着吞吐量的提高而迅速下降到零，这是一个迹象，该服务需要额外的降压机制。理想的情况下，在负载测试，有效的带宽应稳定在接近服务的充分利用，并保持不变，即使在进一步提高负荷。

像Chaos Monkey这样的工具有助于测试服务的混乱工程。例如，它们可能会使中央支助事务厅超载，或造成软件包损失，以模拟超载条件。我们使用的另一种测试方法是使用现有的负荷测试或试验系统。在测试环境中使用恒定负载）（而不是增加）并开始排除服务器。这增加了每个机构的负荷，允许测试其通过能力。这是一个人工增加的方法，减少了车队的规模，方便的单独测试服务，但它不是一个完整的负载试验替代。一个完整的，综合的负载测试也会增加服务依赖性的负担，帮助确定其他瓶颈。

在测试过程中，我们不仅衡量服务器的可用性和延迟，而且从客户端的角度衡量可用性。当这种可用性开始下降时，我们会进一步增加负荷。如果降压工作，即使负荷大大超过了服务的额定能力，通过能力也将保持稳定。

在研究预防机制之前，必须进行超负荷测试。每一个机制都有其复杂性。例如，记住在文章开头提到的服务平台上的所有配置选项，以及如何选择正确的值是很困难的。每一种防止超载的机制都增加了某些保护措施，其效力有限。在测试过程中，指令可以找到系统的瓶颈，并选择消除过载所需的保护措施的组合。

明显性

在亚马逊公司，无论使用什么方法来防止超载，我们正在认真考虑，在防过载保护措施生效时，我们需要什么样的度量和能见度。

当故障保护拒绝请求，此拒绝降低了服务的可用性。当服务犯了一个错误，拒绝了请求，尽管有可用的资源），）例如，如果设定了太低的最大连接量记录假动作。我们试图把错误的工作到零。如果该指令定期检测到假动作频率大于零，那么该服务要么设定的灵敏度太高，要么单个节点会受到永久性的约束。和真正的过载。这可能表明负荷的规模或平衡问题。在这种情况下，可能需要调整应用程序的工作，或转向更适合负荷变化的较大类型的机构。

从直观的角度来看，当卸载导致请求被拒绝时，应确保有控制和测量设备，以知道客户是谁，什么操作他打电话，以及其他信息，将帮助我们调整安全措施。我们还利用警报来确定保护措施是否拒绝了相当大的流量。在部分放弃该制度的情况下，增加资源和消除目前的瓶颈是优先事项。

另一个非明显但重要的因素是在卸载时的能见度。我们意识到，重要的是不要在我们的服务中以失败的请求击落延迟度量。然而，与其他请求相比，推迟请求应该是非常低的。例如，如果一个服务扔了60%的流量，平均延迟可能看起来不错，尽管一个可怕的延迟，成功的请求，由于后一个是由于快速拒绝请求不足。

甩负荷对自动缩放和无障碍区的影响

错误的负载复位可能导致无反应自动缩放。考虑这样的一个例子：该服务配置的喷气式缩放使用CPU，并在一个类似的下载中心拒绝请求的负载。在这个例子中，降压系统减少请求数量，以保持低水平的CPU下载，而喷气式缩放函数接收信号，显示有必要推迟发射新的机构，或者根本没有收到这些机构。

我们还考虑到了在调整自动缩放极限以应对无障碍区故障时的降压逻辑。由于维持了所需的延迟水平，各种服务的规模已达到无法获得与多个可用区相当的资源水平。亚马逊公司的团队经常使用系统的度量，如中央支助事务的下载，以确定服务是否接近资源的极限使用。然而，当使用降压，公园可能更接近于拒绝请求比系统的度量显示，而且，由于缺乏足够的备用资源，无法解决无障碍区的问题。当使用复位，你必须仔细测试服务故障，为了了解车队的资源和能力在某个时候。

事实上，通过减少负荷，可以控制非临界的非高峰期间的流量，从而减少费用。例如，如果设备库处理amazon.com网站的流量，它可以解决，这意味着搜索引擎的旁路流量不值得资源的规模，直到完全多余的可用区。然而，我们非常谨慎地采取这种做法。不是所有的要求都是同样的成本，但证明，该服务必须确保用户流量的可及性区的冗余，同时消除冗余旁路流量，需要精心设计，不断的测试和支持公司的管理。而如果客户不知道该服务是如何配置的，其行为在无障碍区崩溃时可能会更像是在无障碍环境中出现严重的严重故障，比正常的卸载。因此，在以服务为导向的建筑中，我们力求尽早完成加工）【例如，在服务中，它收到客户最初的询价】【正确答案】【正确答案】【正确答案】【正确答案】【正确答案】】【正确答案】【正确答案】】【正确答案】】【正确我们不想做出全球决定，在堆栈的规模确定优先事项。

卸荷机构

关于降压和不可预测的情况，还必须注意导致部分放弃的许多可预见的条件。在亚马逊公司，服务有足够的冗余能力，在不使用额外资源的情况下，应对无障碍区的崩溃。他们利用监管为客户提供一个公平的环境。

然而，尽管有这些保护措施和操作方法，服务在任何时候都有一定的资源，因此可能会由于各种原因而过重。其中包括由于部署不当或其他原因造成的交通量突然猛增、公园资源突然损失。以及用户从简单的查询（例如，从缓存读取）到复杂的）例如，错误或缓存条目丢失。在转运时，该服务必须满足已接受的要求。因此，服务必须避免部分拒绝。在本节下，我们将讨论我们多年来为控制超载而采用的一些特点和方法。

确定拒绝请求的成本

我们一定要对自己的服务进行负荷试验，即使在有效通过能力稳定后也要继续提高负荷。这种方法的主要目的之一是确保在卸载时拒绝请求的费用尽可能低。我们看到了如何很容易跳过随机的插座操作员，这将进一步增加处理请求的成本。

在罕见的情况下，快速拒绝请求可能比保持它更昂贵。在这种情况下，我们慢下来的请求被拒绝，根据（然而，这是重要的，如果保留请求的成本是最低的）（例如，如果他们不延迟应用程序流）。

请求的优先顺序

超载时，服务器可以分析收到的请求，并选择要接受的请求和拒绝的请求。服务器将收到的最重要的查询是ping-要求负载平衡。如果服务器没有响应ping-bug及时，负载平衡将停止发送新的请求到该服务器一段时间，而服务器将停止。如果我们关闭了部分，我们肯定不想减少公园的面积。至于其他的请求，他们的优先顺序设置将是独特的每一个服务。

我们来看一个网站服务提供数据重新开发亚马逊网站。调用一个服务，帮助绘制网页的搜索索引巡视员，肯定不会像人类启动的查询那么重要。为旁路请求提供服务是重要的，但在理想的情况下，它可以转移到非高峰时间。然而，在一个复杂的环境，如amazon.com，大量的服务共享，如果这些服务使用冲突的启发式优先排序算法，这可能会影响整个系统的可用性，并导致工作的简单化。

优先权分配和监管可以一起使用，以避免严格的监管限制，同时保护服务的过载。在亚马逊公司，当我们允许客户超过规定的限制，超过这些客户的要求可以优先于其他客户的要求，在配额。我们花了很多时间研究住宿算法，这些算法尽量减少了无法获得额外资源的可能性。然而，考虑到这些妥协，我们倾向于采用可预测的工作量。

时间观测

如果服务部分处理了请求并注意到客户超时，它可以跳过其他任务并拒绝请求。否则，服务器将继续处理该请求，其延迟的响应将被忽略。从服务器的角度来看，它返回了成功的响应。然而，从等待时间已过的客户的角度来看，发生了一个错误。

为了避免不必要的资源消耗，客户可以在每一个请求中包含提示，告诉服务器他们准备等待多少时间。服务器可以评估这些提示，并以低成本拒绝“注定”的请求。

等待时间的提示可以表示为绝对的时间或持续时间。不幸的是，在分布式系统中的服务器由于时间匹配的问题而臭名昭著。Amazon Time Sync服务补偿偏差，使Amazon Elastic Compute Cloud（Amazon EC2）研究所的时钟与每个AWS区域的卫星和原子钟储备库同步。同步时钟对亚马逊公司的杂志也很重要。将服务器上的两个日志文件与非同步的手表进行比较，使问题更难解决。

跟踪时间的另一种方法是衡量每个计算机的请求的持续时间。服务器能够很好地在当地环境中测量过去的时间，因为他们不需要与其他服务器匹配。令人遗憾的是，以期限表示期望的时间也有其缺点。例如，所使用的定时器必须是单调的，当服务器与网络时间协议同步时不返回）（一个更复杂的问题是，服务器应该知道什么时候开始一个秒表的长度测量。在超负荷的情况下，TCP协议的缓冲区可能会产生大量的请求。当服务器从缓冲区读取请求，客户端等待时间将结束。

当亚马逊公司的系统发送的提示，等待时间，我们试图使用它们的转运。在以服务为导向的架构包含多个跳跃的地方，我们将剩下的时间分配给每一个，让下属服务在呼叫链的结尾知道多久发送有效的响应。

完成已开始的工作

我们不想让有用的工作白白浪费，特别是在过载时。工作白白进行创建了正反馈循环，提高了过载，因为客户经常重复询价，如果服务没有及时响应。在这种情况下，对资源的一个要求变成了多个，乘以服务负荷。当客户等待时间结束，再次尝试，他们往往会停止等待第一次连接的响应，直到他们提出了一个新的连接请求。如果服务器执行第一个请求并发送一个响应，客户可能会忽略它，因为现在他正在等待对再次请求的答复。

正是出于这个原因，我们试图设计的服务，以提供有限的工作。如果API是可用的，它可以返回一个大的数据集（这种API接口返回部分结果和托克恩，客户可以要求额外的数据。我们发现，如果服务器处理请求的最大内存限制，预测额外的服务负荷变得更容易，中央处理机和网络通过能力。如果服务器不知道处理查询需要多长时间，控制资源的可用性是非常困难的。

用户如何使用API服务界面，这是确定需求优先顺序的一个不太明显的机会。例如，该服务有两个API：开始）和结束。为了完成其工作，客户必须能够调用API。在这种情况下，服务应该优先考虑的要求（end），）优先于start请求。如果优先考虑的要求（start），客户无法完成已开始的工作，导致部分拒绝。

做多余的工作的另一个原因是分页。如果客户需要发送多个顺序的请求，从该服务逐页查看结果，但它会在N-1页后发现故障并删除结果，对N-2页的服务要求和重新尝试都是徒劳的。这意味着，和end）请求一样，第一页的请求应优先于以后的页面请求。这也说明了为什么我们设计的服务有限的工作没有无限的翻页从同步操作中调用的服务。

排队观察

在管理内部队列，考虑到请求的持续时间也很有用。在许多现代服务架构中，使用内存队列连接线程集合在不同的工作阶段处理请求。与执行方Web服务平台肯定包括在前景配置队列。对于基于TCP协议的每一个服务，操作系统支持每个插座的缓冲区，这些缓冲区可以包含大量的请求。

负载平衡器也可以添加到队列中的请求或连接到服务过载使用所谓的峰值队列。使用这些队列可能会导致部分拒绝，因为即使收到请求，服务器不知道该请求是排队的时间。在一般情况下，一个安全的解决办法是使用一个溢出配置，迅速拒绝过多的请求，而不是排队。亚马逊公司将这一解决方案纳入下一代的Elastic Load Balancing服务）。Classic Load Balancer服务使用了一个峰值队列，但应用Load Balancer拒绝超量流量。无论配置如何，Amazon团队都在跟踪适当的负载配平度量）【例如，峰值线深度或溢出量】服务。

我们的经验表明，跟踪队列的重要性怎么强调也不过分。令我惊讶的是，我常常在记忆中找到一个排队的位置，在那里我根本没有想到要找他们-在我的服务依赖的系统和图书馆。在分析系统时，有必要假定有一些线，我们还不知道。当然，超载试验提供了比代码分析更多的有用信息，只要能够找到合适和现实的测试方案。

低电平过载保护

服务由几个层次-从负载平衡器到操作系统与netfilter和iptables能力，服务平台和代码。每个级别都提供了一定的保护功能。

在这篇文章的开头，我描述了一个任务，自从我在服务平台开发团队的工作。我们试图确定一个建议的标准连接限制，亚马逊团队可以在他们的负载平衡单元。最后，我们建议工作人员为平衡负载和代理服务器设置一个高的连接限制，授权服务器执行更精确的本地信息的下载算法。然而，重要的是要确保最大的连接量不超过线程和监听过程的数量，以及服务器上的文件描述符。这就要求服务器有足够的资源来处理关键的需求，以检查负载平衡的性能。

业务系统中限制资源使用的功能提供了巨大的机会，在紧急情况下可能是有用的。由于我们知道可能的过载，我们正在采取保护措施，利用适当的指南和具体的指令。iptables工具可以设定服务器接收的连接数量的上限，并拒绝过多的连接比任何服务器程序更经济。这个选项也可以通过更复杂的手段调整，例如，允许以有限的速度安装新的连接，甚至允许有限的速度或连接到源IP地址的数量。源IP地址过滤器是有效的，但不适用于传统的负载平衡。然而，ELB网络Load Balancer甚至通过网络虚拟化保持发端人的IP地址，确保正确的iptables规则，如过滤器。源IP地址。

多层保护

在某些情况下，服务器资源甚至不足以在不延迟的情况下拒绝请求。考虑到这一事实，我们正在考虑所有的跳跃的服务器和客户之间的理解，他们如何能够互动和帮助减少超载。例如，一些AWS默认服务包括复位选项。通过亚马逊API网关提供服务，您可以配置任何API请求的最大速度。通过API Gateway、应用Load Balancer或Amazon CloudFront提供服务，您可以通过指定一系列参数，在AWS WAF中配置剩余流量的排放。

直观性是一个复杂的矛盾。早期拒绝请求是很重要的，因为在这个阶段，排放过量的流量是最便宜的，但明显性也受到影响。正因为如此，我们的保护分为几个级别：服务器收到的工作比它能做的更多，消除过剩的流量，并将足够的信息写入日志，以确保可以确定流量损失。由于服务器可以减少有限的流量，我们希望它的前一级将提供保护，以防止交通量的限制。

对过载的新看法

这篇文章提到，减少负荷的必要性是由于系统的工作进度缓慢，同时承担大量的任务。当资源限制和冲突等因素变得重要时。由于延误最终会导致无用的工作，增加请求的频率，并造成更大的负担，因此产生了过载反馈周期。重要的是，要避免这种规模的普遍性法律和AMDAL法律所造成的影响，同时避免过多的负担，并保持可预测的水平。稳定的性能，即使在过载。面向可预测和稳定的性能-亚马逊服务设计的关键原则。

例如，亚马逊DynamoDB是一个数据库服务，提供可预测的性能和可用的规模。即使工作量大幅度增加并超过分配的资源，DynamoDB也支持可预测的有效能力的延迟。自动化DynamoDB、适应性资源分配和按要求开展工作等因素迅速作出反应，以提高有效的通过能力，同时适应不断变化的环境。增加工作量。在此期间，有效的带宽保持稳定，同时保持了可预测的服务生产率高于DynamoDB，并提高了整个系统的稳定性。

AWS Lambda是一个更具普遍性的服务，以可预测的性能。每个API呼叫是在一个单独的环境中运行的，它提供了一个稳定的计算资源。这个执行环境总是一个单一的要求。这种方法不同于服务器模式，根据这种模式，每个服务器都有多个API接口。

通过隔离每一个API挑战独立资源）（在计算机系统，内存，磁盘或网络），可以绕过AM达尔定律的某些方面，因为一个API挑战的资源不会与另一个挑战的资源发生冲突。因此，如果负载超过有效容量，后者将保持稳定，而不是像在更传统的服务器环境中下降。这不是灵丹妙药，因为依赖性会减慢，同时增加手术次数。但是，至少在这种情况下，我们在本条中讨论的中心站资源不会发生冲突。

这种隔离的资源是相对较低的，但重要的是现代的非压缩计算机环境的优势，如AWS Fargate，Amazon Elastic Container Service）（亚马逊ECS）和AWS Lambda。在亚马逊公司，我们发现，实现卸载需要很大的努力：从设置流束到选择最大连接到负载平衡器的理想配置。为这些配置选择合理的标准值是非常困难或不可能的，因为它们取决于每个系统的独特运行特性。这些新的无纸计算环境确保低水平的资源隔离，并提供高水平的调节器（为防止超载，应使用限制和同时操作次数控制设备。在某种程度上，而不是追求完美的标准值，我们可以完全避免这种配置，并确保不同类型的过载没有任何配置。

补充资料

戴维亚纳采克在AWS兰布达首席工程师。戴维自2006年以来一直在开发Amazon软件，以前曾在Amazon DynamoDB和AWS IOT以及内部网络服务平台和车队自动化系统方面工作。戴维最喜欢的课程之一是期刊分析和操作指标的仔细检查。因此，他正在寻找使系统无障碍运行的方法。

类似材料

时间超时，再尝试，并推迟与推特的存在，实施性能测试，指示分布式系统的操作控制