关于android:百度Feed稳定性架构实践

导读：百度 Feed 信息流举荐零碎服务于手百、难看、全民、贴吧等公司绝大多数信息流业务场景，随着业务的高速倒退，整个零碎承载的流量曾经高达数十亿，在宏大的流量规模背地是数百个微服务和数万台机器做撑持。如何保障整套零碎对外的高可用性是整个零碎能力建设的要害，也是咱们团队的一个十分外围的工作方向。为了保障信息流举荐零碎常态 5 个 9 的可用性指标，本文将基于咱们理论的工作教训分享介绍百度 Feed 在线举荐零碎是如何建设高可用性架构的。

一、背景

百度 Feed 信息流举荐零碎服务于公司绝大多数信息流业务场景，目前曾经承载了手百、难看、全民、贴吧等多端产品的信息流举荐能力。如下是从资源漏斗维度给出的百度 feed 举荐零碎的一个简化示意图。

△图 1：零碎简化示意图

零碎简要阐明如下：

• 资源索引库：基于倒排索引或是向量索引提供数千万资源的索引查问能力，通常会有数十甚至数百的不同的资源索引库，别离提供不同类型的资源索引能力。
• 召回层：从数千万的资源中召回跟用户相干的数十万的资源，通常与资源索引库强绑定，比方一些显式召回会在召回层基于用户的 tag 去相应倒排索引库找到用户相干的文档资源。
• 排序层：在大型举荐零碎中，为了均衡算力和成果会构建粗排 & 精排两层排序体系，基于对立的预估打分机制从数万的资源中找到用户最感兴趣的数百条资源送给混排层。
• 混排层：混排层从数百资源中依据用户上下文信息举荐出最终用户看到的十几条资源，通常也会耦合产品的干涉能力，比方资源的多样性管制等。
• 用户模型：用户模型服务提供用户级别的特色获取能力，比方用户感兴趣的标签汇合。
• 文档特色：文档特色服务提供文档级的全特色服务，通常基于文档 id 拜访获取失去。

随着业务的高速倒退，百度 Feed 举荐零碎目前曾经承载了数十亿的在线申请流量，在宏大的流量规模背地是数百个微服务和数万台机器做撑持。如何保证系统的高可用是整个零碎架构设计的要害能力之一，也是咱们整个团队工作的一个外围方向。

二、整体思路

为了保障在线举荐零碎常态 5 个 9 的高可用指标，基于咱们理论工作的一直形象积淀，造成了咱们整个架构的柔性解决能力。

△图 2：多层级柔性解决能力

如图 2 所示，从对单申请的长尾超时异样到 IDC 级大规模故障，基于咱们的理论工作总结，都造成了相应的架构设计计划来应答，接下来进行具体的介绍。

三、具体计划

1. 实例级故障解决方案

在线举荐零碎是由数百个微服务所组成，并且在公有云上进行了大规模的混部，对于常态可用性指标影响最大的因素次要有两个方面：

• 单实例故障所引起的可用性抖动，可能的引发起因包含机器死机、磁盘打满，混部导致的 cpu 过载等。
• 长尾申请超时所导致的失败，这通常是因为零碎的一些随机因子所导致，引发的起因多种多样，且很难被形象归一，比方资源的竞争、接管流量的刹时不均、周期性的内存清理、旁路日志操作等运维流动。

通常对于这类问题的解决方案是减少重试机制和对于异样实例的屏蔽探活机制，咱们的解决思路相似，但在实现方面对可能引发的问题做了进一步演进。

1.1 动静重试调度

重试机制最大的问题是重试工夫的设定和雪崩问题：

• 重试工夫设置的短，意味着常态下重试流量的比例会绝对较大，造成资源的节约，同时会更容易引发上游服务的雪崩，比方一旦上游呈现大面积的提早进化，就会导致流量的整体翻倍，进而整个上游服务都将被拖垮。
• 重试工夫设置的长，意味着整个服务的超时都会长，否则重试的成果就起不到无效的作用，在简单的微服务调度链路上很容易引起超时的倒挂。
• 当然重试工夫的设定，咱们能够基于某个状态上来权衡利弊，给出一个近似的解来防止下面的问题，但业务的疾速迭代须要咱们一直的基于新的条件去更新这个值，这会带来极大的运维老本。

