关于架构:腾讯搜索的系统架构是如何达到99994高可用的

腾小云导读

本文次要是搜寻在稳定性治理实际的经验总结，讲述了搜狗搜寻在技术债治理根底上如何将可用性晋升一个量级，事变级 MTTD（均匀故障检测时间）、MTTR（均匀响应工夫）优化一个量级，尤其在重大事故档次造成一个较强控制力。内容全面且实践性较强，团队的每项能力定位也比拟清晰，除了外围的容灾、发现、应急建设，还在前置拦挡、主动进攻，危险扫盲等维度进行全方位治理。欢送浏览~

目录

1 可用性架构体系

2 容灾 - 高可用的磐石

3 发现 - 化繁为简的艺术

4 应急 - 提效加速器

5 拦挡 - 四两拨千斤之道

6 进攻 - 打铁尚需本身硬

7 扫视 - 多视角分析

8 合作 - 同向合力之道

9 自动化 - 大治有为

10 总结

01、可用性架构体系

忽然被告知产生了一个事变，对稳定性同学而言这是无比难堪的事件。腾讯搜寻在治理之前就是这样的状态，看不到问题，事变在轻轻酝酿；问题不能上浮，被低效应对；影响面在扩充，却无招可用。从而，咱们开始整顿稳定性技术债，思考建设一个怎么的稳定性体系，并付诸实践，在短期内达成高可用指标。

搜寻的稳定性建设是比拟全面的，笼罩了简直所有环节，并从这些环节抓主放次，围绕业务事变管制去建设、强化、欠缺各类能力。

02、容灾 - 高可用的磐石

每个业务欲要达成高可用指标，必须具备一些保命伎俩，可能在紧急情况下将危险拉回可控范畴内，这就是容灾能力的外围定位：止损。尤其是黑盒式（不须要晓得什么起因引入）的容灾伎俩，便于咱们掌握主动，管制住进一步的好转和损失。这些伎俩，可能无损，可能有损，作为一种速效伎俩，可能为咱们争取更大半径的应答空间。搜寻针对波及事变定级的十多个业务都有这种能力布控，依据业务的差别容灾能力也会有差别，咱们抽离出一些外围的，次要如下：

2.1 冗余架构

多地、多活、多实例，作为分布式理念，无论是服务、数据还是专线都应有这样的冗余设计。上面两点是搜寻稳定性在实操时对执行短板的优化。

2.1.1 异地多活

在索引的离线制作上，咱们梳理所有的单机房环节和跨专线问题，对阻塞点和高风险环节输入治理计划和容灾计划，防止单机房异样或者单专线异样引发全业务异样。如离线时效性通路治理，减少抓取后的解决服务多活和 kafka 容灾能力，彻底解决因专线、服务或者 kafka 异样引发的全断流问题，并建设起切流和兜底策略的容灾能力。

2.1.2 同地多实例

对于一些资源耗费比拟小的服务，如 proxy、直达服务等，有的时候为了老本管制更容易疏忽节点可用率问题，异样服务的流量会打到还存活的服务节点上，从而将还存活的服务打垮产生雪崩效应。并且这种服务大多属于阻塞节点，一旦异样可能导致整条链路断掉。如服务 A 在 gz 机房仅有两个节点 A1、A2，其在服务变更过程中会存在两个危险：

针对这种状况，搜寻对这种低消耗服务做一次梳理，将服务的资源配额调低（如 cpu8 核调为 4 核），同时扩容到肯定可用率保障数量。

2.2 三板斧

三板斧（切流、降级、容灾缓存）是大搜重点建设的外围预案，笼罩绝大多数的故障止损，都是分钟级的失效速度。其中，切流是一种黑盒且无损的容灾能力，确定业务受损后的首选且能够第一工夫操作的能力；降级是一种自我屏蔽和去负重伎俩，以此来切断问题源或者开释更多资源来晋升零碎压力；容灾缓存是一种零碎兜底伎俩，在零碎齐全不可用的时候仍能够保障肯定比例的用户体验。

