（一）从零到一：设计通用型埋点方案的实践与思考

引言

埋点，顾名思义即是在业务代码逻辑中上报某一标识和该标识相关的数据，与业务流程解耦，用于监控或者数据分析。在现代软件开发中，埋点已成为优化用户体验、支持业务决策的关键工具。

本文将从「业务需求初期设计埋点」到「后期重构」的角度，阐述如何设计通用型的埋点方案，希望能为读者提供实用的参考和避坑指南。

1. 起步阶段：初始埋点设计

1.1 业务流程

在业务发展初期，我们的流程相对简单，主要包含两个阶段：stage1和stage2。我们需要记录这两个阶段的耗时、结果，以及整个流程的总耗时。

1.2 数据结构设计

为了存储埋点数据，我们在数据库中设计了如下的数据表结构：

字段	类型	说明
id	bigInt	数据库主键
business_id	bigInt	业务ID
stage1_time	int	阶段1处理时长（单位：毫秒）
stage1_success	int	阶段1是否成功，枚举值：1:成功、0:失败
stage2_time	int	阶段2处理时长（单位：毫秒）
stage2_success	int	阶段2是否成功，枚举值：1:成功、0:失败
answer_success	int	请求是否成功（超时或者异常视为失败，返回即算成功），枚举值：1:成功、0:失败

这种设计简单直接，适合初期业务规模较小时使用。

2. 业务发展带来的挑战

2.1 架构变化

随着业务发展，我们采用了链路编排的方式执行请求。整个流程由多个node节点组成，每个node节点包含多个handler执行器，按照不同的策略类型处理具体的业务逻辑。

2.2 埋点方式的调整

考虑到埋点不在核心业务链路上，我们采用了事件驱动的异步上报方式记录埋点信息，但仍然使用MySQL数据库存储。

2.3 数据结构的膨胀

随着链路编排节点的增多，埋点数据也随之增加。新的数据结构变得更加复杂，包含了更多的监控参数：

字段	中文解释	归类
businessId	业务ID	业务基础参数
question	问题
answer	最终答案
qa_intervals	调用总时长
answer_success	调用是否成功
dialog_time	对话时间
traceId	追踪ID	监控基础参数
userIP	用户IP
serverIP	服务器IP
fail_reason	失败原因
stage1_start_time	阶段一开始时间	阶段一监控参数
stage1_end_time	阶段一结束时间
stage1_answer	阶段一答案
stage1_time	阶段一时长
stage1_success	阶段一是否成功
stage2_start_time	阶段二开始时间	阶段二监控参数
stage2_end_time	阶段二结束时间
stage2_response_time	阶段二响应时间
stage2_answer	阶段二答案
stage2_time	阶段二总时长
stage2_success	阶段二是否成功

2.4 现有方案的局限性

此时，大家可以明显发现，随着业务发展，编排节点增多，埋点数量呈现线性增长，如果继续采用这种数据结构存储，每在编排中接入一个节点到埋点中，数据表就新增若干个字段，这是最直接的致命缺点，数据表将野蛮无限增加字段。

现有方案有以下缺点：

1. 数据表字段呈线性增长，每增加一个编排节点就需要新增多个字段，不可持续。
2. 监控代码侵入业务逻辑，难以适应流程编排的灵活性。
3. 数据库字段设计不通用，链路节点记录不详细，难以快速定位问题。
4. 链路监控无法降级，难以应对高流量场景（如618/双十一大促）。
5. 事件驱动异步方式可能存在性能瓶颈，未经过压测验证。

代码参考：

3. 重构：设计新的埋点方案

3.1 埋点的定位与要求

在设计新方案前，我们明确了全链路埋点的定位：

（1）链路闭环：监控埋点虽与外部存在调用关系，但调用逻辑和链路编排由自身控制，可自己形成闭环，无需第三方回执确认

（2）用户群体：链路埋点面向产研和运营观看数据，不对外面向商家和用户使用。

（3）大促降级：埋点监控不影响主流程执行，不侵入业务逻辑代码，尽最大努力保证埋点记录。但必要情况下，可通过细粒度开关和全局开关进行埋点降级，影响是数据看板和数据分析会缺失降级后的数据。

（4）快速定位问题：埋点监控需要记录详细的调用留痕，链路编排存在多个node节点，每个node节点会存在一个或多个handler，埋点监控需要记录到handler级别，且每一步发生的错误和异常需要记录，且留存现场，方便排查。