基于上述问题的思考，咱们设计并实现了动静重试调度机制，其核心思想是严格控制重试流量的比例(比方只容许 3% 的流量触发重试)，同时基于分位耗时的实时动静采集机制，将重试的机会调配给须要重试的流量，这同时也意味着咱们不再须要手动去保护超时工夫的设定了。

如下是一个实现比照图：

△图 3：动静重试调度

其外围实现包含：

• 后端分位耗时统计机制：将工夫序列划分为周期性的距离(比方 20s 一个周期)，基于前一个周期的流量去统计分位耗时值，并联合配置化的重试比例来动静的确定 backup\_request\_ms 的值，基于 rpc 的申请级重试工夫设定机制，就达成了咱们动静超时调度的指标了。
• 熔断管制机制：从分位耗时统计机制来看，能够发现这里有个周期的滞后，但不会对咱们成果产生大的影响，这是因为前后两个周期服务的延时变动不会产生很大的稳定，只有可能解决极其状况下滞后所导致的流量超发 (可能引发的雪崩) 问题就能够了，而这正是熔断管制机制所要解决的问题，熔断管制机制通过实时统计重试申请数量，并基于更小工夫窗口来管制申请的比例，同时会通过平滑的机制去解决小窗口带来的统计不准问题。

整个计划在举荐零碎利用后，在常态下可用性绝对可能晋升 90% 以上。

1.2 单实例故障解决

应答单实例故障通常采取的计划是屏蔽和探活机制，但在高可用架构下面还面临如下挑战：

• 辨认能力上：这里蕴含几个维度的考量，准确率、召回率和时效性三个方面，一方面基于单机视角的探活在时效性方面尽管可能做到实时的成果，但因为部分视角的起因准确率往往不高，误辨认的概率较大，而基于全局信息的采集往往会带来时效性的大幅升高，同时在性能方面也会带来肯定折损。
• 策略解决上：一方面探活流量会导致小局部流量的折损，同时非全局视角的屏蔽会导致可用集群的服务容量危险，从而带来整体的好转。

基于上述问题的思考，咱们在动静重试调度的根底上，做了进一步的演进，其核心思想在于实时动静的尽可能升高损失，异步准实时的做全局异样解决管制。

• 实时动静止损：动静重试机制应答的场景是无实例差别的长尾申请，为了应答单实例故障这个特定化的场景，这里有两个形象的解决计划来解决，其一基于可用性和耗时反馈的权重调节机制，利用可用性能够感知到异样实例的存在，从而疾速升高权重拜访，同时在重试实例的抉择上也会加以辨别；利用耗时反馈的平滑调节，会基于压力去自适应的调节失常实例的权重，保障失常实例的可用性不会因为容量问题打垮。
• 全局准实时的止损：基于咱们集成在 brpc 框架外部的组件可能疾速的收集单机视角的实例级信息，而后周期级别的去上报给对立的管制汇聚层。通过高效的代码实现以及两层的汇聚机制基本上能够做到对 client 的性能无影响。更重要的是咱们基于与 pass 的联动来进一步管制咱们对异样实例的控制策略，从而在保障可用性容量的前提下做彻底的止损。

△图 4：全局准实时止损计划

基于上述计划的实现，咱们的零碎基本上可能主动的应答单实例故障的问题，可用性抖动相较于单纯的动静重试计划，抖动区间更小，基本上在 5s 内就能失去收敛，同时在抖动区间可用性的升高幅度也相较于之前降落了 50%。

2. 服务级故障解决方案

这里讲的服务级故障指的是在微服务体系下某个子服务呈现大规模不可用，基本上无奈对外提供任何服务能力。目前基于云原生的微服务化架构是整个业界的发展趋势，设计良好的微服务体系可能极大的进步整个零碎开发的迭代效率，同时在稳定性方向也提供了更多可摸索的空间。在微服务架构的根底上，咱们通过柔性架构的设计思维并联合多层级的容灾设计来应答这种大规模的服务故障场景。这里先给出其外围要点：