2.2.1 切流

搜寻链路简单，业务也简单，无奈从一处建设切流能力来笼罩所有场景，咱们从链路走向和业务散布，建设四类切流能力。

· 大搜 DNS 切流

域名粒度的切流能力，能够全切也能够按省份将一个域名某机房的流量切至其余机房。这种切流更灵便，更易操作，然而因为域名会有缓存，其全副失效工夫会有 5 分钟。

· 大搜业务 nginx 切流

服务粒度的切流能力，将大搜某一个机房的流量依照 nginx 粒度切至其余机房，会笼罩所有域名进入得流量。相比于 DNS 切流，其失效更快（1 分钟失效），操作粒度更大（所有这个机房的流量都会被切走）。

· 大搜中台支路切流

大搜交融了搜狗的检索系统和 kd 的搜寻中台。因为历史起因，搜狗侧服务大多部署在物理机上，并且具备肯定的冗余，而 kd 侧部署在 123，因老本管制冗余有余。所以，如果大搜从上游切流，kd 侧的流量也会随之变动（非相对，仅局部域名的流量会下发到 kd 侧），但 kd 冗余有余，就须要在 kd 侧把这部分流量切回去，这是在这个支路建设切流的起因之一。另一个起因，kd 侧是独立的支路和零碎，其自身也须要一个切流能力。

· 123 北极星路由规定切流

搜寻除了大搜，还有增长、举荐类等服务，并且很多都是独立的零碎和入口，这些大多是没有 nginx 的，走的是 trpc + 北极星 +123，咱们应用北极星的规定路由插件建设基于主被调的切流能力（基于比例的切流），来满足这些业务场景的需要。

2.2.2 降级

这里次要讲大搜的降级。

大搜应该建设成什么样的降级能力，是建设成 L4 级的主动感知决策及动态化指令，还是建设成 L2 级的人工感知决策及平台化能力，前者须要超高的老本和精准决策力，后者具备超强的灵活性和干涉力。搜寻对降级的外围定位是：超强的干涉止损能力，且零危险额定引入。基于 ROI 和较高可用性定位，咱们抉择 L2 级的计划能力。

· 运行计划

上图为降级执行流程示意图，人工在降级平台操作降级指令，大搜会把这些指令一路下传，各个降级点会解析这些指令信息从判断是否要执行某一降级项。在决策辅助上，咱们独自建设一个稳定性 server 服务来采集和输入降级告警信息，其中图中红标 1 处是降级决策指标，是否要操作降级；红标 2 处是中台侧辅助指标，是否要操作中台支路的降级能力；红标 3 处是搜狗侧辅助指标，是否要操作检索架构的降级能力。

· 指令规定

// 指令协定
1 key = value 模式的 string，其中 key 为 xxDegrade；value 为各指令的组合字符串；2 一个指令最多有三级参数
3 各指令之间用英文 | 宰割
4 指令的二级参数用英文: 指定
5 若指令的二级参数有多个，之间用 & 分隔
6 若指令有三级参数，之间用 #连贯

// 指令名称
$ 支路 $ 服务名称 $ 降级内容，sogou 侧用 sg 结尾，中台侧用 kd 结尾；// 实例 1（一级指令和二级指令组合）xxDegrade = sgZhiling1|sgXX:1&2&3|kdXX:15
// 实例 2（三级指令）xxDegrade = sgXX:XX#1000&XX#300

· 指令集

大搜的降级项次要分这几类：

· 降级平台

降级能力欠缺后，咱们启动平台建设，输入一个对立入口和权限管控，其外围收益为：

2.2.3 容灾缓存

依照腾讯 PCG 的事变定级标准，较短时间的零碎不可用就会成为一个事变，而这个工夫留给止损的 buffer（N 分钟）是很具挑战的，为了给稳定性治理晋升更大的应答半径，咱们设计了一种更大粒度的容灾计划：容灾缓存。大搜的容灾缓存采纳的是一种冷备计划，作为最初的容灾伎俩启动，来应答极其状况下的零碎不可用。

