阿里集团搜索中台TisPlus

                       阿里集团搜索中台TisPlus

搜索中台的发展

    从阿里很多技术产品的发展路径来看都遵循着技术驱动、产品驱动、数据驱动三个阶段，那阿里巴巴的搜索技术的发展也基本基于上述的发展路径。第一个阶段我们走了将近10年的时间，一直到现在我们仍然还在持续优化和打造世界级的搜索技术生态。但如今的阿里集团并不鼓励一杠子到底的小闭环的重复建设，而是鼓励技术体系中台化，所以搜索事业部去承载整个集团的搜索业务需求是义不容辞的职责，但只有技术强大这一个优势是很难在业务数量成规模情况下取得突破，因为对接业务都是以项目的方式开展是不存在外延性的，只能投多少人做多少事情。搜索技术体系必须要有沉淀规模化的复制能力，这是复杂系统发展到现在所必须要有的基本能力了。那这个基于上述原因如何打造搜索中台降低业务支持成本和提高用户接入体验已经更好的规模化管理业务的第二阶段和第三阶段重任就落在我们团队的肩膀上来，好在因为有了第一阶段整个事业部打下夯实基础，让我们往第二和第三阶段行走的过程中始终都是站在巨人肩膀上轻松前行，接下来的章节跟大家更加详细的分享下我们这些年在搜索中台Tisplus方向上做的一些事情。

效率提升产品化

   复杂的平台系统的效率提升我们认为可以分为三大内容，分别是系统运维效率、业务迭代效率、资源分配效率。资源分配效率提升阿里有专门的基于docker容器+自研编排调度框架来解决，Tisplus平台也是利用了集团已有的方案来改善集群资源分配效率，所以这块的内容不会是本文阐述的内容，大家可以另行从其它文章进行了解。Tisplus平台主要还是聚焦在搜索系统运维效率和业务迭代效率的提升，最近一年平台主要做的效率提升的事情主要有：

目标渐进的管控

    传统的管控平台对于管控的理解更多是过程式的驱动，举个搜索服务引擎全量的例子来说明什么叫过程式的管控，如下图所示：

                                                        

     可以清晰的看到对于一个引擎服务全量过程需要4个阶段，每个阶段等待上个阶段执行完毕后按顺序执行，相信绝大部分目前的管控任务执行也都是基于这种架构，这也包括我们第一版的tisplus基于过程顺序流程的任务执行机制来串联各个服务系统任务执行。这样的架构执行目标确定，前往目标的路径也是确定的，最大的问题是中间执行的任务节点出现错误，遇到问题都需要人工接入处理，让系统先达到稳定正常状态，再继续操作。这样的架构体系冒失并没有什么不妥的地方。这就是典型的过程式处理的思路，其实当我们的系统越来越复杂的情况下过程式管控是会不断带来一系列问题的。首先过程任务的诊断和恢复被排除在系统之外，还是完完全全交由人来负责，无形中加重运维&开发人员的负担。也许有人会挑战说，异常概率并不高啊，偶尔处理下并没投入太多，但试想下我们的平台如果支持成百上千业务实例的时候，故障概率也就被成倍放大。   其次很多时候运维管控操作是会出现反复，比如正在做全量任务流程中，出现需要更换机器怎么办，比如升级A版本过程中突然需要改回B版本了，又比如回滚B版本过程中又得升级到C版本怎么办？好吧遇到上述问题，过程式管控只能要么等待任务流程结束，要么中断任务流程。选择前者只能延后处理异常，很多时候线上并不能接受。选择后者如果遇到是中断成本比较高的任务，后续的任务重做、清理中间状态的成本几乎不可接受，而且最为关键的是能够处理这些线上状态的人需要对系统有特别深刻的了解和非常强的线上运维能力，而问题的定位和解决依然取决于个人的能力高低，换句话说这些能力是和人相关的，并没有被沉淀到系统里面，个人能力是不能被传承。
     所以基于上述问题，搜索各个在线服务管控平台提出了目标渐进式最终一致性的自动化运维系统的想法，其核心思想如下图所示： 

                                                           

   我们认为系统状态应该永远是在当前状态（current）到目标状态（target）的多轮迭代的轮回，具体什么意思呢，简单来讲就是当前系统状态是A，这个时候我向系统设定一个目标状态B，系统就开始朝着状态B执行前进，并且执行完所有的必要路径action （1，2，3，4），如下图所示：

                                                              

   但是如果突然这个时候我们重新给系统设定了新的目标C，那么系统将会获得最新目标和当前执行渐进的目标进行对比，发现目标状态存在变化，系统会马上终止掉当前执行路径和自动清理系统存在的不一致状态，开始下放最新目标状态关键路径执行通知，各个节点接受到最新命令后开始逐步像新的目标渐进，如下图所示： 

                                                                 

   当然整个过程我们并不会限定对目标状态的设置次数，多次最终目标的变化对于系统来说只是通过多轮设定目标状态和寻找当前状态到达最终目标必要关键路径执行。当然如果状态和状态之间存在关键路径的分支，那么如何选择一个当前状态到目标状态的最短最优路径就会是一个新的挑战方向，目前我们正在对这个难点进行调研，希望未来系统能沉淀出来更为智能化的决策中心，不仅仅只是获得目标状态变更的执行关键路径，更能在存在复杂分支的执行路径中寻找到最优路径进行执行。

                                                             

  通过上述文字的描述相信大家对目标渐进式的运维管控有了一定了解，基于这种设计思想下的运维管控体系很大程度上解决了之前过程式的各种弊端，其中我个人认为最为有价值的点还是在于它真正做到了沉淀能力和释放人力。为什么强调这点是因为我觉得在可以预见的未来，搜索技术体系一定会变得越来越功能强大但是同时它的复杂度也会越来越高，肯定有一天会超越人能把控的程度，所以建设一套能够代替有经验的人做出很多有效决策、并且能保障在线服务健康度和稳定性的运维管控体系就变得尤为重要。