• 差异化看待异样：比方对于外围服务，咱们须要有肯定的机制应答可能潜在的异样；对于非核心的服务，咱们要做的可能仅仅是管制它的异样不要扩散到外围链路。
• 多层级容灾机制：通过多层级的容灾机制，当大规模故障产生时，可能在肯定的工夫内保障用户体验的根本无损。

当然服务级故障的解决须要依靠于具体的业务场景来做具体的设计，这里给出局部例子来阐明在 Feed 举荐零碎是如何来进行解决的。

2.1  多召回调度框架

在举荐零碎中，因为召回形式的差异性，往往会设计成多召回框架，每路召回负责某种具体的召回能力，比方从资源层面看，咱们能够分为图文召回，视频召回，从召回算法层面，咱们能够分为 itemcf 召回，usercf 召回等。就单召回路而言，对整体服务的影响取决于它的性能划分：

• 一级召回：比方经营管制相干的召回，间接影响产品的体验感知，不容许失败；
• 二级召回：决定了信息流散发成果，这些召回路如果失败，会导致大盘散发降落显著，单路可容许短期失败，但多路不能同时失败；
• 三级召回：补充召回路，比方摸索趣味召回，对长期成果起到肯定增益作用，短期对产品成果影响不显著，容许短期失败。

对于三级召回路，服务调用失败尽管短期对产品影响不显著，但大规模的超时失败会导致整体性能的提早进化，进而影响到整体服务的可用性。一种间接粗犷的解决方案就是调小这些召回路的超时工夫，使得其即便超时也不会影响到整体，但这显然会升高这些服务的常态可用性，不是咱们想要的成果，为了形象对立的解决这个问题，咱们设计了多召回调度框架，具体设计如下：

△图 5：多召回调度框架

其外围设计包含：

• 召回等级划分：一级召回不容许被动抛弃；二级召回路划分多个群组，目前咱们依照资源类型划分，图文召回群组 & 视频召回群组 &…；每个召回群组由对散发奉献最大的几个召回路组成，群组外部容许超过 40%(可配)的召回路被动抛弃；三级召回路则容许被动抛弃；
• 丢层机制：当满足要求的召回路都返回后，剩下没有返回的召回路会被动抛弃，不在期待返回后果了；
• 弥补机制：抛弃对产品成果始终还是有影响的，只是影响较小而已，为了将这部影响升高到最小，咱们设计了旁路的 cache 零碎，当被动抛弃产生后，利用上次的后果 cache 作为本次的返回，从而肯定水平的升高损失。

基于上述计划的实现，通过咱们理论的演练后果，目前咱们整个零碎能主动应答二 / 三级召回队列服务级故障的解决。

2.2  排序层故障解决方案

排序服务构建在召回之上，提供对多路召回数据的一个对立打分机制，从而实现资源的整体排序，目前业界通常采纳粗排 & 精排的两层排序体系来解决算力和成果相矛盾的问题。

• 粗排通过双塔模型的设计能在一次用户申请中反对数万的资源排序预估，但成果相对来说偏弱；
• 精排通过更简单的网络模型能提供成果更优的排序能力，但反对的预估数量级只有千级别；
• 召回 → 粗排 → 精排 的漏斗过滤体系在算力肯定的状况下很好的晋升了举荐成果。

能够看到，排序服务对整个举荐成果至关重要，一旦排序服务呈现大规模异样，基本上就是在数万的资源外面进行随机举荐了。为了避免这类问题的产生，在设计之初咱们也是充分考虑了故障的应答场景，其外围思路是建设层级的降级机制。

△图 6：排序层降级方案设计

其外围设计包含：