· 方案设计

新建容灾模块 SearchGuard，负责缓存的读写。写入口在前端模块 node，在零碎失常下会始终写，零碎开启容灾缓存是敞开写入；读逻辑在业务 nginx 侧管制，在开关开启的状况下拜访容灾缓存服务，如果拿到后果就返回，读取后果空就持续拜访大搜上游。

· 解决流程

· 预期收益

咱们单从事变影响这个维度来看，容灾缓存在事变定级层面带来的影响有上面两个：

2.3 流控计划

2.3.1 限流

2.3.2 关试验

试验中 interleaving 和 rankab 都会对后端减少实验组 100% 的流量，在试验集中时这部分流量是相当大的，在流量超负载状况下能够思考将试验暂停来缓解零碎压力。

2.3.3 热词打散

搜寻的 SR 和 SH 服务都是本地缓存，分环时依据 query 来分，也就是每个节点是有状态的，SH 本身领有降级措施，能够利用疾速返回无效解决热词 Query 的问题，但当 QPS 很高（如 10 倍涨幅）的状况下，SH 会呈现 GC 卡顿解体的景象。如呈现全网关注的新闻事件，同一关键词的流量打垮单台。长线计划是优化 SR 和 SH 架构，短线计划咱们输入一种容灾能力，以干涉的形式将超高关键词打散。

2.4 柔性策略

当拿不到原始想要的后果和算力时，能够换种代替形式来达到稍次的成果。如本地的 kv 数据或缓存后果来替换近程的后果，本地简化的排序能力来替换简单或者近程大模型算力等等。

2.5 定期演习

容灾预案要想达到预期的成果，首先成果是须要验证的，合乎预期并且不会引入新危险；其次用的时候要保障能力是存活的，不被惯例的迭代磨灭掉；最初要纯熟操作，越快操作越好。所以定期演习是必须的，搜寻是月度演习（每月一次）：

03、发现 - 化繁为简的艺术

发现要能及时且精准地捕捉到问题，并以无效的告警路径通报给正确的接管人。一个简略的无效监控项，要做到及时、精准、通报路径无效、接管人正确，却并不简略。更残暴的事实是搜寻的监控项不止一条，有些同学仅每天接管到的告警量就能达到万级。如此大的监控工程，却不能达到预期成果，反而给开发减少更多困惑和累赘：监控太多了，不晓得监控的啥；告警太多了，不晓得跟哪个；误报太多了，对监控失去信赖；故障回顾时，发现监控没笼罩或者告警没接管到。

搜寻从三个维度去优化：重视用户感知、重视业务输入、重视告警投放，并以层化的形式建设黑盒指标、业务指标、性能指标、统计指标、工程指标、基础设施指标六大类外围监控，胜利将 MTTD 升高一个量级之多。

3.1 黑盒指标

KPI 黑盒告警是大搜最重要的一个监控项，它以探针机的形式对搜寻零碎继续打词（穿透缓存），对状态码为 5XX 的打词后果就会造成 KPI 电话告警，并主动封禁 CD 平台的所有变更动作，直到零碎复原。这个指标直观体现了大搜是否有恙，是切流决策的一个重要依据。

3.2 业务指标

站在业务的角度，监控首先要关注的是业务的外围输入是什么，比方 sug 是否出词、热搜榜的后果数、灵犀的展卡率、大搜的有后果率等。这类指标不须要太多，一个业务一两个就足够，它能精准反馈业务是否还在失常提供服务，所以这个指标的优先级是阻塞性的，一旦告警都要第一工夫染指，所以也是事变防备的一个外围指标。

3.3 性能指标

性能指标是以仿真用户的角度来 check 端的操作成果及返回的后果是否合乎预期。相比业务指标，性能指标更加细化、更加间接、更加贴近用户体验。搜寻对所有波及事变定级业务都有性能指标笼罩 goodcase，外围分为两类：

goodcase 的劣势：

3.4 统计指标

