阿里搜索和推荐关于效率&稳定性的思考和实践

云栖君导读：本文分享了阿里集团从业务效率、资源效率、稳定性三方面来打造了TPP、Tisplus、OpenSearch三大搜索和推荐平台，通过调度系统、管控、高可用分布式服务框架、多机房容灾等手段，实现在不影响业务迭代效率情况下达到4个9的可用性、以及重大故障在5min内快速恢复。

背景

效率和稳定性是我们从工程层面来衡量系统对业务支持能力的两个关键指标。从流程管控上来看，业务效率的提升一定程度上会影响到稳定性，而对稳定性要求过高又会带来对业务效率的影响。从业务的角度来看，成熟的业务会更偏向于稳定性，而新业务更偏向于效率。效率和稳定性兼顾，也就变成了一个巨大的挑战。

我们理解的效率

通常我们提到“效率”更多的是关注开发效率或迭代效率，我们这里称之为“业务效率”。大家通常容易忽视“资源效率”，在阿里集团搜索和推荐现有业务规模下，忽视资源效率的将付出很大的成本。

效率 = 业务效率 + 资源效率

影响业务效率的因素主要有：

1. 开发复杂度

2. 业务迭代流程

3. 业务维护成本

4. 稳定性要求

开发复杂度取决于其生态能为业务的开发提供什么支持，包括语言层面和业务领域所在的第三方生态、集团层面的二方生态、以及业务所在平台。迭代流程一方面可以保证业务功能的正确性，同时也可以提升线上系统的稳定性，但是复杂的流程会很大程度上影响到业务的效率。如何降低业务开发复杂度，为业务开发提供更强大的生态支持？如何简化迭代流程且不影响稳定性？如何降低业务的维护成本，提升其稳定性？

影响资源效率的因素主要有：

1. 稳定性要求：通常出于稳定性考虑会适当的降低资源利用率的要求，比如为了应对流量高峰我们需要提前准备容量，为了容灾我们需要有一定的容量buffer。

2. 资源的管理和分配方式：传统靠人来管理和分配物理机效率低下，所以才有了容器技术以及现在docker的大规模应用，但是没有调度系统的支持docker与传统vm相比并没有明显的优势，并不能有效解决整体资源利用率低的问题。

3. 长尾业务：传统人治的方式无法顾及长尾业务，长尾业务由于其业务规模限制必然存在资源浪费。

4. 资源采购交付时间：通常采购交付时间从业务的角度来看是不可控的，为了应对业务未来的资源需求，我们通常需要提前1年提预算、提前半年左右时间提交采购。而这里时间的把控完全依赖于个人经验。

提升资源效率最直接的手段当然是让所有业务提升资源利用率。而运动式的做这项工作成本巨大收益也不一定能达到预期，还会极大的影响到业务效率和稳定性。如何用更低的成本、在不影响业务效率和稳定性的前提下，持续的让资源利用率保持在合理的范围内，是否敢于延迟采购交付时间？这是我们的挑战。

我们理解的稳定性

通常我们对稳定性最直观的认识就是不core、没有内存泄露，这也是我们通常稳定性测试的范围。往往大家比较容易忽视稳定性另外一个重要的因素 ——— Robustness（鲁棒性）。我们认为稳定性是在任何情况下都不会出现服务异常中断或资源泄露，同时在非正常输入和非正常压力情况下服务在可接受延迟范围内正确响应率不低于一定比例。

导致系统不稳定的因素主要有以下几类：

1. 变更：比如代码或配置的修改上线。

2. 用户行为变化：比如大规模推广导致用户流量增加。

3. 数据的变化：比如用户行为变化后导致的行为点击或PV数据增长、比如商家通过后台系统修改商品数据。

4. 自然因素：比如硬件故障、自然灾害。

针对这些因素，通常我们的应对策略有：

