2015年底，阿里宣布启动阿里巴巴集团中台战略。战略定义为：构建更符合DT时代的“大中小前台”更具创新性和灵活性的组织机制和业务机制。其中，前台作为一线业务，更加敏捷，对市场的适应也更加迅速。中台将整合整个集团的数字化运营能力和产品技术能力，形成对各业务前台的有力支撑，集团是中台布局中非常重要的一环。是搜索中心化，但由于搜索技术本身的复杂性和业务规模的挑战，搜索中心在技术和产品上都遇到了巨大的挑战。 面对挑战，阿里选择走上中台一体化开发运维之路。这条路怎么走？下面就跟随阿里搜索事业部资深技术专家刘明一起来学习吧。 背??景 阿里搜索中心的初衷是支持前端业务更加敏捷，快速适应市场变化。我们的愿景是让世界摆脱难以使用的搜索。基于我们的初心和愿景，我们从0到1打造了一个搜索中心3过去三年，在DevOps、AIOps、线下平台化方面有很多行业前沿的沉淀。作为一个阿里搜索老手，有幸见证了整个阿里搜索平台的技术发展，所以这里分享一些我个人有限的经验，跟大家分享一个后台服务如何解决规模、成本、效率和质量，并转向基于平台的产品。 搜索平台的技术发展 下图是从技术角度对搜索平台发展趋势的判断，也是实践了3年多的过程。 从图中可以看出第一阶段应该是我加入阿里的时候。无论是搜索事业部还是开源搜索技术，都有人负责系统和业务运维。当时，人力资源与业务规模成正比增长。在此期间，大量的人力资源被消耗在低效、重复的工作上。这是人工控制的阶段。 之后，随着经验的积累，PE逐渐发现，一些常见的、重复的运维工作可以通过自动化脚本来实现，在一定程度上降低了人力成本，提高了运维效率，初步积累了专家经验和领域知识这是自动化脚本运维的阶段，也是大多数开源技术系统所在的阶段。但是，这样的运维方式，很自然地把开发和运维这两个角色分开了。 因为每个人的使命不同，两个角色自然就站在了对立面。开发希望快速迭代，运维希望尽可能保证线上稳定，减少迭代次数，因为大家都知道大部分线上故障其实都是配置变更和软件升级导致的。自然的分裂造成了彼此之间的不信任，于是双方有了一个完美的妥协：固定每周发布窗口在周二和周四发布，但这是以牺牲业务运营效率为前提的。 其实系统能力和业务方的迭代需求是有很大差距的。为了解决上述矛盾，基于devOps运维开发一体化理念的全新管控体系应运而生。**在第一阶段的开发运维一体化建设中，一些通过这些操作可以更好地解决发布迭代问题。 但是我们的业务场景自然是一个技术系统的管控，所以我们认为devops不应该停留在单一系统开发运维一体化的方法论认知，所以我们希望定义devops的ops是平台上单个系统“ops”的ops之一，所以本质上，我们和群里其他所谓的devOps平台有很大的不同。 集团的代表devops平台是天机平台，主要解决从服务源码到部署到升级的全流程管理，其用户本质上是运维人员。所以在此基础上，天机使用IAC（InfrastructureAsCode，基础设施即代码）+Git管理部署配置的维度来构建产品其实已经足够了。这是一个典型的devops平台设计思路，但仅仅这样的设计，其实对我们来说可能还不够，因为对我们来说，我们的用户是终端用户，不具备在线系统运维的专业知识。如果他们只看到配置或代码，他们肯定会晕倒。 所以从根本上来说，我们对DevOps的理解需要更进一步，从面向平台的产品化角度更进一步：一是屏蔽用户配置或代码或领域知识的复杂性，二是对系统协同成为一种端到端的体验管控，因为只有化繁为简，把控全链路端到端的体验，才能大幅提升复杂搜索服务的迭代效率。改善。为了实现以上两个目标，经过多年的努力，我们逐步实现了sophon、bahamut、Maat等系统，在业务迭代效率上也取得了很好的提升。 但像阿里巴巴这样规模的平台，只有DevOPS是完美的吗？显然不是，全链路DevOps只是有效解决了研发、PE、用户合作效率和用户体验等方面的问题，但对于平台端来说，随着业务规模的快速扩张和搜索服务类型的复杂多样，与平台端之间的矛盾业务和平台其实已经发生了实质性的转变：如何大规模地为每个业务提供更好的稳定性保障、合理的资源利用、更高的迭代效率成为我们平台的新目标。 目前，基于AIOPS数据运营三年的实践，我们已经实现了Hawkeye-在线服务优化平台、Torch-容量管理平台、Heracles-日常压测服务平台、CostMan-成本服务等系统其他系统。这些服务体系帮助平台在容量管理、日常巡检、一键诊断优化等方面取得了一定的阶段性成果。也让我们以后可以统一集团的搜索、运维管控。即使商家数量超过10000+，平台依然可以轻松应对，树立坚定信心。 经过3年的数据化运维实践，我们离真正的AIOps还有很远的距离，因为之前我们的性能瓶颈分析、问题诊断、故障自愈、复杂的运维决策主要由专家在在经验沉淀方面，说白了就是把人的经验沉淀到系统中去解决线上的运维问题，而AIOPS希望通过数据和算法的能力帮助我们自动发现规律性的问题并解决。从这个角度来看，AIOps在我们的平台上还有很大的潜力可以挖掘，所以我们希望未来能够真正的利用AI的能力，帮助平台在效率上更好的适应未来的发展改进、质量保证和成本优化。 台湾开发维护一体化的实践-Sophon 开发维护一体化-DevOPS 在介绍开发维护一体化体系-sophon之前，先来看一个稍微复杂的搜索场景涉及业务访问的系统以及它们如何协同工作。 从上图其实可以看出整个系统模块大致分为3大模块，OPS、Online、Offline。如图所示，Ops层明显分为在线有状态服务ops、在线无状态服务ops、离线ops。 的意思是每个服务都由一个独立的OPS来管理和控制，但其实如上图所示，一个复杂的业务是多服务系统协同的结果，所以在我的记忆中，tisplus还没有的时候online,weconnected复杂业务之前首先要做的是召集线上有状态服务团队，线上无状态服务团队，线下DUMP团队，业务方，PE开会互相沟通，然后安排如何合作推动本项目的启动。在线修改和解决问题也在后援群里互相喊话：“这一步我做完了，你再做下一步”，“你晚点再做，我得重新发”。所以你可以想象这种业务接入合作是多么低效。相信大家也能从我刚才的描述中明白为什么我们支持10个以上的业务就已经是极限了。 带着这些痛点和需求，我们回过头来说说在devops构建复杂搜索系统的实践过程中我们认为必须具备的东西：提供端到端体验的全链路OPS才是我们认为合适的我们的场景devops标准定义。在复杂的运维管控环节，基于我们常识的流程运维方式需要升级为目标驱动的运维管控。更好的运维抽象和产品抽象，更好的赋能用户。提高业务迭代效率，必须以保证业务稳定为前提。 有了这些需求和痛点，我们在这个领域也有了我们的技术平台布局——Sophon。接下来，我们将分章节详细介绍该系统。 搜索中心Devops实践-Sophon 目标驱动运维 什么是目标驱动运维？其实乍一看，会觉得太抽象了。其实听完我的讲解，你会发现很简单。下面以一个实际的搜索运维场景来说明。可能更容易理解为什么要提倡基于目标的运维管控。. 比如我们的搜索系统目前索引版本是A版本，然后要求系统切换到索引B版本，但是在滚动B版本的时候，后悔想滚动C版本。其实在早些年，线上的情况是非常令人沮丧的。如果是PE做的，只能kill掉切换进程，查看系统各个节点都走到了哪一步，清理中间状态，重新启动运维流程，可想而知，在复杂的运维体系下，程序化的运维管控方式是多么低效。 但如果是基于目标驱动的调度，我们只需要为系统重新设置新的滚动C版本，那么系统就会获取***目标并与当前的渐进目标进行比较，并且发现目标的状态发生了变化。系统会立即终止当前执行路径与自动清理系统不一致的情况，并开始分发***目标状态的关键路径执行通知。各个节点在收到***命令后，会逐渐朝着新的目标前进，所以只看最终状态的渐进和最终一致的运维模式，自然屏蔽了中间状态运维的复杂性，使得复杂的运维管控更简单、更灵活，这也是为什么我们平台所有自上而下的运维方式都升级为基于目标驱动的原因。 极简运维理念 我们平台从托管到赋能一直都在讲。言下之意，我们希望终端用户能够通过承担自己的责任，享受到更强大的搜索能力。但是在赋能方面，搜索系统复杂的领域知识和运维理念不能直接暴露给终端用户，否则这绝对不是在给用户赋能，而是在折腾用户。那么如何简化系统的运维理念，将复杂的、潜在的领域知识留给系统内部，是sophon需要解决的核心问题之一。 上图下半部分从PE角度展示了各个数据中心的基础设施和各种在线服务。会晕倒。 所以sophon做的一件事就是将运维控制对象抽象成一组数据关系模型，即运维管控模型，如上图右侧所示，但是这层运维抽象还是够复杂的，用户应该没有必要去了解这层运维抽象。我们应该给用户展示的是能够到达业务场景的业务抽象，所以sophon将业务抽象抽象到了最顶层的运维抽象之上，比如左上角的三个。层概念：业务逻辑（插件、配置）、服务（部署关系）、数据（数据源&离线数据处理）。这一层的定义几乎没有成本就可以被用户接受，所以通过sophon能够抽象运维概念，简化业务概念，也让我们的平台从托管到赋能用户成为可能。 稳定性保障 sophon对服务稳定性的保障主要体现在两个方面：当平台支持的领先核心业务越来越多时，我们需要对业务搜索服务提供SLA保障，同时适应各种业务需求根据自身的稳定性要求灵活部署离线服务，还需要具备自动容灾切换能力。目前在服务稳定性方面，Sophon可以支持搜索在线服务单元化、离线服务单元化、离线数据冷备份部署、查询链路和数据返回链路的自动容灾切换，如下图所示:前面我们提到了一个关于迭代效率提升的事情，原来基于时间窗口的在线发布迭代是可以24小时随时随地发布的，但是我们说随时随地，并不是说我们只提供发布按钮功能，不考虑快速发布过程可能带来的潜在危险，所以高效安全的发布迭代是我们的目标。这背后很重要的基础是我们设计并规范了一套发布迭代规范。比如一个正常的业务迭代，需要每天和预发布两套环境进行验证。同时，我们在预发布线的发布过程中加入了插件、算法策略升级等多种验证机制来保证发布的稳定性。同时，我们会要求克隆压测对比。如果性能差距过大，发布过程将回滚。同时在发布过程中可以定义基于单机房截流的灰度发布、烟雾验证等能力，因此有了sophon提供的强大的多重验证机制和快速的容灾切换能力，使其成为可能消除业务快速迭代中的任何后顾之忧，可以将业务运营迭代的效率提升到最高水平，如下图： 专家经验沉淀 搜索技术系统功能强大，但有很多背后的专业潜规则，所以如果平台把复杂运维控制和业务迭代需要遵循的专业知识暴露给普通用户，用户肯定会放弃，所以我们devops层必须下沉引擎的知识服务域，以便平台可以屏蔽这些复杂性。 以一个真实的搜索场景为例，如果业务方修改了一个字段，那么在现实中，一个字段的修改可能会涉及联动修改线上线下的配置。也就是说，你不能让用户在修改配置的时候，让他判断我的修改是只会影响在线服务，离线服务，还是离线服务。另外，配置推送需要在离线服务或在线服务上先生效，或者配置必须全部完成一起生效等等，这些都是引擎服务的专家知识。 目前，我们依靠sophondevOPS层在幕后默默地消费所有这些领域知识。用户根本不需要关注这些潜在的知识。运维平台会将复杂的运维操作进行分解，然后根据我们定义的专家运维DAG图，有序分阶段进行，如下图： 通过我们不断积累的运维专家经验进入系统（运维DAG执行流程图），用户对平台的使用成本会不断变小，同时迭代效率也会越来越高时间。当然如果运维操作越来越复杂（比如我们暴露给用户的业务视角需要覆盖越来越多的服务），运维DAG执行链会从简单发展到可能有多个执行分支，那么如何在运维执行中找到最优的执行环节将成为一个有趣的话题（如上图右侧所示）。目前，我们称之为最短路径选择。这是一次有趣的智能运维尝试。我们今后不断努力的方向。从系统到全链路 其实我们也介绍过，我们所有的业务场景都是一个技术系统协作的结果，而这个过程中最重要也是最具挑战的一点就是如何高效的线上线下协同提供端-到终端的用户体验。 从上图我们可以看出，终端用户在使用离线数据时，看到的总是一个可视化的数据关系定义和一个简单的dump->Build->switchindex任务执行列表。但实际上，我们屏蔽了所有的复杂性，只是系统背后有一个复杂的状态机控制着线下协同。这张图就不展开了。整个离线协同，状态机不是关键，关键是我们如何将每个在线搜索业务对离线数据处理的个性化需求转化为抽象，最终由一个平台来支撑。 在介绍线下平台技术之前，先给大家介绍下搜索业务对线下处理的一般需求，而这些需求也在线下平台支持复杂业务topic之前，在线下跨团队合作中反复讨论过.也就是说，业务数据到引擎中并不是一个简单的数据库表。它可能来自多个同构或异构数据源。同时，每个搜索业务都有全量和增量的需求，那么如何根据不同的业务，对不同数据源的关系处理成为一种高层抽象，屏蔽内部处理环节，统一数据源变得非常重要。增量和完整的处理过程。否则，我们必须为业务实现全量和增量数据处理代码。无法忍受的事情。 现在回过头来回顾一下之前我们离线支持的效率低下是因为引擎schema定义的数据源被弱化为一对资源进行抽象和管理，导致我们没有把应该做的基础抽象出来To把它提取出来，其实仔细想想，我们目前访问的所有数据资源都是DynamicTables，所以如果我们用表的抽象来定义这些资源，一些常见的比如建表、删表、修改表、添加、删除、修改、检查Table数据，定义表之间的关系等API应该是可以融合的，不会出现重复开发的问题，所以有了这样的思路，我们就有了构建离线组件平台的整体设计思路——巴哈姆特。 平台支持用户在平台画布上定义自己的数据源信息和表之间的关系（我们可以支持异构表之间的join，比如odps和mysql），我们将这个前端Graph提交给Bahamut执行翻译。Bahamut将前端Graph解析、优化、拆分、翻译成若干个Blink可执行图，如增量syncBlink、fullBulkLoadMR任务、BlinkJoin任务。 这里最重要的两个关键图节点是merge和leftjoin。Merge是将1:1和1:N关系表的处理全部通过rows转移到一张HBASE中间表，N:1关系表的处理。对于下图的例子，我们目前只支持主表N侧（CommodityTable）驱动，也就是说N侧通过blinksync更新，通过blinkJoin合并1侧（即user表）转化为完整的行记录，发送给SwiftSink（增量）&HDFSSink（全量），最后返回给BuildService构建索引，如下图： 通过线上线下管控协同以及BaHamut组件平台的打造，用户可以通过可视化的方式享受到强大的离线复杂数据关系处理和计算能力，极大的提升了业务的支撑效率，也让我们的平台成为第一个可以集成离线提供离线端到端的里程碑式产品-结束体验。另外，我们还在做一件事情，把线下的能力变成线上服务的通用能力。相信在不久的将来，离线组件平台将不再是HA3搜索场景的离线组件平台，而是整个在线搜索服务的离线组件平台。 本文是阿里搜索中台技术系列中DevOps实践的分享。后续我们将推出多篇搜索离线组件平台分享文章和搜索AIOps实践，敬请期待。 搜索平台从0到1的搭建已经3年了，但距离我们心目中让世界好用的宏伟愿景还很遥远。未来的道路必将充满挑战，无论是业务层面的SaaS能力、搜索算法的产品化、云DevOps&AIOps，还是企业建站，都将遇到前所未有的困难。