端对端的管控设计

   关于效率提升最为核心的应该还需要三点：首先管控技术体系本身应该是服务化的，不应该上层可视化操作，下层却还是依靠脚本进行操作。其次产品化需要做到端对端更高层的抽象，需要屏蔽到后端系统间复杂的协同交互，不应该让用户做一次迭代开发上线还需要在平台中操作各种系统进行近10来次的操作修改。再次管控应该都是可视化的，虽然可视化不是什么新的概念，但也不能仅仅依靠everything变成可视化就解决了所以问题，整体可视化的设计应该有背后一套逻辑的，本文阐述下在tisplus新平台里可视化的概念应该涵盖的内容是：

• 面向最终用户的运维操作可视化操作
  
• 在线服务当前状态应该是可视化的
  
• 在线服务任何任务执行状态应该是可视化的 
  
• 在线服务产生的数据经过分析后应该被设计成可视化数据化运营场景
  

在离线的高效协同

     在复杂搜索场景里在线引擎服务是脱离不了离线输送数据而独立存在，所以为了让离线的数据处理变得更加高效，我们和离线团队共建了tisplus离线组件平台。该平台的核心能力是让用户可以在画布中通过拖拽节点的方式去定义数据之间的关系和数据处理流程。通过这种更高级别数据处理抽象很好的屏蔽了用户在复杂数据源情况下需要重复开发数据关系及处理数据流程的代码的问题，此外通过一次性的数据关系和处理流程的可视化描述，就能将搜索引擎所需要全量和增量完美统一。这意味着你只需要拖拽描述下节点，全量数据准备和实时增量更新就能完全交由平台系统搞定，业务方将彻底解决既写全量ODPS&Hive SQL任务又要去写实时增量数据处理的问题，这极大的提升了业务接入搜索服务效率。另外还有一个核心功能是我们支持各种异构数据源的自由组合，换句话说用户任何来源（ODPS、HDFS、HBASE、MYSQL、RDS、OTS、OSS）的结构化数据（非结构化数据也支持UDF进行处理）都能自由去定义他们之间的关系和处理流程（如下图所示）：

                                                                

     可见引擎源数据全量&增量处理的效率在tisplus离线组件上线后真正得到了质的飞跃，但我们绝不会只满足对引擎索引源数据的全量&增量预处理，在未来我们将支持更多的数据源组合之外，会进一步考虑复杂搜索场景下需要融合算法的需求，将离线组件平台演化成可以支持算法特征提取、特征离散&归一化、模型训练、模型效果评估的算法数据处理的平台，从而让算法同学在利用tisplus平台体验到从在线到离线的一站式端对端用户体验。