1. 变更管控，即封网。封网可以在特定时间范围内减少由于变更导致的稳定性问题，但是变更通常都是有业务诉求的，在封网结束后变更仍然会执行，只是把风险从一个时间点转移到了另外的时间。封网也无法避免用户行为和数据的变化以及自然因素的问题。

2. 扩容。通过增加资源方式提升系统容量以应对用户行为变化产生的大流量或或数据量的增长，可以有scale-out（增加replica数量）和scale-up（增加单replica资源）两种方式。扩容不但需要付出资源的成本，而且传统运维方式扩容响应时间慢。

3. 性能优化。提升单位资源的服务能力，即单replica的容量。但是这通常需要我们投入大量的人力成本，也需要对系统有足够深入的理解。

4. 限流。通常限流的实现是配置单机或集群整体的最大服务QPS，这里配置该配多少？随着业务迭代性能变化如何同步？是否应该从入口限流？

5. 多机房容灾。多机房能有效应对自然因素导致的稳定性问题，但是多机房也会增加我们的管理成本，同时要多机房互相灾备需要每个机房留有足够的容量buffer。

由上可以看出现有各种方案能一定程度上解决问题，都存在一定的局限性或缺陷，如何发挥其优点同时弥补缺陷并降低成本，以更有效的提升稳定性，这是我们需要考虑的。

如何提升业务效率

业务效率主要是业务的开发迭代效率和维护成本。我们通过平台化来提升效率，主要有TPP、Tisplus、OpenSearch三大业务平台，支持了阿里集团大部分的搜索和推荐业务。

1. TPP：淘宝推荐平台，支持了阿里集团内大部分的推荐业务。

2. Tisplus：阿里集团搜索中台 https://yq.aliyun.com/articles/402309，支持了集团内大部分的搜索类业务。

3. OpenSearch：阿里云开放搜索 https://www.aliyun.com/product/opensearch，为阿里云上的业务提供搜索服务。

通过这些平台业务方可以非常快速的搭建自己的搜索或推荐业务，业务方只需要有一些基本的搜索常识熟悉自己的业务即可，不需要了解分布式问题，不需要有运维经验，甚至也不用关心稳定性问题。这里我们重点结合Tisplus和搜索业务来介绍。

对于没有搜索经验的团队，如何搭建搜索系统支持其搜索业务需求。通常其需要考虑很多方面：Query的分析和处理、离线数据的处理、搭建搜索引擎、相关性、A/B Test，复杂一点的还需要考虑个性化、Online Learning。再进一步，随着业务发展系统规模膨胀，如何对系统进行优化、引擎的行（replica）和列（shard）数量如何配置最优、哪些字段应该有索引、哪些应该建立联合索引、是否应该用cache、哪些pattern对性能影响较大可以优化、如何做容灾、如何提升系统的稳定性？解决这些问题需要具备丰富的搜索引擎、算法和分布式系统经验。

我们结合Tisplus和我们在淘宝主搜索积累的经验，把业务需要关注的部分剥离出来提供可视化的开发和流程支持，不需要关注的由平台来负责，需要平台和业务共同关注的则由平台提供工具辅助支持。

业务开发和流程可视化

从开发层面，对离线数据处理和引擎进行封装，提供可视化的开发，对于复杂的业务逻辑，也可以通过简单脚本的方式来描述，所见即所得。

对于离线数据处理，用户通过我们基于Blink的组件平台进行可视化的开发，描述数据之间的关系，提交后就会自动生成相应的Blink job。对于引擎，通过可视化配置数据源、schema、插件，提交后就会自动搭建引擎服务，并提交任务到Build Service build索引。对于业务逻辑，则通过业务层SP（Search Planner）提供的嵌入式脚本（Lua）机制来开发，同样可以在web console里进行开发、调试。

同时从开发流程上进行完善，提供测试、冒烟、压测等平台支持。

算法产品化

