关于im:SoCC2018论文DAGOR微信大规模微服务过载控制系统

大规模在线服务零碎的无效过载管制对于避免零碎后端过载至关重要，微信团队自研的过载管制计划 DAGOR 曾经在微信业务零碎中运行了五年多，为微信后端的衰弱倒退提供了重要的保障。

DAGOR 的论文发表在 SoCC2018，本文为该论文的中文翻译版本，英文版本在(https://arxiv.org/pdf/1806.04…)，对原文感兴趣的同学能够点击”。

摘要

大规模在线服务零碎的无效过载管制对于避免零碎后端过载至关重要。通常，过载管制的设计是针对单个服务的。然而因为简单的服务依赖或服务实现的缺点，特定于服务的过载管制可能会对整个零碎造成侵害。在服务开发过程中，开发人员通常难以精确地预估理论工作负载的变动。因而，过载管制与服务逻辑拆散显得至关重要。本文针对面向帐户的微服务体系结构提出了一种过载管制计划 DAGOR。DAGOR 是服务无感知并且以零碎为核心的。它从微服务粒度上治理过载，从而使得每个微服务可能实时地监控其负载状态，并且当检测到过载时，可能和相干服务通过合作形式触发减载(load shedding)。DAGOR 曾经在微信后盾应用了 5 年。试验结果表明，DAGOR 可能在零碎过载时取得较高的服务成功率，同时保障过载管制的公平性。

关键词

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

1. 介绍

过载管制旨在加重零碎呈现过载时的服务无响应。这对于须要确保实现 24×7 服务可用性的大规模在线应用程序来说是至关重要的，只管呈现了不可预测的负载激增。尽管云计算有助于按需配置，但仍无奈解决过载问题——服务提供商受到其可从云提供商处购买的计算资源的限度，因而云提供商须要对其提供的云服务进行过载管制。

传统用于简略服务架构的过载管制假设服务组件数量少，依赖关系小。对于独立服务，过载管制次要针对操作系统、运行环境和应用程序[2,24,29]。对于简略的多层服务，服务入口点的网关监督整个零碎的负载状态，并在必要时回绝客户端申请，例如减载，以避免服务过载[5、7、23]。

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

大型微服务零碎的过载管制必须思考零碎的复杂性和高动态性，这在理论利用中是十分具备挑战性的。首先，所有的微服务都必须被监控。如果任何微服务不在监控范畴内，则可能会在该地位呈现潜在的过载，并进一步波及到相干的上游微服务。因而，零碎可能会呈现级联过载，并最终挂起，导致受影响服务的高提早。然而，依附一些特定的微服务或机器仲裁来监督负载状态是极其艰难的，因为单个微服务或机器没有疾速倒退的部署视图。

其次，因为服务依赖关系的复杂性，让微服务独立地解决过载可能有问题。例如，假如解决客户端的申请须要依赖 k 个服务，然而这些服务以后都呈现过载并且都独立的以概率 p 来拒绝请求。这种状况下，实现客户端的申请的期望值是(1-p)K。如果 p 靠近 1 或者是 k 很大，零碎的吞吐量在这种状况下就趋于隐没。然而零碎过载并不会因为工作负载的削减而加重，因为失败申请曾经被解决的局部依然会耗费计算资源。这将导致系统进入一种难以避免的雪崩状态。

第三，过载管制须要适应服务变动、工作负载动静和外部环境。如果每个微服务都对其上游服务执行服务级别协定（SLA），那么它将极大地减慢这个微服务及其上游服务的更新进度，从而毁坏了微服务体系结构的次要劣势。相似地，如果微服务必须以合作形式替换大量的音讯来治理过载，它们可能无奈适应负载激增，因为过载管制音讯可能会因为零碎过载而被抛弃，甚至进一步好转零碎的过载情况。

为了应答上述挑战，咱们提出了一种用于大规模、面向帐户的微服务架构的过载管制计划，称为 DAGOR。DAGOR 的总体工作原理如下：当一个客户端申请达到入口服务时，它被调配了一个业务优先级和一个用户优先级，这样所有随后触发的微服务申请都会被强制在雷同的优先级上被统一地承受或回绝。每个微服务都为准入申请保护本人的优先级阈值，并通过查看零碎级资源指标，如待处理队列中申请的均匀等待时间，来监督本人的负载状态。如果检测到过载，那么微服务会应用自适应算法调整其负载削减阈值，该算法会尝试缩小一半的负载。同时，微服务还将阈值的变动告诉其间接的上游微服务，以便在微服务管道的晚期阶段能够回绝客户端申请。

DAGOR 过载管制只应用了大量的阈值和微服务之间的边际协调。这种轻量级机制有助于进步过载解决的有效性和效率。DAGOR 也是服务无感知的，因为它不须要任何特定服务的信息来进行过载管制。例如，尽管业务逻辑多种多样，但 DAGOR 曾经部署在微信的业务零碎中，以满足所有微服务的过载管制。此外，DAGOR 对服务变更、工作负载动静和外部环境都具备自适应性，这使得它可能适应于疾速倒退的微服务零碎。

尽管网络门路中的减载问题在文献中曾经失去了宽泛的钻研[8,10,15]，然而本文更侧重于如何为经营微服务零碎建设一个实用的过载管制解决方案。本文的次要奉献在于：（1）介绍了 DAGOR 的设计，（2）分享微信业务零碎中操作过载管制的教训，（3）通过试验验证 DAGOR 的性能。

本文残余的局部组织如下：第二节介绍了微信后端的整体服务架构以及它通常面临的工作负载动静。第三节形容微信微服务架构下的过载场景。第四节介绍了 DAGOR 过载管制的设计及其在微信中的利用。在第五节咱们进行试验以评估 DAGOR，在第六节回顾相干工作并最初在第七节进行全文总结。

2. 背景

作为背景，咱们介绍了微信后端的服务架构，该架构反对 3000 多种挪动服务，包含即时通讯，社交网络，挪动领取和第三方受权。

2. 微信服务架构

微信后端是基于微服务体系结构构建的，其中公共服务递归地组合成具备宽泛性能的简单服务。微信中不同服务之间的互相关系能够被建模为一个有向无环图（DAG），其中顶点示意服务，边示意两个服务之间的调用门路。具体来说，咱们将服务分为两大类：根底服务 (basic service) 和直达服务(leap service)。在服务 DAG 中，一个根底服务的出度（节点出边数）为 0，而直达服务的出度为非 0。换句话说，直达服务能够调用其余服务，如根底服务或者其余直达服务，来触发上游服务工作，而任何工作最终都会汇入到根底服务，不再进一步调用任何其余服务。特地地，在服务 DAG 中，入度边数为 0 的直达服务被称为入口服务。用户收回的任何服务申请的解决总是从一个入口服务开始，以一个根底服务完结。

图 1 展现了微信后端的微服务架构，该架构被分层为三层。数以百计的入口服务停留在顶层。所有的根本服务都搁置在底层。中间层蕴含除了入口服务以外的所有直达服务。每个服务工作都是以自顶向下的形式通过微服务体系结构来构建和解决的。特地地，所有根底服务被所有直达服务共享调用，并且都是服务于用户级目标 1 的最终服务。此外，中间层的直达服务由所有入口服务以及其余直达服务共享。大部分微信服务都属于这一层。

图 1：微信微服务架构

对于微信来说，每天入口服务的申请总数通常为 1010∼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%×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 过载管制

为微信微服务架构设计的过载管制计划称为 DAGOR。其设计旨在满足以下要求：

• 服务无感知： DAGOR 须要实用于微信微服务架构中的各种服务，包含外部和内部第三方服务。为此，DAGOR 不应该依赖任何特定于服务的信息来执行过载管制。这种服务无感知的设计思考有两个长处：首先，过载管制机制具备高度可扩展性，以支持系统中大量的服务，同时适应服务部署的动态性。这对于一直倒退的微信业务至关重要，因为微信业务零碎中部署的各种服务常常更新，例如上线新服务、降级现有服务和调整服务配置等。其次，能够将过载管制的语义与服务的业务逻辑解耦。因而，服务配置不当并不影响过载管制的有效性。相同，过载检测能够帮忙发现导致服务运行时过载的暗藏配置缺点。这不仅有利于服务的开发和调试 / 调优，而且还进步了零碎的可用性和健壮性。
• 独立但合作： 在微服务体系结构中，服务通常部署在一组物理机器上，以实现可伸缩性和容错。实际上，工作负载很难平衡地散布在这些机器上，并且每台机器的负载状态可能会呈现激烈且频繁的稳定，只有多数常见的模式在不同机器之间共享。因而，过载管制应该在单个机器的粒度上运行，而不是在全局范畴内。另一方面，机器间合作的过载管制对于解决组合过载也是必要的。不同机器之间的合作须要以服务为导向，以便上游服务的成功率能够与过载服务的响应率相匹配，只管组合过载会呈现。
• 高效和偏心：当因为过载而不可避免地进行减载时，DAGOR 应该可能维持最好的服务成功率。这意味着在失败的服务工作上所节约的计算资源（即 CPU 和 i /O）被最小化。须要留神的是这些被立刻停止的工作所消耗的计算量很小，因而能够为其余有用的解决让出资源；相同，局部解决但最终被放弃的工作会使得在这些工作上所破费的计算被节约。因而，过载管制的高效是指该机制如何可能最小化在服务工作的局部解决上所耗费的计算资源。此外，当某个服务过载时，其上游服务也应该都可能维持大致相同的饱和吞吐量，而不论上游服务工作对过载服务进行了多少次调用。这反映了过载管制的公平性。

4.1 过载检测

DAGOR 在服务器粒度上采纳去中心化的过载管制，因而每个服务器都会监督其负载状态，以便及时检测潜在的过载。对于针对单个服务器过载的监控，宽泛的性能指标曾经被现有的文献所钻研，包含吞吐量、提早、CPU 利用率、包速率、期待申请数、申请解决工夫等[20, 25, 31]。DAGOR 设计应用期待队列中申请的均匀等待时间（或排队工夫）来剖析服务器的负载状态。申请的排队工夫是由申请达到服务器与其在服务器上被启动解决之间的时间差来掂量的。

通过监控排队工夫来检测过载的理由初看起来并不显著。一个间接的问题是：为什么不思考应用响应工夫 3 来代替呢？咱们认为排队工夫比响应工夫更精确地反映负载状态。与排队工夫相比，响应工夫额定计算申请解决工夫。特地地，解决一个根底服务申请的工夫纯正由本地解决决定，而直达服务申请的解决工夫进一步波及解决上游服务申请的耗时。这导致了响应工夫沿服务调用门路被递归地测量，使得指标不能独自反映服务或服务器的负载状态。相同，排队工夫只受服务器本地解决能力的影响。当服务器因为资源耗尽而过载时，排队工夫与超额的工作负载成比例减少。另一方面，如果服务器有足够的资源来生产传入的申请，则排队工夫会放弃在一个较低的程度上。即便上游服务器可能响应速度较慢，只有上游服务器有足够的资源来解决期待的服务工作，其排队工夫也不会受到影响，只管其响应工夫的确会因为上游服务的响应迟缓而减少。换句话说，只有上游服务器的响应工夫减少，服务器的响应工夫就会减少，即便服务器自身并没有过载。这无力地证实了队列工夫能够反映服务器的理论负载状态，而响应工夫很容易呈现过载误报。

另一个问题是：为什么不应用 CPU 利用率作为过载批示？诚然，服务器中 CPU 利用率高表明服务器正处于高负载状态。然而，高负载并不一定意味着过载。只有服务器可能及时地解决申请（例如，排队工夫较短反映了这一点），即便其 CPU 利用率放弃较高，也不应该认为服务曾经过载。

DAGOR 的负载监控是基于窗口的，并且窗口束缚由一个固定的工夫距离和该工夫距离内的一个最大申请数组成。在微信业务零碎中，只有满足任一个规范，每台服务器每秒或每隔 2000 次申请刷新一次均匀申请排队工夫的监控状态。这种复合束缚确保了在工作负载动静的状况下，监控能够立刻跟上负载的变动。对于过载检测，给定微信中每个服务工作的默认超时值为 500ms，而示意服务器过载的均匀申请排队工夫阈值设置为 20ms。这种教训配置曾经在微信业务零碎中利用了五年多，其有效性已被微信业务流动的零碎健壮性所证实。

4.2 服务准入管制

一旦检测到过载，相应的过载管制就基于服务准入管制。DAGOR 蕴含了一组服务准入控制策略。本文首先介绍了 DAGOR 过载管制中采纳的两种基于优先级的准入管制，而后扩大了该技术，以进一步反对自适应和协同的准入管制。

4.2.1 面向业务的准入管制

微信服务依据其业务意义和对用户体验的影响进行外部优先级排序，相应的服务申请也是如此。例如，登录申请具备最高的优先级，因为用户只有在胜利实现登录后能力与其余服务交互。另一个例子是，微信领取申请比即时消息申请具备更高的优先级。这是因为用户往往对其与金钱相干的交互（如挪动领取）比拟敏感，而他们通常可能承受消息传递服务中的肯定水平的提早或不一致性。微信的运行日志显示，当微信领取和即时消息服务呈现相似的服务不可用期时，用户对微信领取服务的投诉比对即时通讯服务的投诉高出 100 倍。相似的状况也实用于即时消息与朋友圈，因为用户冀望即时消息的内容传递比朋友圈更及时。

DAGOR 中面向业务的准入管制是为每个用户申请调配一个业务优先级，并强制其所有后续申请继承雷同的业务优先级。当服务过载时，其减载策略将优先放弃低优先级申请，为高优先级申请让出资源。用户申请以及它在调用门路上的后续申请的业务优先级是由要在入口服务中执行的操作类型决定的。因为微信的微服务架构中存在着数百个入口服务，所以在入口服务中执行的不同操作的数量有数百个。业务优先级被事后定义并存储在哈希表中，该哈希表被复制到负责入口服务的所有微信后端服务器中。哈希表中的项记录了从操作 ID（示意不同类型的操作）到优先级值的映射。图 3 展现了操作优先级哈希表的逻辑构造。留神，该哈希表并不蕴含所有类型的操作。默认状况下，哈希表中短少的操作类型对应于最低优先级。在哈希表中只记录那些无意排序的操作类型，优先级值越小，示意操作的优先级越高。这导致哈希表中只蕴含几十个条目。因为在入口服务中执行的优先级操作汇合在教训上是稳固的，所以只管微信业务疾速倒退，哈希表依然是紧凑的，很少有变动。

每当一个服务申请触发对上游服务的后续申请时，业务优先级值就会被复制到上游申请。通过递归，属于同一调用门路的服务申请共享雷同的业务优先级。这是基于这样的假如，即任何服务申请的胜利都依赖于它对上游服务的所有后续申请的联结胜利。因为业务优先级独立于任何服务的业务逻辑，因而基于业务优先级的 DAGOR 服务准入管制是服务无感知的。而且，上述面向业务的准入管制易于保护，特地是对于简单且高度动静的微服务架构（如微信后端）。一方面，通过引入操作优先级哈希表，业务优先级的调配在入口服务中实现，并且该哈希表很少随工夫变动 4，这使得业务优先级调配策略绝对稳固。另一方面，微信的微服务架构的动静个别反映在根底服务和直达服务的变动上，而不是入口服务。因为变动频繁服务的申请的业务优先级是从上游服务申请继承而来的，因而这些服务的开发人员能够简略地将面向业务的准入管制性能作为黑盒来利用，而不用思考业务优先级 5 的设置。

图 3：微信入口服务中执行的操作的业务优先级哈希表

4.2.2 面向用户的准入管制

下面提到的面向业务的准入管制限度了是否抛弃申请取决于申请的业务优先级。换句话说，对于服务过载时的减载，面向业务的准入管制假设具备雷同业务优先级的申请要么全副被抛弃，要么全副被承受。然而在过载服务中，对雷同业务优先级的申请进行局部放弃有时是不可避免的。当过载服务的业务优先级的准入级别围绕其“现实最优性”稳定时，这种偶然性就会呈现。为了具体阐明，让咱们思考以下场景：过载服务中的减载齐全基于面向业务的准入管制。假如以后业务优先级的准入级别为 τ，但服务依然过载。而后服务将准入级别调整为 τ -1，即所有业务优先级值大于或等于 τ 的申请都被服务抛弃。然而，零碎很快就发现，应用这种准入级别使得服务处于低负载状态。后果，准入级别被设为 τ，而后服务很快又会过载。上述情景将持续反复。后果，上述场景中，业务优先级等于 τ 的相干申请实际上被服务局部抛弃。

局部抛弃具备雷同业务优先级的申请可能会导致组合过载引发的问题。因为在这种状况下，这些申请实际上是被随机抛弃的。为了解决这一问题，咱们提出了面向用户的准入管制，作为对面向业务的准入管制的弥补。DAGOR 中面向用户的准入管制是基于用户优先级的。准入服务通过一个以用户 ID 为参数的哈希函数动静生成用户优先级。每个准入服务每小时更改其哈希函数。因而，来自同一用户的申请可能会在一小时内被调配同一用户优先级，但在不同时间段调配不同的用户优先级。上述用户优先级生成策略具备双重的合理性。一方面，1 小时周期的哈希函数交替容许用户在长时间段内取得绝对统一的服务质量。另一方面，哈希函数的交替思考了用户之间的公平性，因为高优先级在一天中的每个小时内被授予不同的用户。与业务优先级相似，用户优先级也绑定到属于同一调用门路的所有服务申请中。

面向用户的准入管制与面向业务的准入管制是互相协调的。对于业务优先级等于过载服务业务优先级准入级别的申请，相应的减载操作优先于用户优先级高的业务。一旦服务 A 对过载服务 M 的申请失去胜利的响应，服务 A 对服务 M 的后续申请也很有可能失去胜利的响应。这就解决了由模式 2 的组合过载引起的问题，如图 2.b 所示。此外，图 2.c 所示的模式 3 的组合过载也能够用相似的形式正确处理。假如上游服务 A 按顺序调用两个过载的依赖服务，即服务 M 和服务 N。如果服务 M 的业务和用户优先级的准入级别比服务 N 的准入级别更严格，那么在模式 3 中的组合过载能够被打消。这是因为因为服务 N 宽松的准入级别，一个申请被服务 M 承受意味着其后续申请也被服务 N 承受。因为靠前的服务容易呈现更重大的过载，因而模式 3 中相干服务之间的这种准入级别的条件通常存在于微信业务零碎中。

4.2.3 面向会话的准入管制

除了面向用户的准入管制之外，咱们还提出了面向会话的准入管制，以解决单纯利用面向业务的准入管制所带来的同样问题。面向会话的准入管制基于会话优先级，会话优先级的生成和性能与后面形容的用户优先级相似。惟一的区别是，生成会话优先级的哈希函数将会话 ID 作为参数。当用户胜利登录时，会向其调配一个会话 ID，示意用户会话的开始。会话通常以用户执行确认登记完结。当同一用户在其先前登记后执行另一次登录时，将创立另一个具备不同会话 ID 的会话，从而会相应地生成一个新的会话优先级，只管哈希函数放弃不变。在 DAGOR 中的过载管制方面，面向会话的准入管制与面向用户的准入管制一样无效。但咱们在微信业务零碎中的操作教训表明，面向会话的许准入管制会升高用户体验。这是由微信用户在遇到应用程序服务不可用时，常常抉择登记并立刻从新登录的天然用户行为造成的。同样的景象也经常出现在其余挪动利用中。通过登记和立刻登录，用户将取得一个刷新的会话 ID。因而，面向会话的准入管制为用户调配了一个新的会话优先级，该优先级可能足够高，以至于过载的服务后端承受他 / 她的服务申请。用户可能会逐步发现通过从新登录使他 / 她可能解脱服务不可用状态的“窍门”。当一个技巧被重复验证为无效时，它往往会成为用户习惯。然而，这种技巧并不能帮忙加重零碎后端上理论产生的服务过载。此外，因为呈现了误导性的登记和登录，会引入额定的用户申请，进一步好转过载的状况，最终影响了大多数用户的应用体验。相同，用户的即时从新登录不会影响面向用户的准入管制中他 / 她的用户优先级。因而，在 DAGOR 过载管制中，咱们更偏向于面向用户的准入管制，而不是面向会话的准入管制。

4.2.4 自适应准入管制

微服务零碎中的负载状态总是动态变化的。服务在过载时对其负载状态的变动十分敏感，因为相应的减载策略依赖于超额负载的数量。因而，基于优先级的准入级别应该可能适应负载情况，无效地缩小负载，最大限度地升高对整体服务质量的影响。当过载情况严重时，应将准入级别限度为回绝更多的进入申请；相同，当过载状况弛缓时，应放宽准入级别。在简单的微服务体系结构中，过载服务的准入级别调整必须是主动的和自适应的。这就要求在 DAGOR 过载管制中必须进行自适应准入管制。

DAGOR 依据过载服务的负载状态来调整服务的准入级别。如图 4 所示，DAGOR 应用由业务和用户优先级组成的复合准入级别。每个业务优先级的准入级别与 128 个用户优先级准入级别相关联。设 B 和U别离示意业务优先级和用户优先级，复合准入级别示意为 (B，U)。图 4 中用箭头示意的游标示意以后的准入级别 6 为(2，3)，这示意为所有带有B>2 的申请和带有 B=2 但U>3的申请都将被过载的服务抛弃。向左挪动光标示意进步准入级别，即限度业务和用户优先级。

图 4：复合准入级别

如§4.2.1 所述，DAGOR 放弃了几十种不同的业务优先级准入级别。随着每一个业务优先级别与 128 个用户优先级别的准入级别相分割，由此产生的复合准入级别的数量将达到数万。复合准入级别是以用户优先级为粒度进行调整。为了依据负载状态搜寻适合的准入级别，一种简略的办法是从最低级别开始逐级尝试，即在图 4 中，将光标从最左边向左挪动。留神，对于准入级别的每个设置，服务器必须花一些工夫来验证其有效性，因为负载状态是在某个工夫距离内聚合的。因为传入的申请不可能平均地散布在准入级别上，这种简略的办法往往很难找到适合的设置。这是因为在该办法中对准入级别的每一次调整，即把光标向左挪动一个用户优先级，对过载状况产生的影响很小，但须要工夫来验证其充分性。因而，通过简略的扫描来调整准入级别难以满足自适应准入管制的实时性要求。基于上述简略办法的一个即时改良是执行二分搜寻而不是线性扫描。这使得搜寻复杂度从 O(n) 升高到 O(logn)，n 示意复合准入级别的总数。思考到微信的理论准入级别数量在 104 量级上，O(logn)搜寻波及到十几次调整准入级别的尝试，这依然被认为是不够效率的。

为了进步自适应准入管制的效率，DAGOR 利用一个申请直方图，疾速计算出适宜负载状态的准入级别设置。直方图有助于显示申请在准入优先级上的大抵散布。特地地，每个服务器保护一个计数器数组，其中每个计数器对应于一个由 (B,U) 索引的复合准入级别。每个计数器计算与对应的业务和用户优先级相干的已承受申请的数目。DAGOR 周期性地调整减载的准入级别并重置计数器。调整周期与§4.1 所述的过载检测窗口大小统一，例如，每隔 1 秒或每 2000 次微信业务零碎申请。在每个周期，如果检测到过载，服务器将下一周期的冀望传入申请量下调 α（百分比）, 该值小于以后周期的传入申请量；否则，下个周期的冀望申请数量将进步β(百分比)。从教训上讲，咱们在微信业务零碎中设置了α=5% 和β=1%。给定冀望的准入申请数量，准入级别是依据靠近该数量的直方图中的最大前缀和来计算的，并且依据以后状态以及是否检测到过载来进行调整。设 B∗ 和U∗别离示意业务优先级和用户优先级的准入级别的最佳设置。当检测到过载时，最佳的复合准入级别 (B∗,U∗) 的设置由(B,U)≤(B∗,U∗) 7 的计数器的总和刚好不超过冀望申请数量的束缚所确定。算法 1 总结了 DAGOR 中自适应准入管制的过程。请留神，即便零碎在某些时候没有过载，因为以后的准入级别设置，某些申请仍可能被抛弃，尤其是当零碎正在从上个过载状态复原时。显然，上述办法每次调整准入级别都只波及到一次验证的试验。因而，它比上述的奢侈办法更无效，可能满足自适应准入管制的实时性要求。

算法 1：自适应准入管制

4.2.5 协同准入管制

DAGOR 通过基于优先级的准入管制来强制过载服务器执行减载。对于消息传递，注定被上游过载服务器抛弃的申请依然必须从上游服务器发送，并且上游服务器随后将相应的响应发送回上游服务器以告诉回绝该申请。这种不胜利申请解决的音讯来回传递不仅节约网络带宽，而且耗费过载服务器的缓和资源，例如，序列化 / 反序列化网络音讯。为了节俭网络带宽和加重过载服务器解决多余申请的累赘，倡议在上游服务器晚期回绝注定要抛弃的申请。为此，DAGOR 反对在过载服务器及其上游服务器之间进行协同准入管制。特地是，服务器将其以后的准入级别 (B,U) 附加到它发送给上游服务器的每个响应音讯中。当上游服务器接管到响应时，它将理解上游服务器的最新准入级别。通过这样做，只有上游服务器打算向上游服务器发送申请，它就会依据存储的上游服务器准入级别对申请执行本地准入管制。后果，注定要被上游服务器回绝的申请往往在上游服务器就被抛弃，而从上游服务器理论发送的申请往往会被上游服务器承受。因而，尽管服务器中的准入控制策略是由服务器自身独立决定的，但理论的减载操作由其相干的上游服务器执行。在微服务架构中，上游和上游服务器之间的这种合作极大地提高了过载管制的效率。

4.3 过载管制的工作流程

基于后面提到的服务准入控制策略，咱们当初形容 DAGOR 过载管制的总体工作流程，如图 5 所示。

1. 当一个用户申请达到微服务零碎时，它将被路由到相干的入口服务。入口服务将业务和用户优先级调配给申请，所有后续的对上游服务的申请都继承被封装到申请头中的雷同优先级。
2. 每个服务依据业务逻辑调用一个或多个上游服务。服务申请和响应通过消息传递。
3. 当一个服务接管到一个申请时，它依据以后的准入级别执行基于优先级的准入管制。服务依据负载状态定期调整其准入级别。当服务打算向上游服务发送后续申请时，它依据存储的上游服务准入级别执行本地准入管制。上游服务只发送本地准入管制所容许的申请。
4. 当上游服务向上游服务发送响应时，它将其以后的准入级别附加到响应音讯中。
5. 当上游服务收到响应时，它从音讯中提取准入级别的信息，并更新上游服务在本地的相应记录。

图 5:DAGOR 过载管制工作流

DAGOR 满足在本节开始时提出的微服务架构对过载管制的所有要求。首先，DAGOR 是服务无感知的，因为服务准入控制策略是基于与业务逻辑正交的业务和用户优先级。这使得 DAGOR 广泛实用于微服务零碎。第二，DAGOR 的服务准入管制是独立但协同的，因为准入级别是由单个服务决定的，而准入管制则由相干的上游服务协同执行。这使得 DAGOR 具备高度可扩展性，可用于大规模、适时演变的微服务架构。第三，DAGOR 过载管制是无效和偏心的。因为属于同一调用门路的所有服务申请共享雷同的业务和用户优先级，因而它能够无效地打消组合过载导致的性能降落。这使得上游服务可能在上游服务过载的状况下放弃其饱和吞吐量。

5. 评估

DAGOR 在微信业务零碎中的利用曾经有五年多的工夫了。它极大地加强了微信服务后盾的健壮性，帮忙微信在各种高负荷运行的状况下生存下来，包含在每天的顶峰时段以及非凡事件期间，如中国农历新年前夕。在本节中，咱们进行试验钻研，以评估 DAGOR 的设计，并将其与最新的负载治理技术进行有效性比拟。

5.1 试验设置

所有试验都在外部集群上运行，其中每个节点都装备了 IntelXeonE5-2698@2.3 GHz CPU 和 64GB DDR3 内存。集群中的所有节点都通过 10 千兆以太网连贯。

工作负载：为了独立地评估 DAGOR，咱们实现了一个压力测试框架，模仿在微信业务零碎中应用的加密服务。具体来说，加密服务（示意为 M）专门部署在 3 个服务器上，饱和吞吐量大概是每秒 750 个查问（QPS），因而很容易过载。在另外 3 台服务器上部署了一个简略的消息传递服务（示意为 A），通过依照工作负载的申请屡次调用服务 M 来解决预约义的服务工作。工作负载由 20 个应用服务器综合生成，这些应用服务器负责生成服务工作，并且在试验中从未过载。每个服务工作被编程为通过服务 A 一次或屡次调用服务 M，并且工作的胜利取决于这些调用的联结胜利 8。设 Mx 示意对服务 M 进行 x 次调用的工作组成的工作负载。试验中应用了四种类型的工作负载，即 M1、M2、M3 和M4。对于过载场景，M1对应于简略过载，而 M2、M3 和M4对应于组合过载。

5.2 过载检测

咱们首先评估 DAGOR 的过载检测，这是过载管制的切入点。特地地，咱们试验验证了 DAGOR 的设计抉择，即§4.1 中所探讨的采纳均匀申请排队工夫而不是响应工夫作为负载状态的指标进行过载检测。为此目标，咱们另外实现了一种 DAGOR 变体，应用监督窗口（即每秒或者每 2000 个申请）上的申请的均匀响应工夫作为过载检测指标。设 DAGORq 为基于申请排队工夫的过载检测的 DAGOR 实现 (DAGORr 为基于响应工夫的实现)。咱们别离运行 M1 和M2试验，将进给速率从 250QPS 变动到 1500QPS，进行了试验。图 6 显示了 DAGORq 和DAGORr之间的比拟。对于图 6.a 所示的简略过载，咱们别离将均匀排队工夫和响应工夫的阈值设置为 20ms 和 250ms。从试验后果能够看出，当进给速率达到 630QPS 时，DAGORr就会开始减载，而 DAGORq 能够将减载提早到输入量为 750QPS。这意味着基于响应工夫的负载剖析很容易呈现过载的误报。图 6.b 通过运行 M2 工作负载，在波及到组合过载中进一步证实了这一事实。除了图 6.a 所示的设置外，咱们在图 6.b 中还测量了响应工夫阈值为 150ms 和 350ms 的 DAGORr 的成功率曲线。结果表明，当响应工夫阈值设置为 250ms 时，DAGORr具备最佳性能。然而，因为申请响应工夫中蕴含了特定于服务的申请解决工夫，因而在理论中很难优化 DAGORr 的优化配置。相同，除了 DAGORq 的优越性能之外，因为申请排队工夫与任何服务逻辑无关，它的配置也很容易进行调优。

图 6：不同负载剖析指标下的过载检测：排队工夫与响应工夫。

5.3 服务准入管制

接下来，咱们对 DAGOR 负载治理的服务准入管制进行了评估。如§4.2 所述，DAGOR 服务准入管制是基于优先级的，该优先级进一步设计为面向业务和面向用户。面向业务的准入管制被目前最先进的负载治理技术 [25,32] 广泛采纳。DAGOR 的新鲜之处在于它减少了面向用户的优先级以实现细粒度负载治理，从而进步了端到端的服务质量。此外，DAGOR 过载管制通过自适应准入管制，可能实时地调整服务准入级别，并通过采纳协同准入管制，对减载运行工夫进行了优化。这些不同的策略将 DAGOR 从机制上区别于现有的负载治理技术。因而，为了验证 DAGOR 的翻新在服务准入管制方面的有效性，咱们通过对所有生成的查问申请固定业务优先级的试验，将 DAGOR 与最先进的技术进行了比拟，如 CoDel[25]和 SEDA[32]。此外，咱们还采纳了一种简略的服务准入管制办法，对过载服务 M 随机地执行减载。这种简略的办法能够作为试验的基准。

图 7 展现了别离运行 M1 和M2工作负载的比拟后果。每张图比拟了在采纳不同的服务准入控制技术时，上游服务申请的成功率。此外，咱们也形容了当对应的上游服务过载时，上游服务的实践最优成功率。最优的成功率由 fsat /f 计算，其中 fsat 是使上游服务饱和时的最大进给速率，而 f 是指上游服务过载时的理论进给速率。从图 7.a 能够看出，所有过载控制技术对于简略过载（即 M1）的性能大致相同。然而，当波及到组合过载时，如图 7.b 所示，DAGOR 在M2 的工作负载中的成功率比 CoDel 和 SEDA 高 50% 左右。图 8 通过将进给速率固定到 1500QPS，随着组合过载在 M3 和M4的工作负载中的减少，进一步显示了 DAGOR 的劣势。此外，DAGOR 提供的申请成功率在上述所有后果中都靠近最优。DAGOR 的这种优越性在于它基于优先级的准入管制，尤其是面向用户的策略，对组合过载的无效克制。

图 7：随着工作负载减少的过载管制

图 8：不同工作负载类型下的过载管制

5.4 公平性

最初，咱们评估了在不同的过载状况下过载管制的公平性。公平性指的是过载管制机制是否偏差于一个或多个特定的过载模式。为此，咱们运行由散布平均的 M1、M2、M3 和M4申请组成的混合工作负载。申请由客户端同时收回，进给率从 250 到 2750QPS 不等。每个申请的业务优先级和用户优先级都是在固定范畴内随机抉择的。咱们比拟了 DAGOR 和 CoDel 申请成功率的公平性，后果如图 9 所示。能够看出，CoDel 偏差简略的过载（即 M1）而不是组合过载（例如M2、M3 和M4）。CoDel 的这种偏差使其过载管制依赖于服务工作流，在这种状况下，更简单的逻辑往往在零碎过载时更容易失败。相同，对于不同类型的申请，DAGOR 显示的成功率大致相同。这是因为基于优先级的 DAGOR 准入管制极大地缩小了组合过载的产生，而不论上游对过载的上游服务的调用次数。

图 9：过载管制公平性

6. 相干工作

已有的对于过载管制的钻研次要集中在实时数据库 [3,14]、流解决零碎[4,19,27,28,33] 和传感器网络 [30]。对于网络服务，过载控制技术次要是在 web 服务的背景下提出[11]。然而，这些技术大多是为传统的繁多服务架构设计的，并不适用于基于 SOA 构建的古代大规模在线服务零碎。据咱们所知，DAGOR 是第一个专门解决大规模微服务体系结构过载管制问题的计划。因为微服务架构通常被认为属于 SOA 家族，所以咱们认真钻研了新呈现的用于 SOA 的过载控制技术，这些技术是基于准入管制[5-7,26,31] 或资源调度 [1,2,18,22,24] 的。

通过捕捉古代云零碎的简单交互来管制网络流，能够加重零碎过载的影响。Varys[8]利用协同流和工作形象来调度网络流，以缩小工作实现工夫。然而它依赖于流大小的先验常识，同时也假设了集中式流量管制的可用性。这使得该办法只实用于无限规模的云计算基础架构。Baraat[10]采纳一种相似 FIFO 的调度策略来解脱集中控制，但以就义性能为代价。与这些基于协同流的管制相比，DAGOR 不仅是服务无关的，而且与网络流个性无关。这使得 DAGOR 成为适宜微服务架构的非侵入式过载管制。

Cherkasova 等人 [7] 提出了基于会话的准入管制，它通过计算实现的会话数来监控 web 服务的性能。当 web 服务过载时，准入管制会回绝创立新会话的申请。Chen 等人 [5] 进一步提出了基于 QoS 的会话准入管制，利用会话的依赖性来进步服务过载时的服务质量。然而，这些技术偏向于长期应用的会话，因而不适宜应用蕴含大量短期和中期会话的微信应用程序。与之不同的是，DAGOR 的准入管制是面向用户的，而不是面向会话的，因而它不会在过载管制中偏差服务的任何会话相干属性。此外，以上基于会话的技术依赖于一个集中式模块来进行过载检测和过载管制。这种中心化模块往往成为零碎瓶颈，从而限度了零碎的可扩展性。相同，DAGOR 的设计是去中心化的，因而它具备高度的可伸缩性，以反对大规模的微服务体系结构。

Welsh 等人 [31，32] 提出了分级过载控制技术，该技术依据服务语义将 web 服务划分为若干阶段，并对每个阶段别离执行过载管制。每个阶段都动态地调配一个资源配额来限度负载。只管这种机制与 DAGOR 有肯定的相似性，但其服务划分和动态资源分配的前提条件使其不适用于微信后端等简单的动静服务体系结构。相同，DAGOR 是与服务无感知的，这使得它灵便且高度适应于一直倒退的微服务体系结构。

以缩小响应工夫为指标的网络过载管制曾经失去了很好的钻研 [16]。从微信业务零碎的运行教训来看，面向提早的过载管制在大规模微服务体系结构中的利用成果并不现实。这就促使咱们在 DAGOR 中采纳排队工夫来检测过载。此外，在 THEMIS 零碎中探讨的技术[17] 启发咱们在 DAGOR 设计中思考公平性。

7. 论断

本文提出了用于微服务体系结构的 DAGOR 过载管制计划。DAGOR 的设计是服务无感知的，独立但合作，高效和偏心的。它是轻量级的，并且广泛实用于大规模的、适时演变的微服务零碎，以及对跨团队麻利开发具备敌对性。咱们在微信的后端实现了 DAGOR，并在微信的业务零碎中运行了五年多。除了在微信实际中证实了 DAGOR 的有效性外，咱们置信 DAGOR 及其设计准则对其余微服务零碎也是有启发性的。

经验教训：在微信后端将 DAGOR 作为生产服务运行曾经超过 5 年了，咱们上面将分享从开发教训中获取的教训以及设计原理：

• 大规模微服务体系结构中的过载管制必须在每个服务中都是去中心化和自治的，而不是依赖于集中的资源调度。这对于过载管制框架与一直倒退的微服务零碎相协调是至关重要的。
• 过载管制的算法设计应该思考多种反馈机制，而不是仅仅依赖于开环启发式算法。DAGOR 中的协同准入控制策略就是一个具体的例子。
• 过载管制的无效设计总是从理论工作负载中的解决行为全面剖析中推导进去的。这是 DAGOR 在设计中应用申请排队工夫进行过载检测以及设计基于优先级的两级准入管制以避免组合过载的根底。

致谢

咱们感激匿名审稿人提出的有助于改良论文的宝贵意见和建设性倡议。

脚注

1. 例如，账号服务保护用户的登录名和明码，个性化设置服务保护用户的昵称和其余个人信息，联系人服务保护用户的好友列表，信息收件箱服务缓存用户收到和发送的信息。
2. 实际上，模式 2 和模式 3 在 GFS 类零碎 [13] 中也很常见。在这里，一个大文件被宰割成许多块，散布在不同的存储服务器上，并且须要检索所有块来从新结构原始文件。
3. 响应工夫定义为申请达到服务器与相应响应从服务器发送之间的时间差。
4. 为了性能调优或特地的服务反对，操作优先级哈希表可能会被动静批改。然而，这种状况在微信业务零碎中很少产生，例如，每年 1 次或 2 次。
5. 咱们过来还为服务开发人员提供 APIs，以调整服务申请的业务优先级。然而，后果证实该解决方案不仅在不同的开发团队之间十分难以治理，而且在过载管制方面也很容易出错。因而，咱们在微信业务零碎中弃用用来设置特定于服务的业务优先级的 APIs。
6. 如果没有指定，咱们将在本文的其余部分应用准入级别来示意复合准入级别。
7. 对于两种准入级别 (B1, U1) 和(B2, U2)，咱们使 (B1, U1) < (B2, U2)，如果B1<B2，或者B1=B2 然而U1<U2。
8. 在产生回绝的状况下，雷同的调用申请最多将被重发三次。

参考资料

​ 本文转自微信后盾团队, 如有进犯, 请分割咱们立刻删除

OpenIMgithub 开源地址：

https://github.com/OpenIMSDK/…

OpenIM 官网： https://www.rentsoft.cn

OpenIM 官方论坛： https://forum.rentsoft.cn/

更多技术文章：

开源 OpenIM：高性能、可伸缩、易扩大的即时通讯架构
https://forum.rentsoft.cn/thr…

【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理
https://forum.rentsoft.cn/thr…

【OpenIM 原创】开源 OpenIM：轻量、高效、实时、牢靠、低成本的音讯模型
https://forum.rentsoft.cn/thr…