百度爱番番线索列表如何从快速交付的刀耕火种原始状态

简介:“以客户为中心,以技术为核心的产品服务”是百度爱范范领导管理团队一贯遵循的原则。技术架构规划首先要围绕业务需求,以合理的技术赋能产品,在产品的不断演进中对技术提出更高的标准和要求。作为爱凡凡PV最高的页面,本文将详细介绍线索列表是如何从刀耕火种、快速交付的原始状态走向“高可用、高品质、高体验”的成熟阶段。 ”。

全文9355字,预计阅读时间24分钟。

在后端系统中,列表是最常见的数据呈现方式之一。它与系统的实用程序一样普遍,以至于您可能会问列表开发会遇到哪些技术挑战?

一、该列表应提供哪些功能?

列表页有三个基本模块: 搜索框(直接查找某条数据) 过滤项(预设搜索条件,快速找到符合条件的结果) 数据呈现表头 数据分页器 操作项 操作按钮(用于整行数据)),比如分配线索列表,调用修改数据(到一个字段),比如添加标签

列表承载业务数据。列表的设计体验关系到用户处理和管理业务数据的效率。最终目标是提高客户使用数据和决策的效率。

二、技术演进

随着爱凡凡产品的快速迭代和演进,线索列表也逐渐从最初的刀耕火种快速交付状态走向“高可用、高品质、高体验”的成熟阶段。下面将介绍线索列表的不同版本,踩过的坑,以及对应的解决方法。

V1 – 快速实现基础能力在爱凡凡项目初期,为了保证项目的快速落地,帮助用户快速查询和及时跟进线索,线索信息存储在MySQL中提供基本的 CRUD 功能。

V2——配置扩展能力随着业务的不断演进,基本的表单和列表功能与用户可配置和可扩展的需求之间的矛盾越来越突出。如何支持定制化能力是铅榜面临的一大难题。 爱凡凡的线索管家团队主要从“元数据驱动”、“索引解析器”、“前端渲染引擎”三个方面来解决。

2.1 元数据驱动线索产品不断迭代,线索预设字段数量不断增加。此外,线索升级能力支持自定义字段。原页面的固定搜索项已经不能满足用户搜索所有线索字段的需求。因此,我们提出通过自定义搜索项元数据来动态完成搜索项的渲染,以满足用户的需求。个人喜好。

1、UI渲染信息完成,页面动态渲染检索项2、检索条件构建器动态构造检索项索引数据3、检索项算子支持不同指标的检索范围4、检索项关系可以动态组装检索条件的查询场景5、当需要增加新的过滤指标时,只需要检索项的元数据和实现检索的builder item 需要添加2. 2 指标解析器需要实现headers的灵活配置和随着线索字段数量的增加列表项的快速加载,并细化自定义列表指标项的元数据。

1、自定义列表 在这个列表检索服务中,通过访问通用的自定义指标服务来完成用户自定义列表项的灵活配置。 2、指标检索配置通过引入检索指标的概念,可以将列表字段的查询抽象为指标的查询。这样就可以将不同的查询场景建模为对不同索引数据的查询,索引数据可以任意组合以满足需要。这时底层只需要提供一个通用的索引检索服务。 3、后处理器针对不同的场景,列表字段需要不同的呈现形式;通过引入后处理器,可以以可配置的方式自定义渲染逻辑。新建指标只需要配置相应的指标元数据即可。

2.3 前端配置引擎设计 初始的线索列表和过滤项只支持较少字段的显示和筛选,所以我们只需要对特定字段进行特殊处理的渲染UI组件即可。但是随着业务复杂度的增加,字段的增加,自定义字段的增加,对特定字段进行特殊处理带来了巨大的维护成本(增加字段需要为该字段开发单独的UI组件,以及相关的业务代码)需要不断调整。)和测试回归成本,不能满足自定义字段的筛选和展示。因此引入了配置引擎设计,以组件为基本单元,通过组件参数配置完成页面相关内容渲染。

1.每个组件都是由元数据驱动的标准化组件,分为组件和配置两部分;

2. 将后端返回的组件配置信息与本地默认配置合并,生成最终配置;

3. 组件配置引擎通过解析组件配置动态绑定事件、传输数据、渲染组件;引入配置引擎设计后,前端在添加组件类型时只需要投入开发人力即可。对于其他同质化需求,只需要修改后端配置即可生效,大大降低了开发和测试回归的成本。

V3-升级体验3.1 后台Lead list是Lead Manager的核心业务场景。随着业务的不断发展,铅榜体验升级迫在眉睫。

