研发效能提升:vivo AI 搜索平台化建设( 三 )


搜索流程可视化 。 以流程图的形式展示完整的业务搜索流程 , 业务人员可以通过流程图快速熟悉业务流程 , 了解每个功能的上下环节 , 更好的把控整体业务流程 。
组件能力实现
通过对业务逻辑进行抽象 , 我们发现搜索流程和具体步骤都不会涉及到具体的代码逻辑 , 只是对整体搜索过程进行串联和约束 , 为此我们开发了搜索平台流程编排功能 , 并对基础功能进行抽象和封装 , 形成一个个通用的系统服务组件给不同业务使用 , 而业务中特有的业务逻辑可以定制开发 , 这样可以将整个业务逻辑中变与不变的部分区分开来 。
研发效能提升:vivo AI 搜索平台化建设
文章图片
平台化后架构图
我们对不同业务的公共能力进行抽象 , 并封装成公共组件由搜索平台进行管理 。 在业务对接搜索平台后 , 业务人员就不再需要关注基础能力的具体实现 , 而是可以直接在搜索平台中进行配置 , 从而专注于业务功能的迭代;与此同时 , 业务人员还可以根据实际需要不断扩充搜索平台的组件类别 , 提升组件能力 , 并提供给其他业务使用 。 业务和平台之间相辅相成 , 业务促进平台能力的提升 , 平台也能进一步赋能业务的发展 。
针对于不同业务场景中存在的相同逻辑功能 , 我们参考了低代码平台的实现思路 , 将通用功能封装成公共组件 , 开发人员通过页面拖拽配置组件实现通用的功能 , 少量代码即可完成业务功能扩展 , 从而实现便捷构建搜索流程 。 使用者可以通过页面可视化配置的方式对整个搜索流程进行组装 , 从而满足不同的业务需求 。
通过对已有业务能力以及一般搜索业务流程逻辑进行梳理 , 我们总结了3大类8个小类的公共组件模块 , 具体如下:
研发效能提升:vivo AI 搜索平台化建设
文章图片
公共组件模块
以上组件基本涵盖了搜索全流程的各个环节 , 业务开发人员在日常迭代过程中可以直接使用组件库中提供的组件模块进行可视化开发 , 如果不能满足需求 , 可以自行进行扩展 。 同时我们也定义了一套标准规范 , 所有内置的公共组件都按照这套规范进行开发 , 业务人员也可以按照这套规划开发自己的组件并共享到组件库中 , 而组件又是可以插拔的 , 业务之间都可以方便的拿来复用 。
搜索链路监控
搜索服务涉及的垂类业务多 , 调用链路长 , 不仅包括团队自身维护的业务垂类 , 还包括算法团队、图谱团队等 , 当线上业务出现问题或者搜索结果出现badcase时 , 往往只能通过日志信息进行排查 。 这样不仅需要有详细完整的日志信息 , 而且要求开发人员能够熟悉整个业务流程才能快速对问题进行定位 。 在调用链路还比较短、业务功能还比较单一的时候 , 这种方式还是能够比较有效的帮助我们对问题进行定位和排查 。 但是随着业务的快速发展以及用户数量的快速增长 , 日志信息的规模也呈现指数级别的增长 , 这样会给日志采集系统带来极大的压力 。 此外 , 日志信息往往不能直观的展示服务中的具体问题 , 往往需要对应功能模块的开发同学进一步进行判断和定位 , 从而极大提高了问题的解决成本 。 因此 , 我们团队对业界已有的服务全链路监控工具进行调研 , 最后选择SkyWalking作为搜索服务的链路监控工具 。
SkyWalking是一款优秀的APM工具 , 提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案 。 在实际使用过程中 , 由于搜索服务每天的请求量较大 , 我们并不是直接使用SkyWalking对每个请求的完整调用链路数据进行监控 , 这样每天会产生几十TB的监控数据 , 而且绝大部分都是无用的 , 而是对某个调试请求接口进行监控 。 当线上环境出现搜索结果异常或者其他问题时 , 可以直接通过请求该接口进行问题复现 , 然后通过SkyWalking对整个调用链路的请求和访问数据进行收集监控 , 并通过SkyWalking的可视化界面对问题快速定位 。