对于一些常用的算法，技术上可能涉及到多个分布式系统角色的协调以及离线的数据分析处理，而业务上来看不同的业务有很大的共性。将这些算法特性沉淀为Tisplus平台的产品功能，业务方只需要通过简单的配置即可以使用。

以个性化算法为例，不同的业务会有不同的item数据和用户群体，用户行为也会各有差异。基础的用户行为有展现、点击，而电商类的还会有收藏、加购、购买等行为。接入Tisplus的业务会统一收集所有的行为日志。业务方可通过基于Blink的组件 平台和机器学习平台Porsche提取特征训练模型，自动同步到Rank Service。也可以产出i2i（item-to-item）和u2i（user-to-item）等数据，自动同步到iGraph（图检索引擎）。在线查询时SP会先调用iGraph获取i2i和u2i信息，再调用Ha3进行检索，然后再调用Rank Service进行排序，给出最终的搜索结果。

运维自动化和智能化

我们强调devops，并不是直接把ops的工作交给业务方，人治的方式并不能解决运维问题。我们希望业务是由业务方负责，但是其只需要关注业务相关的运维操作，比如业务的发布、系统容量规划。其它的比如机器故障、监控、报警等问题，则应该完全由平台来负责。业务方关注的业务的发布和系统容量规划，平台也应该尽量降低其门槛。发布过程中如何保证系统的可用性？如何避免发布业务功能异常导致故障？容量该如何评估，单replica性能怎么样？什么时候该扩容什么时候该缩容？

基于集团的Sigma调度系统，结合搜索的业务，我们打造了搜索的业务调度平台Hippo。所有搜索的系统都由Hippo从Sigma申请资源进行调度。同时我们每个系统都有其对应的二层调度（即ApplicationManager）和管控系统。二层调度主要的职责是从一层调度（即ResourceManager）申请资源、部署业务、业务拓扑结构管理、rolling、节点迁移、自动更换异常节点、节点数据同步name service，并提供各种操作的API。管控系统主要是提供可视化的用户操作入口、管理流程、管理多个机房/集群。对于无数据的服务，其二层调度是Carbon/Fiber，管控系统是Drogo。对于有数据的服务，其二层调度是Suez Admin，管控系统是Suez Ops。我们通过调度系统和管控系统，实现大部分的运维功能自动化。调度系统通过rolling机制加上最小可用度保证在任何情况（发布、重启）下服务的可用性。

通过智能的弹性伸缩，来动态适应业务流量的变化。对于特定的运营活动可能产生的突发流量，业务方可以提前录入其活动起止时间，调度系统也会作为将其作为算法决策的输入。同时我们通过对整个数据反馈、调度和决策链路进行优化，对于无数据的服务其调度响应时间可以做到秒级，让系统有足够的能力应对异常情况。接下来我们在稳定性里还会再提到智能弹性伸缩。

通过离线分析数据和日志，对引擎的部署和配置给出优化建议，比如行列如何分布最优、哪些字段应该增加索引。这里的优化建议还会从平台的角度结合全局资源情况来定，比如从平台角度考虑到调度系统资源分配可能存在资源碎片，我们希望部分业务能适当拆分，用更多的行和列、每一个instance占用更少的内存和CPU。虽然从业务本身的角度来看并不是最优，但是从平台的角度会有非常大的好处。我们跟iDST算法团队合作，给出智能的全局优化建议。

通过kmonitor（监控平台）和烽火台，业务新接入后自动创建相应的监控和报警并将报警转换为事件，同时kmonitor还会对业务的metrics进行检测发现异常点并转换为事件。再通过kmon watch指定事件的处理方式，可以是报警，也可以是其它的定制化处理手段。

通过压测平台，我们定期跟踪业务带来的性能变化，同时在业务做容量规划的时候给出参考建议。TPP上千个场景在双11预热期甚至双11当天都会有频繁的变更，我们通过daily run每天跟踪场景的性能并在每次变更后自动run，保证每一个场景算法变更后系统的稳定和容量。压测平台还支撑了搜索和推荐大规模的全链路压测，由于个性化和cache对系统整体性能影响较大，所以搜索和推荐的压测需要极大的query量，压测平台结合我们的调度系统，充分利用碎片资源实现极低的资源消耗。