3.2 设计目标坚持信息通俗易懂、体验简单易用的设计价值观。通过重新整理列表信息,升级体验,可以提高潜在客户列表的客户满意度。 3.3 设计思路3.3.1 拆解线索列表页面的页面由标题、工具栏和表格三个模块组成;标题区:包括标题、规则描述等信息,概括整个Page信息;工具栏区域:包括数据过滤(过滤、搜索)、功能操作(新建、导入…),承载添加、删除、修改、查看页面等操作;表格区:包括表头和正文,分页,展示页面的核心信息。 3.3.2 核心痛点标题区:规则不清晰,理解成本高;工具栏区域:数据过滤和功能操作密度高,干扰信息复杂;表区:核心信息显示屏效比低,运营成本高。 3.3.3 设计策略1.标题区域升级2.工具栏区域升级3.表格区域升级

3.4 设计优势通过构图、交互、反馈、适配四个维度深度挖掘和重组页面信息。核心表区屏占比达到70%,数据展示更合理,线索列表提升页面易用性和客户满意度。

V4 – 检索能力升级4.1 现状与挑战 目前系统预设58个线索字段,125个动态扩展字段,十亿级线索数据。业务不断将所有线索字段升级为自定义搜索(多条件搜索、分词搜索等),不断扩大的数据使得搜索性能具有挑战性。我们使用 ES 代替 MySQL 来实现高性能的高级搜索功能。

4.2 方案设计

词汇表-WATT:百度数据流开放平台-WATT(WATT),是一个数据流的自助式开发和运维平台。数据流捕获mysql数据库中变化的数据并实时发布。它以两种方式发布:增量和基准。提供文本格式数据,保证数据实时、有序、不丢失,还可计算订阅数据。

方案:检索从DB迁移到百度云ES服务。用户操作线索后,数据更新到DB,再通过WATT、MQ、写服务同步到ES。好处:提高查询效率,支持全文分词场景,数据按相关度排序等,支持任意组合搜索条件,不影响查询性能。

V5 – 支持阅读您的文章5.1 状态和挑战

线程列表检索从MySql迁移到ES后,带来了新的问题。在同步ES的过程中,DB容易受到依赖环境的影响,导致数据更新延迟,导致用户在线程列表中看到的不是最新的。数据对用户体验有一定的影响,给排行榜的稳定性和准确性带来了新的挑战。

目前数据流状态如下:

上述DB同步ES一共需要5个步骤。任何步骤的任何延迟都会导致线程列表数据无法及时更新。

5.2 优化目标即使DB和ES之间的数据同步存在延迟,也可以保证线程列表中的数据与用户操作的结果一致。

5.3 方案设计

1、用户对线程进行操作(创建、分配、编辑等)后,将操作后的线程ID写入redis有序队列。由于DB同步到ES延迟时间大概是0~2s的时间,所以redis队列自动过期策略设置为10s。

2、redis队列只写入线程ID,而不存储线程数据的完整快照:线程属性多,结构复杂,迭代变化快。只记录线程ID,相对轻量级,线程本身发生变化。不影响redis中缓存的数据结构;

b.查询时根据ID从DB中查询数据,数据更准确,因为没有事务保证redis和DB中数据的强一致性。

3、用户查询线程列表数据a,获取redis有序队列最后5s的线程IDb,组装ES过滤条件查询ES数据,获取redis线程ID过滤DB数据。为了保证列表的查询性能,采用并发查询 c.通过表达式引擎,根据 ES 过滤条件过滤 DB 线索数据,得到有效的查询结果 d.通过合并策略完成ES数据和DB数据的合并

合并策略为了简单描述合并的各种场景,我们先定义几个对象1、leads_es:leads对应的ES结果视图

2、leads_db:leads对应的数据库视图

3、result_es = {….} : ES 查询结果的结果集

4、result_redis_db = {….}:通过redis获取线程ID查询DB的结果集

5、result_redis_db_filter = {…}:result_redis_db是表达式引擎根据过滤条件过滤的结果集

6、candidate = {….}:我们称之为候选结果集的最终结果集

候选选择策略1、如果有新的或修改的线索且满足过滤条件,则将DB中查询到的线索加入候选集2、未操作的线索并且满足过滤条件,ES中查询到的线索应该加入候选集3、被操纵的不满足过滤条件的线索不应该加入候选集

有效福利:上线后,没有用户反馈操作线索后列表数据延迟。线索标记后的首次搜索率和编辑线索后的首次搜索率均为100%。

V6 – 性能优化6.1 如何衡量性能如果你不能衡量它,你就不能改进它!

页面性能测量是优化的前提,前端性能监控也是一个经久不衰的话题。监控方向、监控指标、埋点解决方案、报告工具都是需要考虑的点。行业的商业管理平台和厂内埋地平台都无法解决易用性、实时性、前后端全链路监控等问题。为此,爱范范推出“大前端APM”项目,参考服务器端RED指标和业界主流的前端嵌入方案,探索最适合爱范范的前端APM架构。

6.1.1 监控目标从全局问题出发,可以洞察页面URL的统计真实性能指标,可以在任意阶段之间做统计耗时分析操作流程。从个案问题出发,可以根据用户id进行任何全端调用链跟踪。

6.1.2 个解决方案

积分埋点SDK:爱范范商管使用支付系统“神策”。为了避免重复造轮子,前端APM SDK在Godce SDK的基础上重新打包,以npm包的形式进行版本管理;用户在公共模块初始化嵌入式SDK。增加非侵入式性能获取能力,提供采样率等配置扩展能力。

报告

全面的图像、sendBeacon 和 Ajax 报告解决方案。首先,拼接完整的带有参数的url,判断url的长度。如果url长度小于浏览器允许的最大长度,则通过动态创建img标签发送前端性能数据;如果url过长,则判断浏览器。是否支持sendBeacon方法,如果支持,通过sendBeacon方法发送请求,否则发送同步ajax请求。示例代码如下:

function dealWithUrl(url,appId){
    let times = performanceInfo(appId);
    let items = decoupling(times);
    let urlLength = (url + (url.indexOf('?') < 0 ? '?' : '&') + items.join('&')).length;
    if(urlLength < 2083){    imgReport(url,times); }
        else if(navigator.sendBeacon){    
                sendBeacon(url,times);  
        }else{ajaxReport(url,times);
    }
};

前后端走线相连

6.2 性能问题&目标问题:前端APM将于2021年Q2全面落地,让爱范范前端性能监控向前迈出一大步。但同时也暴露出页面性能差、数据量大的用户感知时间长等诸多问题。其中,线索列表的性能问题尤为突出,页面初始化用户感知时长超过5000ms(P90);目的:通过对爱范范所有页面的性能进行统计分析,整体前端-end 性能指标为“页面初始化用户感知时长低。2000ms(P90)”),拆解目标如下:

6.3 优化思路&整体优化思路和方案节奏:首先聚焦主要矛盾,摘低挂果;然后关注细节,解决难点。每一个方向都做到极致,每一个都被打破。

6.3.1 耗时链接分析术语:BFE,百度前端,百度统一前端,是百度统一的七层(HTTP/HTTPS)流量接入平台;百度提供流量接入服务。

用户可以感知耗时环节:从CDN节点加载静态资源(静态资源耗时)、执行js文件、发送Ajax请求(界面启动总耗时)、浏览器发送Http请求、以及到达BFE网络耗时 BFE 链路转发到Access Gateway耗时,Access Gateway转发到BFF服务链路耗时,BFF自身服务耗时(包括服务内部请求、组装微服务等) ) 网关返回响应,到达 BFE 链路需要时间。 BFE 将响应返回给浏览器网络耗时浏览器渲染时间

问题:

优化前的BFF调用链:

方案:优化后的BFF调用链:

好处:BFF调用微服务链接所需时间减少100ms+,消除了BFE VIP连接频繁超时的问题。

6.3.2 接口性能优化 通过分析接口实现逻辑和SkyWalking调用链,发现以下三类问题: 第一类问题:代码实现问题。低垂的水果更容易采摘。问题:方案:

第二类问题:性能调优。这部分需要了解ES和RPC框架的底层实现原理。问题:方案:

第三类问题:超时问题。这部分优化场景复杂且困难。超时问题有几种: 问题: 解决方法:1. 重构Mesh SDK进行连接复用,调整服务本身的IO线程数,解决QPS高时的连接等待问题; 2.DB集群稳定性治理3.超时问题治理

收入:潜在客户列表服务器耗时(P90)从 2500ms+ 到小于 800ms。

6.3.3 前端性能优化前端性能问题主要集中在渲染延迟和静态资源加载耗时。

第一方面:列表渲染优化背景:爱范范前端整体采用vue技术栈。 elementUI作为vue生态中最受欢迎的UI框架,以其强大的功能、健全的生态和活跃的社区而入选。做爱范范前端UI框架。线索列表使用element-ui中的el-table组件,可以支持列表场景中的常见需求。

问题:1.在数据量很大(100行,50列)的情况下,JS Long Task耗时近3000ms,线索列表的渲染卡顿。 2.数据整体渲染时间长,用户等待(加载)时间长。 3.el-table不支持顶吸和底吸操作,简单修改CSS样式无法实现,体验不好。

分析:看了el-table源码,发现el-table的实现是通过四个HTML原生表格(列表左右的header、body、checked列)来实现的。数据量大时,DOM的数量会变得非常大;尤其是header被拖拽,页面重绘回流时,计算量巨大,Long Task长,导致页面卡顿。研究基于动态渲染思想的开源组件pl-table。不支持吊顶功能,行高不固定时支持不好,排除在外。

