英语原文共 13 页，剩余内容已隐藏，支付完成后下载完整资料

微信大规模微服务过载控制系统

摘要

大规模在线服务系统的有效过载控制对于防止系统后端过载至关重要。通常，过载控制的设计是针对单个服务的。但是由于复杂的服务依赖或服务实现的缺陷，特定于服务的过载控制可能会对整个系统造成损害。在服务开发过程中，开发人员通常难以准确地预估实际工作负载的变化。因此，过载控制与服务逻辑分离显得至关重要。本文针对面向帐户的微服务体系结构提出了一种过载控制方案DAGOR。DAGOR是服务无感知并且以系统为中心的。它从微服务粒度上管理过载，从而使得每个微服务能够实时地监控其负载状态，并且当检测到过载时，能够和相关服务通过协作方式触发减载(load shedding)。DAGOR已经在微信后台使用了5年。实验结果表明，DAGOR能够在系统过载时获得较高的服务成功率，同时保证过载控制的公平性。

关键词

过载控制，服务准入控制，微服务架构，微信

1. 介绍

过载控制旨在减轻系统出现过载时的服务无响应。这对于需要确保实现24times;7服务可用性的大规模在线应用程序来说是至关重要的，尽管出现了不可预测的负载激增。虽然云计算有助于按需配置，但仍无法解决过载问题——服务提供商受到其可从云提供商处购买的计算资源的限制，因此云提供商需要对其提供的云服务进行过载控制。

传统用于简单服务架构的过载控制假定服务组件数量少，依赖关系小。对于独立服务，过载控制主要针对操作系统、运行环境和应用程序。对于简单的多层服务，服务入口点的网关监视整个系统的负载状态，并在必要时拒绝客户端请求，例如减载，以防止服务过载。

然而，现代在线服务在架构和依赖性方面变得越来越复杂，远远超出了传统过载控制的设计目标。现代在线服务通常采用面向服务的架构（SOA），该架构将传统的单一服务体系结构划分为通过网络协议连接的子服务。微服务架构，作为SOA的一种特殊化，通常由数百至数千个子服务（即微服务）组成，以支持复杂的应用程序。每个微服务在一台或多台机器上运行一组进程，并通过消息传递与其他微服务通信。通过分离不同微服务的实现和部署，微服务体系结构促进了对每个微服务的独立开发和更新，而不管底层编程语言和框架。这就为复杂的在线应用程序的跨团队开发提供了灵活性和生产力。

大型微服务系统的过载控制必须考虑系统的复杂性和高动态性，这在实际应用中是非常具有挑战性的。首先，所有的微服务都必须被监控。如果任何微服务不在监控范围内，则可能会在该位置出现潜在的过载，并进一步波及到相关的上游微服务。因此，系统可能会出现级联过载，并最终挂起，导致受影响服务的高延迟。然而，依靠一些特定的微服务或机器仲裁来监视负载状态是极其困难的，因为单个微服务或机器没有快速发展的部署视图。

其次，由于服务依赖关系的复杂性，让微服务独立地处理过载可能有问题。例如，假设处理客户端的请求需要依赖k个服务，但是这些服务当前都出现过载并且都独立的以概率p来拒绝请求。这种情况下，完成客户端的请求的期望值是(1-p)K。如果p接近1或者是k很大，系统的吞吐量在这种情况下就趋于消失。但是系统过载并不会因为工作负载的削减而减轻，因为失败请求已经被处理的部分仍然会消耗计算资源。这将导致系统进入一种难以避免的雪崩状态。

第三，过载控制需要适应服务变化、工作负载动态和外部环境。如果每个微服务都对其上游服务执行服务级别协议（SLA），那么它将极大地减慢这个微服务及其下游服务的更新进度，从而破坏了微服务体系结构的主要优势。类似地，如果微服务必须以协作方式交换大量的消息来管理过载，它们可能无法适应负载激增，因为过载控制消息可能会由于系统过载而被丢弃，甚至进一步恶化系统的过载状况。

为了应对上述挑战，我们提出了一种用于大规模、面向帐户的微服务架构的过载控制方案，称为DAGOR。DAGOR的总体工作原理如下：当一个客户端请求到达入口服务时，它被分配了一个业务优先级和一个用户优先级，这样所有随后触发的微服务请求都会被强制在相同的优先级上被一致地接受或拒绝。每个微服务都为准入请求维护自己的优先级阈值，并通过检查系统级资源指标，如待处理队列中请求的平均等待时间，来监视自己的负载状态。如果检测到过载，那么微服务会使用自适应算法调整其负载削减阈值，该算法会尝试减少一半的负载。同时，微服务还将阈值的变化通知其直接的上游微服务，以便在微服务管道的早期阶段可以拒绝客户端请求。

