大规模异构数据的线索列表进化之路
导读：「以客户为中心，技术为产品服务」是爱番番线索管家团队一贯遵循的原则。技术架构规划首先应该围绕业务诉求展开，用合理的技术赋能产品，产品在不断的演进中又对技术提出更高的标准和要求。作为爱番番 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 个，动态扩展字段 125 个以及亿级线索数据。业务不断升级所有线索字段纳入自定义检索（多条件检索，分词检索等）和日益膨胀的数据让检索的性能面临挑战， 我们使用 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 的线索 ID
b、组装 ES 筛选条件查询 ES 数据，获取 redis 线索 ID 筛选 DB 数据， 为了保证列表的查询性能，采用并发查询
c、通过表达式引擎，根据 ES 筛选条件过滤 DB 线索数据，获取有效的查询结果
d、通过 merge 策略完成 ES 数据和 DB 数据 merge
merge 策略
为了能够简单阐述 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 请求。示例代码如下：
前后端 Trace 打通
6.2 性能问题 &目标
问题：前端 APM 在 2021 年 Q2 全面落地，使得爱番番前端性能监控迈出一大步。但同时暴露出不少页面性能较差、大数据量用户可感知时长较长等问题。其中线索列表性能问题尤为突出，页面初始化用户可感知时长超过 5000ms（P90）；
目标：通过对爱番番所有页面性能统计分析，前端整体性能指标为「页面初始化用户可感知时长低于 2000ms（P90）」，分段拆解目标如下：
6.3 优化思路 &方案
整体优化思路及节奏：先抓主要矛盾，摘低垂果实；再抠细节，进行难点攻坚。每个方向均做到极致，各个击破。
【链路】厘清页面完整链路及耗时，全面了解页面性能现状。
【后端】深入分析后端代码实现逻辑，从并发、缓存、es 调优、线程池调优，依赖超时分析等方面着手优化接口性能。
【前端】分析前端代码、编译配置、浏览器 Performance 火焰图，从静态资源体积、JS Runtime Long Task、渲染性能等方面入手优化前端性能。
【交互】与产品、设计共同探讨交互升级方案，以达到极致用户体验。
6.3.1 耗时链路分析
名词解释：BFE，Baidu Front End，百度统一前端，是百度统一的七层(HTTP/HTTPS)流量接入平台；为整个百度提供流量接入服务。
用户可感知耗时链路：
从 CDN 节点加载静态资源（静态资源耗时）
执行 js 文件，发送 Ajax 请求（接口总耗时开始）
浏览器发出 Http 请求，抵达 BFE 的网络耗时
BFE 转发至 Access Gateway 链路耗时
Access Gateway 转发至 BFF 服务链路耗时
BFF 自身服务耗时（包含服务内部请求、拼装微服务等），由 Skywalking 统计
BFF 返回 response，至 Access Gateway 链路耗时
Access Gateway 返回 response，至 BFE 链路耗时
BFE 返回 response 到浏览器网络耗时
浏览器渲染耗时
问题：
BFF Node.js 服务调用后端微服务链路耗时长。
BFF 通过域名-BFE-微服务方式调用时，BFE 部分 VIP 存在连接超时问题无法彻底解决。
优化前 BFF 调用链：
方案：
BFF 模块升级 Mesh 服务。BFF 调用后端服务方式，由网关域名调用，升级为 Mesh service 调用。
优化后 BFF 调用链：
**收益：**BFF 调用微服务链路耗时降低 100ms+，BFE VIP 连接超时频发问题得到根治。
6.3.2 接口性能优化
通过分析接口实现逻辑以及 SkyWalking 调用链，发现下面三类问题：
第一类问题：代码实现问题。属于低垂的果实比较容易摘到。
问题：
BFF 及后端接口链路存在非必要串行请求
前后端均存在可以使用缓存场景
方案：
在 BFF 实现层面，将三次串行请求，优化成必要的两次串行，其余均使用 Promise.all 并行处理
对服务端接口后置处理器，统一使用线程池异步处理
对标签元数据、表头配置元数据等接口增加 Redis 缓存
前端对权限、查询条件等接口进行预加载，并增加本地缓存
第二类问题：性能调优。这部分需要了解 ES、RPC 框架底层实现原理。
问题：
使用 ES 检索模糊查询性能较差
线索服务压测不达标，高 QPS 下请求排队
方案：
使用全文检索来代替模糊查询
调整 RPC 调用 RPCIoWorkThreadNumber 工作线程数
第三类问题：超时问题。这部分优化场景复杂，难度较高。超时问题有几类：
问题：
RPC 调用连接超时：老版本 Mesh sdk 每次发起请求时会重新创建新的连接，导致调用方在并发大或者访问的服务平响高时，会出现连接等待，以至连接超时。
网关查询超时：线索所属 DB 集群 sfcrmsales 磁盘利用率较高，慢 SQL 及长事务较频繁，DB 集群稳定性不高，导致 DB 查询频发超时。
依赖外部服务超时：线索列表需要对线索池权限等进行鉴权操作，依赖 ACS 团队权限接口超时频繁；列表检索完毕后，需要对部分字段进行加工，涉及不少外部团队 HTTP 请求调用，其中大商业广告信息 open API 调用超时最为频繁。
方案：
1. 对 Mesh SDK 进行连接复用改造，并调整服务自身 IO 线程数，解决 QPS 高的情况下连接等待问题；
2. DB 集群稳定性治理
设立 DB 稳定性治理专项，增加 DB 告警、值班机制；
联合 DBA 对慢 SQL、长事务、连接数异常、主从延迟高等问题进行彻底分析、排查、解决、验证、根治；
对 DB 中重试表、分配日志表、outbox 表等大表进行清理，对线索原始信息主表进行定期数仓转储，并清理表中大字段；
对集群中非一级业务表进行迁库操作，减轻线索 DB 集群存储压力。
3. 超时问题治理
调整 ACS 服务线程池大小，对 ACS 服务进行水平扩容；
对广告信息接口进行 缓存+离线数仓+实时调用 组合查询方案，并调整后置处理器超时时间，保证绝大部分场景查询速度。
收益：线索列表服务端耗时（P90）从 2500ms+，缩短至 800ms 以下。
6.3.3 前端性能优化
前端性能问题主要集中在渲染卡顿和静态资源加载耗时长两方面。
第一方面：列表渲染优化
背景：
爱番番前端整体采用 vue 技术栈，elementUI 作为 vue 生态中最受欢迎的 UI 框架，因其强大的功能、健全的生态以及活跃的社区，被选做爱番番前端 UI 框架。线索列表使用 element-ui 中 el-table 组件，能够支持列表场景常见需求。
问题：
1.大数据量（100 行、50 列）情况下，JS Long Task 时长将近 3000ms，线索列表渲染卡顿。
2.数据整体渲染时间较长，用户等待（loading）时间长。
3.el-table 不支持吸顶、吸底操作，单纯通过修改 CSS 样式亦无法实现，体验不佳。
分析：
阅读 el-table 源码发现，el-table 的实现是通过四个 HTML 原生 table（表头、表身，列表左右侧勾选列）实现。大数据量下，DOM 数量会变得异常庞大；尤其是在表头拖拽，对页面进行 Repaint 和 Reflow 时计算量巨大，Long Task 较长，导致页面卡顿。
调研基于动态渲染思路的开源组件 pl-table，不支持吸顶功能，且在行高不固定的情况下支持情况不良，被排除。
方案：
1.通过调研业界主流 UI 框架，只有 React 体系中的 AntD table 支持吸顶功能，但其 vue 版本存在滞后性并未支持该提醒。经过组内讨论，决定参考 React AntD table 实现思路，重新实现 AFF-UI table。
2.列表数据渐进式渲染。先渲染首屏数据，结束 loading 为用户呈现首屏列表。同时在用户无感知的情况渲染其他列表数据。
收益：
1.AFF UI table 相比 el-table，相同数据量下，DOM 数量减少 60%，100 行、60 列数据量下，渲染性能提升 300%；
2.支持列表吸顶吸底功能，体验提升较大；
3.渐进式渲染，首屏可感知渲染时长（P90）从 2000ms 降低至 500ms 以下。
第二方面：静态资源优化
背景：
爱番番前端使用自研 Tangram 微前端架构，分为主模块「common」，以及其他业务域子模块。支持各敏捷小组页面分代码库，独立部署运维。前端静态资源均部署在百度云 BOS 上，通过 BFE 进行域名静态资源转发定位。
问题：
静态资源经过 BFE 转发，增加链路耗时
静态资源未使用 CDN 网络
静态资源体积较大
分析：
静态资源优化思路，从链路、缓存、编译三方面入手。
链路和缓存，是前端优化常见手段，方案大同小异。编译的问题一般隐藏较深，需要对 webpack 编译打包原理有一定了解。下面着重介绍下编译相关分析过程：
1、首先通过监控平台，对 js 加载瀑布流进行分析，定位到 chunk-vender.js 存在耗时较高的情况，为性能瓶颈。
2、通过 webpack analyzer 对编译情况进行分析：
发现存在以下问题：
业务域代码中 chunk-vendors.js 打包了微前端框架底座 biz-crm-fe-common 模块，这部分能力可以在主应用中提供，业务模块打包是应该排掉。
部分依赖库（bce-sdk、tangram-ui、moment、lodash）体积巨大，需要考虑作为公共依赖放入主应用，或者在页面通过 Promise 异步加载。
代码库路由较多，复用组件较多，导致 chunk-common.js 体积较大，且静态资源整体体积大。
方案：
链路：
静态资源直接请求 BOS 域名，不走 aifanfan.baidu 域名，减少一层 BFE 转发链路
开启百度云 BOS CDN 加速
开启静态资源 gzip 压缩
缓存：
在首页中预加载线索列表相关静态资源
在 HTML 预加载线索列表相关 JS，利用 webpack require 特性，全局缓存列表相关 JS（该方案是方案 1 的进阶版，预加载更前置、彻底）
编译：
修改微前端框架 tangram-sdk 编译配置，排除 biz-crm-fe-commom 包
拆分前端代码库。将列表和详情之外的非核心页面迁移新代码库，保证列表 js 体积最小化
进行异步加载大体积依赖 js，使得初始化加载 js 体积压缩到极致
收益：
静态资源耗时（P90）从 2000+ms，优化至 500ms 以下
静态资源**gizp 总体积：**693.52KB → 228.83KB，总体积缩小 67%
附编译优化前后 js 体积对比（飘绿为优化后）
6.3.4 体验优化
问题：
列表全屏 loading，白屏时间长；
列表筛选条件全部、实时加载，客户感知时间长，且会有抖动；
表头数据默认值可全选（50+列），请求、渲染数据量大。用户在使用时需要横向滑动 3-5 屏，体验不佳。
方案：
列表筛选使用侧拉面板交互，本地记忆上次筛选条件并展示；
优化 loading 区域及方式，从视觉感知上最小化用户感知时长；
通过对所有用户自定义表头设置数据分析，及参考业界通用设置，增加表头数量上限。
收益：
性能优化和体验提升殊途同归。在 UBS 调研中，爱番番线索管家整体体验和性能在业界均处于领先地位。
6.4 收益
经过上述优化手段，线索列表整体性能达标。
回顾将近一年的性能优化旅程，大致经历了下面几个阶段：
「无从下手」用户反馈列表性能存在问题，尝试解决，但无法度量，在黑暗中摸索。（20 年 Q4 — 21 年 Q1）
「磨刀不误砍柴工」调研前端性能监控解决方案，启动爱番番大前端 APM Topic。（21 年 Q1）
「有的放矢」APM 建设，web 端全面落地。对线索列表性能有全面了解，优化工作逐步清晰明朗。（21 年 Q2）
「先摘低垂果实」使用常规手段，对前后端常见性能问题进行解决和优化。（21 年 Q3）
「难点攻坚、毫秒必争」不放过任何一个优化点，对前后端难点问题分别成立专项小组，集思广益，重点攻坚，不拿结果誓不罢休。（21 年 Q4）
三、总结
「以客户为中心，技术为产品服务」是爱番番线索管家团队一直遵循的原则。技术架构的规划首先应该围绕业务诉求展开，用合理的技术赋能产品，产品在不断的演进中对技术提出更高的标准和要求。线索列表是爱番番众多核心功能其中的一点，但管中窥豹，技术问题往往要从业务中寻找答案，理解业务是开展技术的前提。同时，业务的复杂度升级反哺技术架构进化。业务与技术相互促进，相辅相成，最终为用户创造价值。
产品和技术演进只有起点，没有终点。展望未来，线索列表能力通用化，配置扩展能力向 PaaS 平台演进，LowCode 及 NoCode 等方向均需要继续探索实践，我们要走的路还很长。
===
四、作者介绍
本篇系爱番番线索管家团队多位同学共同编写。
飞邪：架构师，擅长通过微服务架构和 DDD 落地复杂系统
TJ：设计师出身，努力向服务端转型的前端开发
Hana：一只耕耘在 To B 行业的设计狮
东拾：资深研发工程师，擅长业务系统架构设计
三木: web 前端工程师，擅长各种撸猫
五、推荐阅读：
---------- END ----------
百度 Geek 说
百度官方技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
百度官方技术账号 2021.01.22 加入
关注我们，带你了解更多百度技术干货。
评论