如何提升资源效率

我们从两方面来看资源的效率，一是“资源利用率”，二是“资源的维护成本”。

资源利用率 = (可用的机器数 * 调度系统分配率 * 应用水位) / 总机器数

所以我们从4个方面来提升资源效率：

1. 有效的管理机器提升可用机器数，降低闲置机器数及闲置时间

2. 提升调度系统分配效率

3. 提升应用水位

4. 降低资源维护成本

资源的有效管理

这里我们提到“可用的机器数”，那不可用的机器是哪些呢？当然我们并不是指这些机器没用，而是指在我们资源紧缺比如大促过程中不能有效发挥出作用的机器。比如老旧机型由于机型性能差无法跟其它机型混用、比如我们的线下测试环境、预发环境、A/B Test环境、大量长尾应用只需要极少cpu就占用1台物理机的情况。

我们将所有机器统一加入Sigma和Hippo统一管理，低配机型可以由长尾使用，甚至后续在调度系统支持下可以低配与高配机型混用。各种非生产环境可以快速拆除恢复，每次全链路压测前拆掉，压测结束后恢复。所有的长尾应用统一迁移到Drogo，不再有独占物理机的应用。通过Drogo提供的弹性伸缩和自动更换异常节点、自动的监控报警又能降低长尾业务的管理和运维成本。

同时我们通过应用的一键部署和一键建站，加快应用的部署效率，新的机器交付后可以快速投产。这样提交采购的时间也就可以尽量延迟，降低我们采购机器闲置的成本。目前我们可以一键部署基础设施，在一些新机房的建站中得到了应用，后续再扩展到业务的一键部署。

资源的分配效率

搜索的所有在线资源都由Hippo统一管理分配，各个应用申请的资源规格不一，自然也就有了资源碎片问题。如何有效降低碎片提升资源分配率？我们做了两方面的尝试，也取得了较好的结果。

1. 碎片整理。通过搬迁任务，将合适的几个应用compact到一台物理机让物理机的资源分配率最大化。同时还需要考虑同一业务的分布尽量按物理机打散，甚至部分系统由于端口资源问题只能在一台物理机上部署一个instance。碎片整理要求我们所有的任务（离线/batch/streaming/service）都需要具备可动态迁移（起新下老）的能力，Carbon为所有调度系统提供了动态迁移基础能力的支持。

2. 拆分足够多的小规格（0.1 ~ 4 core）容器。一是长尾业务对于性能要求不高，其可以分配小于1core的容器，通过share CPU使用碎片资源。二是结合我们前面提到的跟iDST算法团队合作的智能全局优化建议，让合适的业务拆分出足够多的小规格容器，能够最大化使用碎片资源。

通过这些措施，我们在压测阶段将Hippo整体的分配效率提升到了95%，在双11期间也保持在90%以上。这些离不开我们跟iDST算法团队合作进行的计算资源优化，让我们的调度系统和决策系统真正的智能化。

提升应用水位

通过西弥斯（资源运营系统），我们跟踪线上各系统对资源的使用情况，包括其资源使用总量、水位情况。同时结合智能扩缩容，以及预算和Quota，对于水位不达标的应用，限制其扩容和预算，同时降低其Quota。对于高水位运行的应用由于由智能扩容的支撑，也无须担心稳定性问题。从而可持续的推动应用提升水位。

由于业务本身具有流量周期性特征，在流量低谷期资源消耗低，加上系统为了容灾而预留的容量buffer，所以从全天来看整体的平均资源利用率仍然很低。我们通过在离线混部，在离线任务充分利用这些闲置的资源，从而提升整体资源的水位。

资源的自动化管理