统计指标是基于用户行为的监控，如 pv、uv、点击、曝光、支出等，这些会直观体现零碎的变动；也如用户反馈 case 量的变动，这也是事变定级标准中的一个定级维度，单位工夫用户反馈量突增肯定代表零碎某方面的体现存在重大异样并让用户不称心；也如终端可达性监控，对各类终端在各个省份、各个经营渠道成功率、pv 的变动实时监控，也做到了终端层面的监控等。统计指标应关注时延，时延较差的指标其告警意义就较弱。

3.5 工程指标

下面的指标都是以用户的维度，在零碎外去监督服务，工程指标是深刻零碎内，在服务的要害调用链下来建设外围监控，是一种服务粒度的监控。搜寻在工程指标建设和监控上重视如下几个事项：

3.6 基础设施指标

除了关注零碎自身引入的异样外，还须要关注基础设施异样带来的影响，这在平时 case 的奉献占比也不小，也是容易疏忽的一个监控点。外围关注事项有各个域名流量、提早、丢包率，带宽，防火墙，CDN，DNS 等。

3.7 总述

04、应急 - 提效加速器

在发现和容灾之间应该有一个纽带，可能迅速决策操作哪类容灾能力并迅速执行起来，这就是应急框架的外围意义。如果所有的容灾能力都是主动触发的，那么应急的重要性就不会这么高，如果不是，这个能力是必须要建设的。MTTR 能够拆分为三局部：从发现到染指的工夫、从染指到开始执行止损动作的工夫、止损操作后到零碎复原的工夫。其中第三局部能够了解是容灾失效工夫，因为容灾能力根本都是速效伎俩，这类工夫根本可控。那么，外围须要优化的工夫就是后面两局部，也就是上图中方框内的工夫。

搜寻的应急框架尽量简化流程、了解和决策老本，稳定性会定义一些根本治理因素和建设一些疾速动作来辅助应急框架的自发执行，目前搜寻遇到紧急故障都是大群一键疾速会议，大量的一些同学就能迅速染指并执行容灾预案。

4.1 治理因素

4.2 准则和要求

4.3 应急流程

在这个环节里，搜寻稳定性重点打造五个提速动作：通报快、染指快、止损快、决策快、复原快。

05、拦挡 - 四两拨千斤之道

在回顾历史 case 时，统计发现 90% 的 case 能够在公布初期乃至测试阶段被拦挡住。搜寻在稳定性建设初期就思考往拦挡这块使劲，外围动作如下：

5.1 分级

分级是拦挡的外围，其提供一个缓步空间让从 offline 溢进变更阶段的 case 尽早裸露，并可能将其影响管制在可控范畴内。

5.1.1 预公布

无实在用户流量的线上环境，真正意义上公布前的最初一道验证和拦挡渠道。

5.1.2 CD 分级

预公布 –> 单台 –> 各机房单台 –> 单机房 –> 残余全机房

在 dfly 变更平台，建设严格的分级机制，所有接入的代码、数据、配置都执行分级流程。在腾讯 123 变更平台，因微服务模式，服务较多，咱们梳理搜寻在 123 的要害门路节点，对立推动接入 XAC（一种 pipeline 模式的变更机制），替换 123 的分批公布模式。

5.1.3 沙盒环境

沙盒环境部署 –> 数据沙盒环境 dfly 流水线校验（冒烟用例）–> dfly 上线正式环境

5.2 校验

分级放大了裸露 case 的影响范畴，校验能够及时地发现裸露的问题。校验不仅能晋升分级的成果，如果自动化做的好，还能够肯定水平解决分级带来的上线效率问题。搜寻的外围校验点有这几处：

5.3 品质红线和卡点

offline 是拦挡问题的先锋和大头，标准而弱小的测试力是无力保障。在测试左移的趋势下，放弃住原有测试力程度，进步自动化水平，晋升执行度和执行成果，是搜寻线下拦挡的重大挑战。

5.4 流程和标准

搜寻很早就公布了上线变更流程与运维标准，并将很多事项落地到自动化实现，如 dfly 和 xac 分级、主动校验、上线单推动、公布工夫束缚、case 采集和复盘等等。