• 构建一层稳固的两头代理层 Router：改层逻辑简略，迭代少，稳定性高，提供异样产生时的降级能力；
• 粗排异样解决计划：旁路建设一路基于资源的点展比和时长信息的排序能力，数据由离线后延统计信息开掘失去，当粗排服务产生大规模异样时，利用该路信息提供应急排序能力；
• 精排异样解决计划：粗排的排序成果相比精排要差，但能够作为精排异样的时候降级数据供整个零碎应用，当精排服务产生大规模异样时，间接利用粗排服务进行降级。

相比于随机举荐来说，整套排序层故障解决方案可能大幅升高故障时对举荐成果的影响。

2.3 弹性容灾机制

基于排序层故障解决方案的进一步演进，咱们构建了针对全零碎的弹性容灾机制，其指标是用一套对立的架构反对异样的解决，当异样产生的时候，升高对用户的体验感知和策略成果的影响。

△图 7：弹性容灾新架构

其外围设计包含：

• 稳固的举荐零碎入口模块 Front：该模块是举荐零碎的入口层，定位是不耦合任何业务逻辑，只反对弹性容灾相干的能力；
• 分层的异样数据建设：个性化容灾数据 +  全局容灾数据，个性化容灾数据通常基于跨刷新数据的缓存来构建，全局容灾数据通过旁路开掘来构建；
• 对立的异样感知机制：跨服务的异样透传能力，当下层 Front 感知到外围服务异样时，就优先获取个性化容灾数据来进行容灾，若无个性化容灾数据，即拜访全局容灾数据来进行容灾。

咱们通过信息流的置顶数据的异样解决来做阐明。

• 全量容灾数据的开掘：旁路周期性的将所有可用的置顶数据写入全局的容灾 cache 中；
• 个性化容灾数据的构建：当用户前一刷的时候，置顶召回服务会取出合乎用户条件的最佳置顶数据汇合，将这部分数据写入个性化容灾数据 cache；
• 服务失败感知：当置顶召回拜访失败，或是从 Front 到置顶召回服务之间任何链路失败时，Front 接管到的数据返回包外面都没有标记置顶数据胜利的标记；
• 容灾管制：Front 会基于返回数据做判断，如没有胜利标记，则开始进行容灾解决，优先读取个性化置顶容灾数据，没有读取到，则开始利用全局容灾数据进行容灾。

该机制构建了对立的弹性容灾能力，一方面利用个性化数据在容灾时尽可能保障策略的损失最小，另一方面利用全局的容灾数据进行兜底容灾尽可能的保障用户体验的无感知。

3. IDC 级故障解决方案

IDC 级的故障解决方案通常采纳异地多主计划来解决，即故障产生时通过 idc 切流来及时止损，百度举荐零碎也采纳相似的计划来解决，这里咱们通过下发历史存储服务的异地多主方案设计来做个介绍。

下发历史存储服务提供用户级别最近的下发、展示、点击过的资源。基于它提供跨申请的策略反对，比方多样性管制，更重要的是避免反复资源的下发。一旦服务挂掉将整个举荐服务将无奈对外提供服务。

其整体设计如下：

△图 8：下发历史存储服务多主架构

其外围设计包含：

• 每个地区保护一份全量的存储；
• 对于读申请，只容许读本地 idc；
• 对于写申请，同步写入本地机房，同时进行跨 idc 同步写入，若写入失败，则写入音讯队列，由音讯队列进行异步跨 idc 进行写操作更新。

当呈现 idc 级故障时，基于异地多主多活架构可能疾速反对切流止损。

四、总结

百度 Feed 举荐架构反对着业务的高速迭代倒退，在整个架构演进过程，可用性建设始终是零碎架构能力的要害指标，咱们通过柔性架构的建设，保障了对外常态 5 个 9 的高可用指标，并具备应答惯例大规模故障的能力。

△图 9：近一个月的进口可用性指标

本期作者 | windmill & smallbird
原文链接：https://mp.weixin.qq.com/s/sm…

举荐浏览

|[](http://mp.weixin.qq.com/s?__b…百度信息流和搜寻业务中的弹性近线计算摸索与利用

|乏味！有料！有温度！「百度技术沙龙」全新降级，重磅回归！

———-  END  ———-

百度架构师

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注！

一键三连，好运连连，bug 不见👇