数据化运营

   平台业务规模越来越大，平台对业务本身的管理、稳定性保障和成本控制就变得越来越有挑战，所以在这个阶段我们开始从产品驱动逐步朝着数据化运营优化平台进行转变，在这期间我们落地了容量评估、一键诊断、日常巡检、测试中心、成本趋势等一系列数据化场景来帮助优化平台，主要也是为了加强整个平台的成本控制和稳定性优化方面。在未来我们希望通过更多数据化场景来引导用户能够看懂数据，理解数据价值，主动会利用数据化建议去优化自身业务。

成本可控

成本可衡量

  我们通过搜索资源调度框架（Hippo）做到了屏蔽机器概念，进而通过资源弹性调度机制使得物理机可以被多业务合理的复用的，而使用容器技术也使得每个业务就可以被容器度量的资源（cpu、memoy、disk、network）quoto单位来衡量，而为了让quoto可以被具体化成为成本我们打造了属于我们自己的资源计费系统costman,有了该系统在我们平台上任何的业务都可以被单独计费，一些资源浪费和成本优化都可以被追踪，同时也让数据化运营价值有了可以被衡量的数据化依据。

容量优化

   随着搜索业务日益增多，诸多系统都在走向平台化，平台上应用成千上万，如此多的应用依靠传统的人肉资源管理方式，成本越来越高，特别是面临诸如以下问题，极易造成资源使用率低下，机器资源的严重浪费。

• 业务方申请容器资源随意，造成资源成本浪费严重，需要基于容器成本耗费最小化明确指导业务方应该合理申请多少资源（包括cpu，内存及磁盘）或者资源管理对用户屏蔽。
  
• 业务变更不断，线上真实容量（到底能扛多少qps）大家都不得而知，当业务需要增大流量（譬如各种大促）时是否需要扩容？如果扩是扩行还是增大单个容器cpu规格？当业务需要增大数据量时是拆列合适还是扩大单个容器的内存大小合适？ 如此多的问号随便一个都会让业务方晕圈。
  

  以上归结摆在我们面前的问题就是：如何能自动化的指导应用申请合理的机器资源，提供稳定的搜索服务的同时提高资源使用率。所以在这个需求背景上我们打造了容量评估平台Torch：

                                        

该平台的主要核心执行流程是：

• 容量管控根据并发设置，将n个应用分别基于生产环境clone完整的一行，clone的目的是要保证压测出来的极限容量是生产环境真实的容量，并且让压测不影响到线上服务。
• 对clone环境进行自动化压测，自动压测到极限容量后（cpu 70%）停止。
• 将压测数据及kmon日常数据传给IDST资源成本分析算法服务，经过成本计算和优化，给出合理资源申请建议（cpu、mem、disk,行列分布等）。
• 根据算法建议更新克隆环境资源，并再次通过自动压测进行校验。
• 将经过验证后的资源建议进行持久化保存。
• 在tisplus console上进行展示及提供各种容量优化建议，方便用户一键进行容量优化。

   

     整个Torch系统通过airflow（分布式任务调度平台）平台将tisplus、kmon（实时mertic系统）、costman(成本系统)，Heracles(压测服务)将数据分析计算协同成一个数据分析计算闭环每天周而复始的自动执行给出优化建议，而不需要人工介入。而容量评估在双11期间为参入优化的12个应用容器成本累计日均节省4.6W元， 整体相当于每年容器成本节省1600W。

稳定性可控

  平台加速业务的迭代和发布效率，并不是意味舍弃稳定性环节为前提片面的追求效率，所以我们在平台建设的原则上都是保障服务稳定性的前提上提升迭代效率，所以我们依然会投入非常多的精力去打造平台稳定性能力，本章节主要给大家介绍我们在稳定性方面做得相关事情。

测试技术体系

  平台测试体系的建设是我们团队跟搜索事业部-工程效率&技术质量升龙团队一起协同打造的，其中最为核心的两个模块是：

冒烟平台

  冒烟平台的核心目标是实现业务快速回归、快速发现线上异常。平台降低了搜索线上回归测试的复杂度，提供了丰富的测试方法，如查询验证、流式case、对比测试等，业务方可在tisplus平台进行小白化case编写，轻松写case。冒烟case执行接入了Tisplus业务发布流程，实现了发布自动冒烟，保证了上线版本质量，同时也逐渐培养业务方无冒烟，不发布的质量意识。