06、进攻 - 打铁尚需本身硬

一个好的零碎和架构设计，自身也须要具备肯定的健壮性和容灾力，惯例的一些代码习惯、鲁棒性和异样解决这里不细讲，重点讲架构设计档次的优化和一些主动防御能力建设。

6.1 架构优化

6.1.1 计算和缓存拆散

在 2.3 流控计划里，给出了热词问题的短线计划，这里是长线计划。

SR 是有状态服务，其必须与 memdb 服务依照 1:1 的实例数部署，计算与存储严密耦合，如果热词流量打散到其余实例，会失落该实例的缓存数据。优化计划是革新 SR 为无状态服务，将计算和存储解耦合，存储革新为旁路模式，实例间共享。

6.1.2 上线 / 回滚耗时优化

在 SH 服务启动上，剖析启动耗时点，优化数据加载依赖关系和并行化、优化预热成果和条目量、优化无用的大数据问题等，整体启动工夫优化点 40+%，大幅度晋升启动效率。同时调整分级过程中每个批次的机器量，并建设疾速回滚通道，在保障平安的根底上，减速回滚速度。

6.1.3 申请队列

在中台支路的上游建设申请 hash 和申请队列，短时间内雷同申请的后果复用，彻底解决 qu 因为历史起因引入的 diff 问题（后果不统一）。qu 会输入申请解析内容，并一路带上来，如果 qu 有 diff，整条链路都会产生 diff。申请队列的模式很好地将 qu 的 diff 从外层闭合掉，保障雷同申请上游下发的 qu 内容统一。

6.1.4 分布式缓存

对于一些高申请量服务、阻塞点服务，在其上游建设分布式缓存是一种不错的形式，既能缓解上游压力，同时也能在上游异样时持续提供肯定的服务能力。

6.2 主动进攻

6.2.1 主动降级

除了大降级容灾能力，搜寻零碎自身也建设了很多具备主动决策力的降级能力，这些个别是 query 粒度，具备更强的反应力。

6.2.2 主动熔断

在链路上游模块 SH 减少单机熔断限流器设计，对于网络不可用状况、间断 N 个申请谬误状况、工夫窗口 T 内错误率较高状况启动熔断策略。为了爱护未熔断的失常实例不被流量打垮，减少限流爱护，超过肯定熔断比例后，启动限流，限流比例为

，限流在无故障时单台压力水位左近。

07、扫视 - 多视角分析

这一章重点讲述 where 的问题，痛点在哪、危险在哪、问题在哪。通过这些多视角地剖析，既能找到可用性建设的方向，也能让咱们对系统可用性水平有一个全面且清晰的认知，无效晋升咱们对重大事件或者故障解决时的应答力。

7.1 自省视角

case 复盘是一个重要的被动治理伎俩。每一个线上问题产生，肯定会暴露出整个流程中某些问题。就单个 case 而言，问题共性抽离，可能解决多个潜在问题；多个 case 问题汇总、统计、剖析，就能够看到零碎各个环节单薄水平，从而有针对性去治理。

7.1.1 case 采集机制

建设自动化或半自动化注销入口，尽可能将多地线上问题收集起来，汇总到一个 case 池子里。

// 采集字段信息
填写人（主动）所在部门（主动）CS 等级（必填）日期（必填）形容（必填）影响（必填）模块（必填）发现形式（必填）发现阶段（必填）是否启动应急机制（必填）业务分类（必填）止损伎俩（必填）引入源（必填）引入工夫（必填）产生工夫（必填）发现工夫（必填）染指工夫（必填）止损工夫（必填）复原工夫（必填）完结工夫（必填）case 资料 责任人（必填）责任人归属组（必填）责任人归属总监（必填）是否部署拦挡计划 是否自动化漏测 是否纳入 MTTD&MTTR 考核（必填）MTTD MTTR 染指提早 止损延时 复原提早 违反流程标准 填写工夫（主动）