我们机器数量到了一定规模后，硬件异常也就成了常态，降低硬件异常的处理成本很大程度上降低了我们的管理成本。

通过接下来我们将要介绍的稳定性手段，我们把硬件异常对业务的影响降到最低，然后通过西弥斯，我们实现从 故障机器检测 -> 下线 -> 维修 -> 重刻系统 -> 初始化 -> 上线，全部的自动化处理。

同样作为基础设施，机器的内核版本管理、操作系统配置、虚拟IP中间件环境的管理，这些也都是我们“资源”管理的一部分。我们要保障生产环境所有机器内核和系统配置的一致性、保障IP中间件环境的正确性，同时提供对于内核灰度、升级的支持。

效率提升带来的稳定性问题

平台化的好处很明显，极大的提升了业务效率，新业务接入成本低，业务可以低成本试错创新。从平台的角度还可以全局优化提升资源效率节省成本。

但是平台化也带来了更大的稳定性挑战：

1. 平台稳定性问题会放大，平台的问题都是大问题。

2. 长尾业务从平台全局来看规模小不重要，而从用户的角度来看却可能是至关重要。长尾的稳定性也需要保证，所以我们不可能通过靠人分而治之的方式来解决问题。

3. 平台为了用户体验屏蔽了大量的细节，用户在对其细节不够了解的情况下，可能会引入人为的稳定性风险。而我们又不能要求用户具备很资深的分布式系统运维经验，否则为什么还需要用平台？

4. 平台要兼顾资源利用率，我们通过一系列的措施（资源审计、混部）来提升资源利用率，而资源利用率的提升又一定程度上引入了稳定性的风险。

如何提升稳定性

稳定性目标

通常我们用可用性N个9来衡量系统的稳定性，针对不同的可用性目标，系统设计方案上可能会有很大的差异。当可用性目标要求不高时，简单的通过多replica也许就能达成目标。当可用性目标要达到4个9甚至更高时，从单个服务的角度可能就变成了mission-impossible。比如一个典型的搜索业务，会涉及到至少5个子系统，需要各个子系统都达到99.998%整个业务的可用性才能达到99.99%。

我们把稳定性拆分成“服务稳定性”和“业务稳定性”，分别从两个不同的方向来共同达成稳定性目标。我们对服务稳定性目标可能低于4个9，但是要保证业务的稳定性目标要不低于4个9。

服务稳定性

服务稳定性的核心是通过一个robust rpc framework来保证我们的服务在各种异常情况下保证其正常服务能力。一个典型的rpc framework如下图所示：    

这种简单的rpc框架存在很多问题：

1. 静态权重的问题：我们机型换代周期和过保周期不一致，所以必然存在2代甚至更多不同机型同时服务的情况，不同机型服务能力差异较大。同时在我们大规模容器化和混部的情况下，不同物理机的负载不一致也会对容器的服务能力有所影响。所以静态权重已经无法保证server的负载均衡。当我们的调度进一步成熟，未来可能会存在不同计算能力的replica，甚至动态调整部分replica的计算能力。

2. 心跳探测机制的问题：通常心跳探测实现采用7层健康检查（4层健康检查局限性太大这里我们就忽略吧），传统7层健康检查实现是检查特定路径下status文件是否存在并通过HTTP Status Code来进行区分，这已经是脚本或者人肉运维时代的机制。我们现在强调devops，甚至infrastructure as code，需要系统有自动部署的能力，status文件也就退化成了镜像里的一个普通文件，此时7层和4层检查的差异也就不大了。另外跟Server的7层健康检查实现有关，当系统出现异常的情况下，心跳探测请求不一定能反应出系统的异常。就算我们对其实现进行优化，可以让系统异常的情况下返回404，但是也解决不了心跳探测的网络链路跟client实际访问server的网络链路不一致的问题。