压测平台

  搜索压测平台（heracles）支持多种服务发现方式（ip/cm2/vip/hsf/mtop），多种数据读取方式（hdfs/odps/http），是一个分布式、高性能的压测平台。压测平台依托于搜索调度系统，实现施压机自动分配、扩容，压测过程不仅支持人工调速；也支持多种自动调速模式，平台已支撑了搜索/推荐2017年双11大促压测，输出QPS峰值达350w，同时压测链路超过500个。现在tisplus平台无缝对接了压测平台，所有平台业务无需准备测试数据、测试机器、测试脚本、只要填写压测目标，即可快速完成系统性能压测，在极大提升了压测实施效率的同时也使TisPlus平台只能从大促压测演化到日常化压测变成了可能，而进一步有了日常化压测的数据的产出也为容量预估平台动态调整资源进行成本优化提供了数据基础。

优化日常化

   从产品驱动时代平台的全部精力都只关注业务如何接入，怎么快速接入，至于接入后业务方怎样用好搜索服务，是否正确使用了搜索服务平台并没有很好的关注，也就是说整个tisplus平台有很长一段时间内对于线上服务稳定性的掌控是比较弱，所以以前平台处理的方式都是搜索业务线上服务扛不住了（查询超时、Load变高、磁盘不够）并报警了，运维人员才能参与处理线上问题，遇到核心业务事后亡羊补牢式的处理，但已经不能改变背P级故障的厄运，也许故障reivew过后发现是业务方查询使用不当或者数据量、查询量的预估不合理，最终故障单并不是平台方来背，但是故障的发生并给集团造成的损失还是存在的。面对这样的问题，平台方是不可能一对一保姆跟踪所有线上搜索业务状态的，但如果把职责交给业务方，又面临着搜索技术并不像数据库技术那样即使对于普通开发而言的普惠技术，所以没有工具或者机制保障单纯依靠业务方的及时汇报其实是不可能很好地去保障搜索服务稳定性的。所以只能是平台方往前走一步，通过提供更好的机制和手段，将服务的潜在风险暴露出来，在问题最终发生前将可能发生的故障避免掉。在面对这个问题，我们很好的参考了windows系统的电脑管家的产品思路，屏蔽搜索系统的复杂性，让用户时刻知道自己搜索服务的健康程度，并通过一键恢复的方式，让搜索服务可以恢复到相对健康的状态，目前我们打造的优化大师平台Hawkeye(好可爱)系统已经逐步为很多核心搜索业务提供健康分诊断的功能，我们列举几个常见并特别行之有效的稳定性提升手段，例如

• 字段配置合理性分析：让最终用户因为不谨慎的字段类型配置导致资源成本过高的问题得到根治。
  
• 容量评估合理性分析：数据、查询变化率分析，精准知道业务规模变化趋势，准确知道当前服务集群支撑业务的余量，为达到资源瓶颈前做出扩容保障稳定打下基础。
  
• 算法feature耗时分析：精确定位到算法字段性价比分析，通过字段占用资源和访问频次，排序打分贡献值的关联分析后将成本高但是贡献度低的字段进行标注并建议用户做下线处理。
  
• 查询Query性能分析：，通过对用户查询Query的分析后，对查询慢、性能损耗过多的查询Query在搜索查询多个阶段的耗时进行精准定位，准确定位性能瓶颈，最终分析后能给予用户查询优化建议，常见的查询优化有过滤转倒排，构建联合索引，查询query改写等。
  

     通过上述类似的分析手段，并通过一种计算健康分算法，平台就能给用户的业务进行健康度进行打分，越高得分的业务，线上稳定性越高，资源利用最为合理，而得分越低的业务，线上的业务肯定是不稳定或者使用不合理的。

全链路问题诊断

      复杂的搜索业务场景不仅仅只会是一个倒排的搜索引擎，都会涉及到多个服务系统，所以面临一个系统架构、依赖链路复杂后问题不能容易快速定位的问题，所以很大程度上线上故障的排查都只能通过有经验的开发或者PE来通过多个系统的日志分析、模拟现场等方式来进行定位和修复。但是否这些问题只能通过人工介入分析后才能做到精准定位并执行后续动作呢？其实很多情况下线上问题是具有相关规律的，所以我们希望将这些人的分析能力的经验沉淀到系统中来，让程序模拟人的行为作出判断，就像我们去医院看病一样，医生诊断病因也是通过几种常见手段（验血、CT）来诊断病因，那么我们也希望有一些系统可以提供类似的诊断手段，精确的定位分布式系统下的线上问题，我们暂且称之为全链路一键诊断系统，当然此系统可行性的前提是被检测的系统本身存在可以被衡量、可以被识别和标准化的系统和业务指标数据，这个方向依然困难重重，我们依然需要努力前行。