7.1.2 CS（casestudy）机制

搜寻采取定期复盘机制，每周都有一个固定工夫的复盘会，须要 cs 的 case 就近退出。稳定性提供 case 资料模板及资料要求、复盘重要准则及参加人要求、case 躲避措施及责任人要求等。

cs 机制肯定要保持执行，不仅能够继续欠缺零碎，还能够成员强化稳定性意识。

7.1.3 FL（follow）机制

cs 的躲避措施能够划分优先级，不同的优先级不同的工夫限度，每条措施建设对应的 tapd 跟踪，并将进度定期通报到责任人及大群，同时每周的回顾里也会贴上措施闭合率。

7.1.4 统计分析

依据 case 池子，除了能够剖析一些裸露的零碎薄弱环节问题，还能够基于一些统计信息定期剖析如 MTTD、MTTR、拦挡率、漏测率等外围指标变动，跟踪稳定性治理成果。

7.2 蓝军视角

除了惯例的混沌工程、容灾演练，搜寻提出“危机六问”模型，作为事变和危机治理的外围，从繁琐的监控和治理体系中抽离进去，聚焦外围业务，关注外围输入，从事变标准定义中倒推出“事变管制应该把外围焦点放在什么地位？”。其本质是一个效率问题，便于咱们高效地解决“看到”、“管制”、“复原”三个档次的问题。搜寻以此模型来评估各个业务在事变防备中的治理程度，开掘治理破绽，并推动优化治理。

7.3 链路视角

零碎异样大多出在零碎的某一节点上，多梳理、思考如何在次要链路上做文章，如果无效躲避次要链路节点异样带来的危险是重中之重。

7.4 重保视角

每次重要节假日或者重大事件时，稳定性应该有专门的应答预案。如果预案及容灾能力不可能无效笼罩各类状况，这必定是个大危险，须要提前治理。

08、合作 - 同向合力之道

稳定性无论从广度还是深度都是很泛的，波及的人员、角色、大组、部门都很多。如何无效合作，如何共力建设，是搜寻在可用性治理中一直摸索的一个方向。

8.1 顶层式治理

搜寻在治理初期采取的是稳定性的同学提出治理计划，各个部门出人力的形式。获得了不错的功效，迅速将根底体系建设起来，造成了初步的防治力。然而顶层式治理有显著弊病：

8.2 下沉式治理

让间隔问题最近的人去治理问题，并进步其治理积极性。搜寻在二期治理过程中开始下沉，提出下沉式治理模式，输入三道防护圈机制。各个组出稳定性接口人，并独立制订治理计划，一起承当稳定性指标。

09、自动化 - 大治有为

稳定性建设的每一个环节，都应该踊跃往自动化方向转化。多做机制、工具、平台，以主动的形式去串联一些环节、流程，缩小人为因素参加。如搜寻建设大量监控 oncall、告警主动投放、监控看板、上线墙、搜狗白盒监控投放伽利略、容灾平台、全自动化流水线、goodcase 按模板主动生成机制等。

10、总结

以上是腾讯搜寻在稳定性治理中外围实际方向，在聚焦可用性及事变管制上，也在一直地去偿还一些稳定性技术债，来健全整体的防御力，所以下面的内容会笼罩到各个环节。在根本技术债理清之后，稳定性应聚焦在容灾力、工具、架构优化建设，不同的业务场景和可用性定位就会有不同的治理计划， 无论是哪种，抉择适合的，才是最无效的 。

整篇文章分享到这里就完结啦！各位开发者在做我的项目的同时，也不要忘了定期地去查看、清理技术债权。让我的项目晦涩稳固地运行，这样工作下来也能事倍功半。

-End-

原创作者|姚洪哲

技术责编|宋南 郑锦锋

你对技术债有什么认识？在工作中如何防止技术债的沉积？欢送在腾讯云开发者公众号评论区探讨。咱们将选取 1 则最有创意的评论，送出腾讯云开发者 - 鼠标垫 1 个（见下图）。6 月 15 日中午 12 点开奖。