大规模异构数据的线索列表进化之路

见贤思齐

导读：「以客户为中心，技术为产品服务」是爱番番线索管家团队一贯遵循的原则。技术架构规划首先应该围绕业务诉求展开，用合理的技术赋能产品，产品在不断的演进中又对技术提出更高的标准和要求。作为爱番番PV最高的页面，本文将详细介绍线索列表如何从快速交付的刀耕火种原始状态，逐步走向“高可用、高质量、高体验“的成熟期。全文9355字，预计阅读时间24分钟。在后台系统中，列表是最常见的数据展示方式之一，它就像系统的水电煤一样平常，以至于你可能会问列表开发能有什么技术挑战呢？一、列表应该提供什么能力？列表页有三个基本模块：搜索搜索框（定向查找某条数据）筛选项（预置搜索条件快速找到符合条件的结果）数据呈现表头数据分页器操作项操作按钮（对整行数据），比如线索列表的分配、打电话修改数据（对某个字段），比如添加标签列表承载着业务上的数据，列表的设计体验关乎用户对业务数据的处理和管理效率，最终的目标是为了能提高客户使用数据及决策的效率。二、技术落地演进随着爱番番产品的快速迭代与演进，线索列表也从快速交付的刀耕火种原始状态，逐步走向“高可用、高质量、高体验”的成熟期。下面将逐一介绍线索列表经历过的不同版本，踩过的坑以及相应的解决方案。V1 - 快速落地基础能力爱番番项目初期，为保证项目快速落地，帮助用户及时快速查询和跟进线索，线索信息存放到MySQL，提供基础的CRUD能力。V2 - 配置扩展能力随着业务不断演进，基础的表单及列表功能与用户可配置、可扩展需求之间的矛盾愈发突出，如何支持自定义能力，是线索列表面临的一大难题。爱番番线索管家团队主要从「元数据驱动」，「指标解析器」，「前端渲染引擎」三方面着手解决。2.1 元数据驱动?伴随线索产品不断迭代，线索预置字段数量不断增加。并且线索升级能力支持自定义字段，原来页面固定的检索项已不能满足用户对所有线索字段进行检索的需求，所以我们提出了通过自定义检索项元数据动态完成检索项的渲染，以满足用户的个人偏好。1、UI渲染信息完成检索项在页面动态渲染2、检索条件构建器，动态构建检索项指标数据3、检索项操作符支持不同指标的检索范围4、检索项关系符可以动态组装检索条件的查询场景5、当有新的筛选指标需要添加时，只需要添加检索项元数据和实现检索项的构建器2.2 指标解析器随着线索字段的不断增加， 在列表中需要实现表头的灵活配置，和列表项的快速加载， 提炼了自定义列表指标项元数据。1、?自定义列表在列表检索的这个服务中，通过接入通用自定义指标服务来完成用户自定义列表项的灵活配置。2、?指标检索配置化通过引入检索指标的概念，可以将列表字段的查询抽象为对指标的查询。这样的话不同的查询场景即可建模为对不同指标数据的查询，指标数据之间可以任意组合以满足需求。此时底层只需要提供一个通用的指标检索服务即可。3、?后置处理器对于不同的场景，列表字段需要不同的展现形式；通过引入后置处理器，可以通过配置化的方式定制渲染逻辑。新指标只需在配置对应的指标元数据即可。2.3 前端配置化引擎设计最初线索列表和筛选项仅支持较少字段展示和筛查，因此我们只需要对特定字段进行特殊处理UI组件进行渲染即可。但随着业务复杂度增加、字段增多以及自定义字段的加入，单纯针对特定字段进行特殊处理进行渲染带来了巨大维护成本（增加字段需要为此字段单独开发UI组件，需不断调整相关业务代码）和测试回归成本，且无法满足自定义字段的筛选及展示。于是引入配置化引擎设计，以组件为基本单位，通过组件参数配置完成页面相关内容渲染。1. 每个组件均是由元数据驱动的标准化组件，分为组件和配置两部分；2. 将后端返回的组件配置信息和本地默认配置merge后生成最终配置；3. 组件配置引擎通过解析组件配置，动态化的绑定事件、传递数据、渲染组件；引入配置化引擎设计后，前端只有在新增组件类型时才需要投入开发人力，对于其他同质化需求仅需后端修改配置即可生效，极大降低了开发和测试回归成本。V3 - 升级体验3.1 背景线索列表是线索管家的核心业务场景，随着业务的不断发展，急需对线索列表的体验进行升级。3.2 设计目标秉持信息易懂、体验易用的设计价值观，通过对列表信息进行重组和体验升级，从而提升线索列表客户满意度。3.3 设计打法3.3.1 页面拆解线索列表页由、工具栏、表格三大模块构成；区：包括、规则说明等信息，概括整个页面的信息；工具栏区：包括数据过滤（筛选、搜索）、功能操作（新建、导入...)，承载页面的增、删、改、查等操作；表格区：包括表头、表体、分页，展现页面的核心信息。3.3.2 核心痛点区：规则不明确，理解成本高；工具栏区：数据过滤及功能操作密度大，干扰信息繁杂；表格区：核心信息展示屏效比低，操作成本高。3.3.3 设计策略1. 区升级【区】规则说明由图标优化为图标+文字形式，直观易懂；2. 工具栏区升级【功能操作】外露重要高频操作，折叠低频操作，降低对用户的干扰；【数据过滤】外露高频筛选，折叠低频筛选，提升核心表格区屏效占比；3. 表格区升级【表头】页面上滑，表头吸顶展示，易于定位字段信息，拓展线索列表纵向空间；【表体】页面横滑，横向滚动条悬浮于屏幕底部，提升横向操作效率；【表体】操作列采用主次形式，外露高频功能，折叠低频功能，有效提升操作效率和功能扩展空间。▲线索列表升级前后对比图3.4 设计收益通过构成、交互、反馈、适配四个维度将页面信息进行深挖与重组，核心表格区屏占比达到70%，数据展示更合理，提升线索列表页面易用性与客户满意度。V4 - 升级检索能力4.1 现状和挑战目前系统线索预置字段58个，动态扩展25个以及亿级线索数据。业务不断升级所有线索字段纳入自定义检索（多条件检索，分词检索等）和日益膨胀的数据让检索的性能面临挑战， 我们使用ES替代MySQL来实现高性能的高级检索功能。4.2 方案设计名词解释-WATT：百度数据流开放平台-瓦特（WATT）, 是数据流自助开发和运维平台。数据流捕获mysql数据库中变化数据实时发布出来， 以增量和基准两种方式进行发布， 提供文本格式数据，保证实时性、数据的有序和不丢，还可以对订阅数据进行计算。方案：检索由DB迁移到百度云ES服务，用户操作完线索后数据更新到DB， 再通过WATT、MQ和写入服务将数据同步到ES。收益：提高查询效率， 支持全文分词场景，数据进行相关度排序等，支持任意检索条件组合查询不影响查询性能。V5 - 支持写后读(Read your writes)5.1 现状和挑战线索列表检索由MySql迁移到ES后，又带来了新的问题，DB在同步ES的过程中，容易受依赖环境影响导致数据更新有延迟，导致用户在线索列表看到的不是最新数据，对用户体验有一定的影响， 从而对线索列表的稳定性和准确性带来了新的挑战。数据流现状如下：??上述中DB同步ES共需要5步，任何一步出现延迟都会造成线索列表数据更新不及时。5.2 优化目标即使DB到ES数据同步存在延时，也能保证线索列表中的数据与用户操作后的结果一致。5.3 方案设计1、用户对线索进行操作(新建，分配， 编辑等)后， 将操作后的线索ID写入到redis有序队列中，由于DB同步到ES延迟时间大概在0～2s间，因此redis队列自动过期策略设置为10s。2、redis队列只写入线索ID，而不是存储完整的线索数据快照:?a、线索属性多、结构复、迭代变化快，只记录线索ID比较轻量级，线索本身变更不影响redis中缓存的数据结构；b、查询时根据ID从DB中查询，数据更准确，因为没有事务去保证redis与DB中的数据强一致性。3、用户查询线索列表数据a、获取redis有序队列中最近5s的线索IDb、组装ES筛选条件查询ES数据，获取redis线索ID筛选DB数据， 为了保证列表的查询性能，采用并发查询c、通过表达式引擎，根据ES筛选条件过滤DB线索数据，获取有效的查询结果d、通过merge策略完成ES数据和DB数据mergemerge 策略为了能够简单阐述merge的各个场景，我们先定义一下几个对象1、leads_es：线索对应的ES结果视图2、leads_db：线索对应的数据库视图3、result_es = {....} ：ES查询结果的结果集4、result_redis_db = {....}：通过redis获取线索ID查询DB的结果集5、result_redis_db_filter = {...}：result_redis_db根据筛选条件通过表达式引擎过滤后的结果集6、candidate = {....}：最终融合到的结果集我们称之为候选结果集candidate 选择策略1、有新增或修改操作后的线索且满足过滤条件的，应该把DB中查询到的线索加入候选集2、没有操作过的线索且满足过滤条件的，应该把ES中查询到的线索加入候选集3、操作过的线索且不满足过滤条件的，不应该加入候选集效果收益：上线后无用户在反馈操作线索后列表数据延迟类问题，线索打标签后首次查得率、编辑线索后首次查得率均为100%。V6 - 性能优化?6.1 如何度量性能If you can't measure it, you can't improve it!页面性能度量是优化的前提，而前端性能监控也是一个经久不衰的话题。监控方向、监控指标、埋点方案、上报工具都是需要考虑的点，业界商用打点平台及厂内埋点平台，均无法解决易用、实时、前后端全链路监控等问题。为此爱番番启动「大前端APM」专项，参考服务端RED指标及业界主流前端埋点方案，探索最适合爱番番的前端APM体系架构。6.1.1 监控目标从全局问题出发，能够洞察统计性的页面url真实性能指标，以及可以做操作流任意阶段之间的统计性耗时分析。从个案问题出发，能够基于用户id进行任意一次全端调用链追踪。6.1.2 解决方案采集埋点SDK：爱番番业务打点使用付费系统「神策」，为避免重复造轮子，前端APM SDK基于神策SDK进行二次封装，通过npm包形式进行版本管理；使用方在公共模块对埋点SDK进行初始化。增加无侵入性能采集能力，提供采样率等配置扩展能力。上报综合image、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('?')