报警理念升级

     相信很多人使用报警监控的同学都会遇到类似的问题，首先设置报警阀值基本靠拍脑袋，如果阀值设置严格，则会产生很多误报，导致报警接受人最终变得麻木，对报警失去警惕性，设置宽松则会产生漏报，最终导致故障造成业务损失。所以一般的解法只能依靠使用者多次的主观意愿、甚至说是多次惨痛经历后才能慢慢的将报警阀值设置收敛，达到一个相对正常的范围，但这种依靠多次事故后进行报警阀值收敛设置更多还是一种主观意愿和经验驱动数据变化，但是面对一个需要支持海量业务场景的平台系统而言，这种人肉报警监控体系去固定人力投入会导致人力成本变的直线上升，开发都会持续的投入到一些没有附加值的重复劳动中去。所以面对这样的问题，我们提出智能化报警平台的建设。发展到现在我们一定要有个非常明确的概念，就是数据已经不仅仅是一种信息的载体，更是一种能够提高生产力的动力源，同理我们对搜索服务系统自身产生的业务指标数据也应该发生认知上的变化：它不应该只是报警metics或者报表可视化数据输入而已，它更应该成为反哺业务持续健康发展的生产资料，它是可以通过挖据其内部的价值，建立报警数据模型从而实现通过历史业务指标数据去预估业务动态报警阀值、系统异常点检测的目标，所以我们认为的未来的监控报警应该是不再需要依靠人力投入支持，而是通过业务指标数据分析反馈后能够自动调整收敛的智能化报警系统。

未来

     目前平台主要还是提供基础技术服务输出，换句话说我们和Paas层的服务本质上其实没有多少差别，那么这种技术可以被替换的门槛依然很低，但是搜索技术真的只能做到PaaS层吗？其实未必，在复杂搜索场景里其实更多的是结合数据和算法形成具有场景领域知识的排序和推荐服务，而以这种服务能力输出才具有非替换性门槛，所以我们大胆的认为依托于业务领域并结合数据和算法能力提供搜索行业Saas解决方案才是平台的未来。

总结

     中台价值是什么？我认为中台价值就是让前面的业务走的更快更容易，让前面的创新变得更简单。基于这样的一个衡量标准，Tisplus平台发展至今已经在搜索中台这个角色上初步展露头角，整个平台在默默在背后支持了很多阿里集团核心业务，耳熟能详的有商品中心IC、聚划算、lazada、paytm、天天特价、村淘、优酷、闲鱼、评价、盒马、飞猪、菜鸟等搜索排序和检索业务，而这些核心业务的业务方开始自助的使用平台能力快速迭代业务，截止到目前为止业务方每天基于Tisplus平台进行几百次的业务和算法更新迭代，Tisplus平台让以前可能一周一次复杂业务的迭代效率提升到可以一天进行多次更新迭代，极大的释放了算法和业务的生产力。所以毫不夸张的说Tisplus平台沉淀的搜索标准化管控功能在深刻的影响着集团搜索业务、算法、搜索运维同学们日常的工作方式，同时Tisplus平台也成为了复杂分布式系统和业务迭代效率在中台战略中的最佳实践。 现在回想这一路走来还是很不容易，因为做中台特别是往上层做的人，往往具有很多产品不确定性，比如很难知道产品需要做成什么样、很难评估其价值产出，但好在团队小伙伴一起坚信中台方向价值，在人手有限的情况下并行拓展了很多核心方向并持续落地，当然也是得益于平台的力量，让我们精力更聚焦在平台发展而不是业务支持上，但中台之路注定不简单，未来需要去探索和攻克的方向和困难还有很多。另外今年我们的下半平台年处于井喷式快速发展，急需各路英雄一同聚义共谋大事。所以如果你不惧怕挑战，并具有持续不断的学习激情和能力，对搜索公有云、专有云输出、搜索性能优化，算法端对端产品化这些搜索领域最头疼的问题充满兴趣，那么我们团队绝对是你发展的最佳平台，所以请你毫不犹豫的联系我: