Uber的大部分业务都涉及人与人之间的连接，因此客户平台的可靠性对我们的成功至关重要。客户平台支持从随意组合而且超级吃,超级运费而且Raybet2．我们的平台团队拥有4个服务，数千个主机，服务峰值流量高达每秒30万次请求，拥有450多个内部服务。
任何如此复杂的系统都有可能出现故障，尤其是发展如此迅速的系统。分析发生在六个月期间的中断，我们发现28%的中断可以通过以下方法减轻或避免优雅降级．
我们观察到的三种最常见的故障类型是由于:
- 入站请求模式更改，包括过载和不良行为者
- 资源耗尽，如CPU、内存、io_loop或网络资源
- 依赖项失败，包括基础设施、数据存储和下游服务
为了根据请求的临界性主动管理我们的流量负载，我们构建了QoS感知负载管理(QALM)，这是一个基于临界性的传入请求的动态负载脱落框架。当服务由于流量过载、资源耗尽或依赖项失败而降级时，QALM将为更重要的请求优先分配服务器资源，并丢弃不太重要的请求。我们使用QALM的目标是降低任何中断或事件的频率和严重程度，从而在我们的业务中带来更可靠的用户体验。
QALM架构
我们最初将QALM编写为一个Go库，并将其集成到我们最大容量服务之一的应用层中。该框架具有智能过载检测、临界注册和端点隔离等功能，可满足服务质量(QoS)要求。智能过载检测允许QALM在服务降级实例期间为关键请求预留资源，而端点级隔离可以保护特定端点免受流量峰值的影响。
智能过载检测
静态入站速率限制框架(将请求限制在设置的阈值之上)对我们的平台有太多约束。虽然静态阈值需要在服务容量变化时更新，但服务水平协议(SLA)和端点之间的容量差异使配置变得复杂。
动态过载检测器提供了更大的灵活性并提高了硬件效率，特别是在像我们这样复杂的服务中。使用QALM，我们实现了一个过载检测器，其灵感来自于CoDel算法。一个轻量级的请求缓冲区(由goroutine和渠道)为每个启用的端点添加，以监视从调用方接收请求到处理程序开始处理之间的延迟。每个队列在一个滑动时间窗口内监视最小延迟，如果延迟超过配置的阈值，则触发过载条件。
端点隔离
要启用端点隔离，QALM将根据其配置创建单独的队列。每个队列都有自己的过载检测器，因此当一个端点发生降级时，QALM只会从该端点释放其负载，而不会影响其他端点。
请求临界
QALM引入的最重要的特性之一是请求临界性，它确保了降级期间的QoS。QALM根据Uber的业务需求定义了四个级别的临界性:
- 核心基础设施请求:永不放弃。
- 核心行程流程请求:永不放弃。
- 面向用户的特性请求:当系统过载时可能会被丢弃。
- 内部流量(如测试请求):当系统过载时，更有可能被丢弃。
如图2所示，当EP1正在经历降级时，只有来自Consumer1的非关键请求被丢弃，而来自Consumer2的关键请求仍然成功。
QALM支持本地配置文件和通过Uber服务管理系统集成的简单在线图形用户界面(GUI)。GUI服务使用jaeger跟踪为每个端点预填充调用者的数据和默认临界值。通过定期配置同步，来自GUI的更新在几分钟内生效。
负载测试实验
我们使用我们的一个关键生产服务执行了多个负载测试，以量化QALM如何改善优雅降级和临界意识。该集成显著改善了成功请求延迟，并在过载期间正确地丢弃了非关键请求。
优雅降级
我们以每秒6000个请求(RPS)对一个端点进行了压力测试。如果没有QALM，延迟会越来越严重，最高可达20秒。在实践中，大多数服务在这么长的延迟后都会超时。
在启用动态过载检测的情况下运行负载测试会得到令人印象深刻的结果。QALM显著改善了优雅降级，通过丢弃非关键请求(占总数的20%)，将p99延迟保持在400毫秒以下。与没有集成QALM的负载测试相比，我们发现成功请求延迟提高了98%。
临界意识
在系统请求过载期间，QALM丢弃非关键请求，同时保留我们指定为关键的请求。对于这个测试，我们配置了两个具有不同临界性的调用程序(文档:临界和文档-staging:非临界)，让它们以大约2,300 RPS的速率到达相同的端点。当QALM检测到系统过载时，它丢弃了一些文档分期请求，这样所有指定为关键的文档请求都成功了。
从应用层到RPC层
在我们构建和测试QALM之后，我们团队中的四个核心生产服务集成了它，并立即获得了显著的可靠性改进。现在我们知道这个解决方案适用于我们的试点服务，我们将精力重新集中在确定其他团队如何也可以使用QALM上。
从多个QALM服务的采用中，我们发现将代码和配置更改集成在一起减慢了过程。当我们考虑如何将QALM提供给Uber内部的其他团队时，我们专注于三个价值观:
- 负载减少应该是每个服务的内置功能
- QALM应该易于配置
- 服务所有者不必担心将负载减少与业务逻辑代码混合在一起
幸运的是，Uber投资了许多开发者效率项目。其中一个项目是YARPC，一个用于Go服务的开源远程过程调用(RPC)平台。YARPC具有灵活、广泛的特点中间件处理入站和出站请求。
我们将QALM重写为入站中间件，因此它可以很容易地插入到现有的YARPC服务中。此外，我们还为UberFx依赖注入服务框架。使用这种方法，服务所有者在部署QALM时不需要进行任何代码更改，并且可以通过简单的配置启用负载减轻。使用YARPC和UberFx，我们将QALM的实现时间从几天缩短到两分钟以内。
虽然将QALM移到应用层使实现更容易，但我们需要确保它仍然有效地工作。由于QALM为每个端点创建单独的缓冲区，这将不可避免地导致一些CPU开销。为了理解QALM的影响，我们在测试运行中使用了CPU分析，在单个主机上有五个端点，每个端点的RPS为100。将这个配置与没有QALM的配置进行比较，我们发现CPU开销只略微增加了大约3%。
在Uber的生产中使用QALM
为了确保我们新的QALM YARPC插件已经准备好与Uber工程集成，我们与不同团队的另一个团队启动了封闭测试计划。我们把这个测试程序作为一个机会来改进我们的技术文档和集成支持。
我们选择了球队支援超级签证因为他们的服务有一个非常具体的可靠性要求:端点级隔离。该服务的一个关键端点，应用它允许终端用户申请信用卡，需要与其他非关键终端流量峰值隔离。
我们的负载测试主要关注端点级隔离，使用以下参数:
- ~10 RPS应用终点为30分钟
- >非关键端点1200 RPS峰值getProvidedCards
外卖
我们开始专门为我们的团队开发QALM，当我们看到它如何提高服务可靠性时，我们知道它可以使整个Uber工程团队受益。从我们开发和集成QALM的经验中，我们学到了一些经验:
- 可靠性特性不应该与业务逻辑混合在一起。服务所有者应该能够根据需要轻松地插入或禁用它。将QALM构建到RPC层使得采用非常容易。
- 参数比语言更有说服力。量化可靠性改进使服务所有者更容易理解QALM的价值。通过全面的性能负载测试，我们可以为可靠性增强提供令人信服的案例。
- 文档是很重要的，特别是对于自助入职。我们提供了全面的wiki、监控仪表板、负载测试说明和警报模板，以帮助服务所有者理解流程。
- 当您为RPC层做贡献时，协作是非常重要的。我们一直在这个项目上与多个团队合作，并主动向利益相关者提供更新。
前进
我们正在继续改进QALM，使团队更容易实施，并进一步提高可靠性。具体而言，我们打算:
- 为服务所有者构建自动化流程，以便在执行负载测试时减少手动配置，并设置警报以简化集成流程。
- 提高警报阈值，以防止我们的随叫随到工程师的非关键工作。集成异常检测QALM还可以提供更准确的警报阈值。
如果你对构建更高层次的客户平台以支持优步的可持续增长感兴趣，那就来吧加入我们，发挥影响力．
订阅我们的通讯以跟上优步工程公司的最新创新。
确认
QALM是由客户平台基础团队建立的斯科特么，萍金，风王，鑫鹏．我们也要感谢克丽丝Kowal感谢RPC团队在这个项目上的合作。最后，如果没有我们工程经理的支持，QALM是不可能建成的Deepti切，Chintan沙,燕张．