DAGOR过载控制只使用了少量的阈值和微服务之间的边际协调。这种轻量级机制有助于提高过载处理的有效性和效率。DAGOR也是服务无感知的，因为它不需要任何特定服务的信息来进行过载控制。例如，虽然业务逻辑多种多样，但DAGOR已经部署在微信的业务系统中，以满足所有微服务的过载控制。此外，DAGOR对服务变更、工作负载动态和外部环境都具有自适应性，这使得它能够适应于快速发展的微服务系统。

虽然网络路径中的减载问题在文献中已经得到了广泛的研究，但是本文更侧重于如何为运营微服务系统建立一个实用的过载控制解决方案。本文的主要贡献在于：（1）介绍了DAGOR的设计，（2）分享微信业务系统中操作过载控制的经验，（3）通过实验验证DAGOR的性能。

本文剩余的部分组织如下：第二节介绍了微信后端的整体服务架构以及它通常面临的工作负载动态。第三节描述微信微服务架构下的过载场景。第四节介绍了DAGOR过载控制的设计及其在微信中的应用。在第五节我们进行实验以评估DAGOR，在第六节回顾相关工作并最后在第七节进行全文总结。

2. 背景

作为背景，我们介绍了微信后端的服务架构，该架构支持3000多种移动服务，包括即时通讯，社交网络，移动支付和第三方授权。

2.1微信服务架构

微信后端是基于微服务体系结构构建的，其中公共服务递归地组合成具有广泛功能的复杂服务。微信中不同服务之间的相互关系可以被建模为一个有向无环图（DAG），其中顶点表示服务，边表示两个服务之间的调用路径。具体来说，我们将服务分为两大类：基础服务( basic service)和中转服务(leap service)。在服务DAG中，一个基础服务的出度（节点出边数）为0，而中转服务的出度为非0。换句话说，中转服务可以调用其他服务，如基础服务或者其他中转服务，来触发下游服务任务，而任何任务最终都会汇入到基础服务，不再进一步调用任何其他服务。特别地，在服务DAG中，入度边数为0的中转服务被称为入口服务。用户发出的任何服务请求的处理总是从一个入口服务开始，以一个基础服务结束。

图1展示了微信后端的微服务架构，该架构被分层为三层。数以百计的入口服务停留在顶层。所有的基本服务都放置在底层。中间层包含除了入口服务以外的所有中转服务。每个服务任务都是以自顶向下的方式通过微服务体系结构来构建和处理的。特别地，所有基础服务被所有中转服务共享调用，并且都是服务于用户级目的1的最终服务。此外，中间层的中转服务由所有入口服务以及其他中转服务共享。大部分微信服务都属于这一层。

图1：微信微服务架构

对于微信来说，每天入口服务的请求总数通常为1010sim;1011次。每个入口服务请求随后对协作微服务触发更多的请求，以实现用户期望的行为。因此，微信后端基本上每秒钟需要处理数亿个服务请求，处理如此规模数据的系统显然具有挑战性。

2.2 微信服务部署

在微信业务系统中，微信微服务系统容纳了超过3000个运行在20000台机器上的服务，并且随着微信的日益普及，这些数字还在不断增加。该微服务架构允许不同的开发团队独立地部署和更新各自开发的服务。随着微信的不断发展，微信的微服务系统也在经历着服务更新的快速迭代。例如，从2018年3月到5月，微信的微服务系统平均每天经历了近1000次的变更。根据我们维护微信后端的经验，任何集中式或基于SLA的过载控制机制都很难支持如此大规模的快速服务变更。

2.3 动态工作负载

微信后台处理的工作负载总是随时间变化，并且不同情况下的波动模式也有所不同。通常，高峰时间的请求量比日平均请求量大3倍左右。在个别情况下，例如农历新年期间，高峰期的工作负载可能会高达日平均工作负载的10倍左右。在服务请求量差距如此大的情况下，处理好这种动态工作负载是很有挑战性的。虽然过量配置的物理机器可以承受如此巨大的工作负载波动，但该解决方案显然是不经济的。相反地，通过仔细设计过载控制机制，使其能够自适应地容忍系统运行时的负载波动，显得更加可取和实际。

3. 微信中的过载

微服务架构中的系统过载可能由多种原因造成的。其中最常见的包括：负载激增、服务协议变更导致的服务器容量降低、网络中断、系统配置改变、软件缺陷和硬件故障。典型的过载场景包括过载的服务和相关调用路径上的服务请求。在本节中，我们描述了三种基本的服务过载形式，它们是完整的，并且能够用来构成其他复杂形式的服务过载。图2展示了这三种基本形式，其中过载的服务由警告标志标记，沿调用路径关联的请求由箭头表示。