（5）数据分析：可供运营、产品进行多指标数据分析，如耗时、成功率、PV、UV等。

3.2 新方案设计

基于以上定位和之前方案的缺点，我们设计了新的埋点方案：

1. 流程编排自动/手动上报：

• 利用node编排时自动在handler执行前后进行埋点上报。
• 保留手动上报入口，以应对特殊情况。

2. 异步上报：

• 通过消息队列（MQ）统一发送和消费，利用MQ的积压和并行消费能力实现异步解耦。

3. 数据存储：

• 使用Elasticsearch按季度创建索引模板。
• 只保留近6个月数据，每日离线推送至大数据平台备份。（假设每条请求对应20条链路日志，每日用户提问1W条，每日链路日志总数则为20W条，每季度约1800W）

3.3 新的数据结构

新方案采用通用字段设计，实现横向扩展而非列向扩展：

中文说明	字段	说明
接入方式	accessType
接入系统	accessSystem
追踪ID	traceId
业务ID	businessId
埋点标识（如类名）	eventTrackSign	唯一标识当前埋点
埋点状态	eventTrackStatus	开始、结束或为空
节点类型	handlerType	枚举：串行、并行
节点超时设置	handlerTimeOut
埋点结果	eventTrackResult	枚举：成功、失败
失败原因	failReasonCode	枚举：code码
现场信息	context_info
埋点类型	eventTrackType	枚举：手动、自动
时间	time	毫秒级时间戳

新方案与旧方案相比有很多优点，对比如下：

方面	旧方案	新方案
扩展性	列向扩展，字段增长快	横向扩展，通用字段设计
灵活性	固定字段，难以适应业务变化	通用字段，易于适应不同业务场景
性能	可能存在性能瓶颈	使用MQ和Elasticsearch，性能更好
数据分析	直接查询即可	需要额外的数据处理步骤，但更灵活
降级能力	无	支持细粒度和全局降级
问题定位	难以快速定位问题	详细记录每个handler，易于问题定位
代码侵入性	高，散布在业务逻辑中	低，主要通过自动上报实现
存储成本	随业务增长线性增加	通过定期清理和离线备份控制成本

到这里，重构后的方案就介绍完了，这里有一点值得注意，新的数据结构由于是通用字段设计，对于原始数据需要多一步数据处理的步骤进行数据分析与统计，不过这并不是太大问题，只要有原始数据存在，就可以针对业务所需要的数据指标做灵活的聚合统计。

4. 结论和最佳实践

经过从初始设计到系统重构的全过程，我们总结出了以下几点关键的最佳实践，希望能为同行提供有价值的参考：

1. 设计通用字段 通用字段设计是提高埋点系统灵活性和可扩展性的关键。它让我们能够适应不断变化的业务需求，而不必频繁修改数据结构。
2. 异步解耦 利用消息队列进行异步上报是一个明智之选。这不仅能显著减少对主业务流程的影响，还能提高系统的整体性能和稳定性。
3. 分层存储策略 采用Elasticsearch进行实时存储，辅以大数据平台进行离线备份，是一种平衡查询性能和存储成本的有效方法。这种策略让我们能够快速检索近期数据，同时保证长期数据的完整性。
4. 推进自动化埋点 尽可能实现自动化埋点，可以大幅减少代码侵入性。这不仅提高了开发效率，还降低了人为错误的可能性。
5. 预留降级机制 为高流量场景预留降级开关是非常必要的。这确保了在极端情况下，核心业务不会受到埋点系统的影响，从而保证了整体服务的可靠性。
6. 全面详细的记录 记录足够详细的信息是快速定位和解决问题的基础。在实践中，我们发现全面的日志记录能够大大缩短问题排查的时间。
7. 定期评估与优化 随着业务的不断发展，定期评估埋点系统的效果和性能变得尤为重要。我们建立了一个季度评估机制，确保埋点系统能够及时进行优化和调整。

通过这次从初始设计到重构的过程，我们不仅解决了当前面临的问题，还为未来的业务扩展奠定了坚实的基础。这个过程让我们深刻认识到，一个优秀的埋点系统应该是灵活的、高效的、可扩展的，同时又不应该对主业务造成明显影响。

感谢阅读～

---

感谢大家的观看！！！创作不易，如果觉得我写的好的话麻烦点点赞👍支持一下，谢谢！！！
相关文章已在掘金发布，体验更佳！！