方案:1.通过调查业界主流UI框架,只有React系统中的AntD表支持吸顶功能,但其vue版本存在滞后,不支持此提醒。经过群里讨论,决定参考React AntD表的实现思路,重新实现AFF-UI表。 2.列表数据的渐进式渲染。首先渲染首屏数据,结束加载,将首屏列表呈现给用户。同时在用户感知不到的情况下渲染其他列表数据。

优点:1.与el-table相比,AFF UI table在相同数据量下减少了60%的DOM数量,在100行60列数据下渲染性能提升了300%; 2. 支持列表从上到下的功能,体验大大提升; 3.渐进式渲染,首屏可感知渲染时间(P90)从2000ms减少到500ms以内。

第二个方面:静态资源优化背景:爱范范前端采用自研的Tangram微前端架构,分为主模块“common”和其他业务领域子模块。支持每个敏捷团队页面代码库,独立部署运维。前端静态资源部署在百度云BOS上,域名静态资源通过BFE转发定位。

问题:

分析:静态资源优化思路,从链接、缓存、编译三个方面入手。链接和缓存是前端优化的常用方法,解决方法也大同小异。编译的问题一般都隐藏的很深,需要对webpack的编译打包原理有一定的了解。下面重点介绍编译相关的分析流程:1、首先通过监控平台分析js加载瀑布,定位到chunk-vender.js耗时情况,是性能瓶颈。

2、通过webpack分析器分析编译:

发现以下问题:

方案:链接:静态资源直接请求BOS域名,不使用aifanfan.baidu域名,减少一层BFE转发链接,开启百度云BOS CDN加速,开启gzip压缩静态资源, cache:在首页预加载线索列表静态资源预加载HTML中线索列表相关的JS,使用webpack require特性,全局缓存列表的相关JS(本方案是方案一的高级版,预加载是更高级更彻底)编译:修改微前端框架tangram-sdk编译配置,排除biz-crm-fe-commom包拆分前端代码库。将列表和详情以外的非核心页面迁移到新代码库,保证列表js体积最小化,异步加载大体积依赖js,让初始加载js体积压缩到极致:静态资源耗时(P90)从2000+ms,静态资源gizp总体积优化到500ms以内:693.52KB → 228.83KB,总体积减少67%

附上编译优化前后js体积对比(浮绿为优化后)

6.3.4 体验优化问题:列表全屏加载,白屏时间长;全列表过滤条件,实时加载,客户感知时间长,抖动;标头数据的默认值 您可以选择全部(50 列以上),请求和呈现大量数据。用户使用时需要横向滑动3-5屏,体验不好。解决方案:使用侧拉面板交互进行列表过滤,本地记忆和显示上次过滤条件;优化加载区域和方法,以最小化用户从视觉感知的感知时间;为所有自定义表头设置数据分析,参考行业通用设置,增加表头最大数量。好处:性能优化和体验提升同上。在瑞银调查中,爱范范领管家的整体经验和业绩在行业中处于领先地位。

6.4 收益

经过以上优化措施,线索列表整体表现达标。

回顾近一年的性能优化历程,我经历了以下几个阶段:

“没有办法启动”用户反馈列表有性能问题。我试图解决它,但我无法衡量它,我在黑暗中摸索。 (2020Q4 – 21Q1)“利刃不乱砍柴”调研前端性能监控方案,发起爱范范前端APM话题。(21Q1)“针对性”APM建设,web端全面落地。全面了解领跑名单的表现,优化工作逐渐清晰明了。(21年Q2)》先摘下容易摘到的果子” 用常规手段解决前后端常见的性能问题。和优化。(21年Q3)“攻坚难点,毫秒必争”不会放过任何一个优化点,并且成立了专门小组针对前后端的疑难问题,集思广益,聚焦关键问题,没有结果不放弃。(21年Q4)三、总结“以客户为中心” ,以技术为基础的产品服务”是爱攀范领管家团队一直秉持的原则一直跟着。合理的技术为产品赋能,产品在不断演进中对技术提出更高的标准和要求。线索列表是爱范范的核心功能之一。商业是发展技术的前提。同时,业务复杂度的升级反哺技术架构的演进。业务与技术相辅相成,相互促进,最终为用户创造价值。

产品和技术的演进只有开始,没有结束。展望未来,铅榜能力的泛化,配置扩展能力向PaaS平台的演进,以及LowCode和NoCode的不断探索和实践,我们还有很长的路要走。 四、作者介绍,本文由爱凡凡线索管家团队多位同学合着。

© 版权声明
THE END
喜欢就支持一下吧
点赞256 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片