3. 单replica服务能力问题：我们通过压测可以得出单replica的服务能力，但是如果超出其服务能力后会怎样？超时还是拒绝服务？此时如果其服务能力反应到心跳探测上，更多流量导到其它replica，极有可能产生雪崩效应。我们也可以对Name Service优化通过保护机制避免雪崩，但是当整体流量超过整个集群的服务能力上限后，Name Service也无能为力了。

4. 集群服务能力扩展问题：这里server可以有多replica，也可以随时调整replica。但是应该什么时候调、调到多少？

5. 熔断问题：server端rt高导致client端资源（连接池或线程池）耗尽，client也就挂了。在多层的分布式服务系统里，问题会逐级向上传递，最终导致整体系统所有服务不可用。

为了解决这些问题将rpc framework扩展成robust rpc framework，我们重新设计了其架构：

这里引入了动态负载均衡、动态timeout（熔断）、自动降级、自动限流、自动扩缩容这一系列的概念，还将集团的EagleEye结合起来。通过动态负载均衡解决静态权重的问题，动态timeout来确保server端的异常不会进一步向上传递放大，异常流量可以通过自动降级和自动限流来最大程度上降低对业务的影响，再通过快速的自动扩容来提升集群服务能力，新扩容的replica可能预热不充分服务能力差，又可以通过动态负载均衡和自动降级来平滑过渡到正常服务能力的状态。自动缩容又可以保证我们及时释放资源提升资源利用率。通过EagleEye我们可以对流量打标标识爬虫流量或压测流量，当负载高时可以优先对爬虫和压测流量进行降级或限流，避免压测影响生产的可用性。这一系列的措施相辅相成，共同保证了我们服务的稳定。

案例：

A线上服务存在bug，B服务在不知情的情况下调用A服务触发bug导致core，影响生产的稳定性。

从稳定性的角度来看，A引入了稳定性风险，系统本身的稳定性是不达标的，应该更多的由A来承担责任。我们对于故障的定责和action也重新进行了定义，我们希望故障的定责和action更关注的是帮助我们的系统向更好的方向演进，而不只是完善我们的流程。

案例：

A服务调用B服务，超时时间为150ms，B由于变更性能下降，延迟从50ms增长到100ms，A线程池耗尽导致故障。

这里的诱因是B，根本原因在于A的超时时间与资源（线程池）设置不匹配。B的性能下降可能是非正常的也可能是正常的，B可能承诺了正常响应时间范围也可能没有承诺，这些都不关键。A应该保证其线程数量与依赖服务的RT相匹配，这里并不是要求B一定要承诺其RT，A可以去动态适配，当B的RT超出A承受能力上限后，A应该通过熔断机制确保自己服务正常，不将B的影响进一步向上传递。

案例：

A服务访问B服务，A服务由于爬虫流量大加上防爬系统C不完善，导致B服务雪崩完全不可服务。

我们有很多流程上的理由让A或者C承担责任。但是为什么B会完全不可服务？B服务完全可以保证自己的最大服务能力，超出部分可以拒绝服务。所以我们认为B应该承担更多的责任。

业务稳定性

前面我们提到对单个服务的稳定性要求可以低于4个9，但是业务的稳定性要求要高于4个9。这就要求我们从更高的维度来思考问题。

影响稳定性有两个重要因素：一是人为因素变更；二是不可预知的非人为因素，比如机房断电、网络链路故障。我们的故障绝大部分的都人为因素导致的，所以首先我们要降低变更带来的风险。集团有封网制度保障关键时期系统稳定，但是封网是以牺牲业务迭代为代价的。我们要在不影响业务迭代的情况下降低变更风险。其次我们要能有效应对不可预知的非人为因素导致的故障。

我们可以对非关键业务进行隔离，将非关键业务剥离出独立服务，该服务可以任意迭代发布。所有依赖该非关键服务的系统可以结合自己的自动降级和熔断机制，保证在非关键服务在任何异常情况下都不影响主要业务。

同时结合非人为因素的问题，我们可以通过多机房部署，分机房发布来降低变更风险和应对机房非人为因素的故障。