图2：常见的过载场景

3.1 过载场景

在形式1中，如图2.a所示，过载发生在服务M。在微信业务系统中，服务M通常是一种基础服务。这是因为在微服务架构中基础服务代表了服务DAG中的接收节点，因此它们是最活跃的服务。在图2.a中，箭头表示一种通过服务A调用服务M的请求类型。当服务M过载时，发送到服务M的所有请求都会受到影响，从而导致响应延迟甚至请求超时。更糟糕的是，过载服务的上游服务（如服务A）也会受到影响，因为它们在等待过载服务的响应。这将导致过载从过载服务向其上游服务进行逆向传播。

虽然形式1在SOA中很常见，但形式2和3是大规模微服务体系结构2所独有的。如图2.b所示，形式2类似于形式1，但涉及从服务A到服务M的多次调用。在一些业务逻辑中需要这样的多次调用。例如，在加密/解密应用程序中，服务A首先可以调用服务M来解密某些数据，然后在本地操作明文数据，最后再次调用服务M来加密最终数据。我们将相应的过载场景称为组合过载(subsequent overload)，其正式定义如下：

组合过载是指存在多个过载服务，或者单个过载服务被关联的上游服务多次调用的过载场景。

在组合过载的场景中，上游服务发起的任务被成功执行的条件是当且仅当其所有发出的请求都得到了成功的响应。否则，如果发送到过载服务的任何服务请求未得到满足，则认为服务任务处理失败。显然，形式2（图2.b）和形式3（图2.c）都属于组合过载。形式2中的组合过载是由于对单个过载服务的连续调用，而形式3中的组合过载则是由于对不同过载服务的分开调用导致的。

组合过载增加了有效过载控制的挑战性。直观地讲，当服务过载时随机执行减载可以让系统维持饱和的吞吐。但是，组合过载可能会出乎预料地大大降低系统吞吐量。这是由调用过载服务的连续成功服务约束所导致的。例如，在图2.b所示的形式2中，假设服务A调用服务M两次，服务M配置为容量C，并且在服务过载时随机执行减载。我们进一步假设服务M当前的工作负载为2C，而服务M仅由服务A调用。结果，服务M预计会拒绝一半的请求，因此服务M单次调用的成功率为50%。从服务A的角度来看，其对服务M的调用成功率为50%times;50%=25%。换句话说，服务A发送C个任务，2C的调用请求将被发送到服务M，但是服务A只有0.25C的请求被接受。相反，如果服务A的工作负载为0.5C，那么服务M只是饱和，没有过载，因此服务A任务的成功数量为0.5C。由此可以看出，如果每个服务A任务不得不多次调用服务M，那么组合过载会导致服务A的成功率非常低。同样的论点也适用于图2.c所示的形式3，唯一的区别就是服务A的成功率依赖于服务M和服务N的请求成功率的乘积。

在上述三种基本的服务过载形式中，形式1和形式2在微信业务系统中占主导地位，而形式3相对较少。为了有效地进行过载控制，我们强调在运行工作负载很大时，必须正确处理组合过载，以维持系统吞吐量。否则，在请求服务超载时，简单地采用随机减载可能会导致客户端请求的成功率极低（例如接近零）。这种“服务挂起”现象在我们以前维护微信后端的实践中已经被观察到，这促使我们研究适合微信微服务架构的过载控制设计。

3.2 大规模过载控制的挑战

与面向Web的三层架构和SOA的传统过载控制相比，微信微服务架构的过载控制存在两个独特的挑战。

首先，对于发送到微信后端的服务请求没有单一的入口点。 这使得在全局入口点（如网关）处的集中式负载监控的传统方法失效。此外，一个请求可以通过复杂的调用路径来调用多个服务。即使对于相同类型的请求，相应的调用路径也可能完全不同，这取决于特定于请求的数据和服务参数。因此，当某个特定的服务过载时，不可能精确地确定应该丢弃哪种请求来减轻过载的情况。

其次，即使在分布式环境中采用去中心化过载控制，过多的请求中止不仅会浪费计算资源，还会因服务响应的高延迟而影响用户体验。特别是，当组合过载发生时情况会变得严重。这就要求在请求类型、优先级、调用路径和服务属性方面进行某种协调，以正确地管理减载。然而，由于微服务体系结构中的服务DAG极其复杂，并且在不断地演化，因此，维护成本以及与过载服务进行有效协调的系统开销被认为过于昂贵。

4. DAGOR 过载控制

为微信微服务

全文共23850字，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[2647]