这里每个机房内部署了一个完整的业务，包括整个服务调用栈涉及到的所有系统。这里我们把机房当成一个单点，机房内虽然有大量服务器，但是受限于地理、机房基础设施、网络设备等因素，其存在很多单点因素。所以我们把一个机房作为一个“单元”，两个单元就相当于一个业务的两个replica，其中一个replica出现故障，自然应该把流量导到另一个replica。这也是我们通常提到的“单元化”的概念，而搜索“单元化”相比交易等业务一个显著的区别在于，我们的多个单元是完全对等的，不需要考虑数据一致性的问题。

多机房或多单元已经不是什么新鲜的概念，但是还有一些问题没有明确：

1. 如何降低多机房给业务带来的维护成本？

2. 如何把变更的影响控制在机房内？

3. 如何快速发现故障？

4. 如何有效提升监控覆盖率和报警准确率？

5. 故障如何快速止损？

6. 如何降低机房容灾的容量buffer的成本？

前面提到我们有管控系统，基于管控系统，要解决这些问题就比较简单了，我们不只是制定流程规范来约定，还可以将规范变成管控系统的代码来进行强制约束。所以我们在管控系统里提供了多机房的支持，所有服务都可以低成本部署和维护多机房，同时实现了以下规范：

1. 所有变更必须灰度和分机房发布，机房之间有一定发布间隔。

2. 所有系统的机房发布顺序保持一致，避免多个机房同时由于变更导致不可用。

3. 自动化冒烟，冒烟失败不能继续发布。

4. 所有监控自动分机房聚合，快速定位故障影响的机房。

5. 重要监控保证在1min内发出报警。

6. 任何情况下可通过管控系统一键切流，切流后可以直观的看到整个链路所有系统的稳定性情况。

按我们传统经验来看双机房容灾我们的系统水位需要运行在35%以下，三机房容灾我们系统水位需要运行在45%以下。由于超线程和其它的一些因素，我们系统的并发能力并不能随CPU消耗线性增长。也就是说为了极小概率的故障可能性，我们付出了在日常情况下牺牲资源利用率的代价。当我们所有系统都具备了自动降级和自动限流的能力后，在故障发生时我们切流后可以通过自动降级和自动限流承接正常容量之外的流量，可能会对业务带来短时间的极小的影响，但是却能让我们的系统在日常情况下都敢于高水位运行，提升资源利用率。

案例：

A服务依赖于B服务，B服务所支持的功能对业务影响不大。B服务由于变更导致整体超时，A由于B超时导致故障。

这里B服务是非关键服务，A服务把对B服务的依赖变成了关键依赖。这是A服务设计的问题。

案例：

A服务使用iGraph，iGraph双机房部署。其中一个机房由于iGraph变更不可用，另一个机房正常。A服务由于iGraph单机房不可用导致故障。

iGraph的可用性是允许单机房故障的，在单机房故障情况下只要通过name service把流量快速切到其它机房，就可以认为对业务无影响。而这里A服务完全依赖于单个机房的可用性，这是我们不允许的。

总结

 

我们从业务效率、资源效率、稳定性三方面来打造搜索和推荐平台。Tisplus、TPP、OpenSearch支持了大量的搜索和推荐业务，提升业务的效率。我们的调度系统、管控系统、西弥斯，提升资源效率。为了保障业务的稳定性，我们从服务稳定性和业务稳定性两方面着手，沉淀出了我们的高可用分布式服务框架，以及跟管控系统相结合的多机房容灾方案。最终目标是在不影响业务迭代效率情况下达到4个9的可用性、以及重大故障在5min内快速恢复。我们通过一系列的项目逐步完善了我们的系统，包括自动降级和自动限流、智能弹性调度、管控系统、亲维、5min故障快速恢复项目、接入EagleEye等，将我们的经验沉淀为“搜索在线服务稳定性规范”和“搜索业务接入规范”。