企迈科技 x DeepFlow：爆发式增长业务背后的可观测性平台实践

作者：闻长明，企迈科技质量运维总监

企迈科技是数字化门店 SaaS 服务的领先者，通过全渠道连接门店与顾客，提升经营效率和竞争力。近几年业务规模迅速扩大，技术架构面临性能和稳定性挑战，促使企迈引入 DeepFlow 作为可观测性平台，通过 eBPF 技术实现零侵扰的数据采集和分析。DeepFlow 帮助企迈优化性能、快速定位问题，并通过全栈调用链追踪和持续性能剖析提升服务质量。未来，企迈计划进一步融合 eBPF 数据与其他监控数据，构建全栈一体化平台，并加强与 DeepFlow 社区合作，推动可观测性技术进步。

01｜企迈科技

企迈科技，数字化门店 SaaS 服务引领者，致力于通过数字化技术连接门店与顾客，提供高效、智能的经营升级服务。全渠道链接经营场景，满足门店的全域经营需求，为商家创造更多机会，提升行业竞争力。企迈服务了沪上阿姨鲜果茶、霸王茶姬、呷哺呷哺集团、乐乐茶、益禾堂、丘大叔柠檬茶、乡村基、永和大王、老娘舅、紫燕百味鸡、绝味鸭脖、墨茉点心局、85度C、爱达乐等 2000 多家连锁品牌，50 万+合作门店、 7 亿多消费者、GMV 过千亿，助力数字经济的蓬勃发展。并获得多个知名资本投资，包括凡创资本、中金资本、顺为资本、高瓴创投和高成资本，于2022年2月成功完成 C 轮融资。作为全域门店经营平台，企迈秉持让生意经营更简单为初心，赋能品牌完成门店经营升级，与商家共筑门店数字经营的美好未来。

企迈科技

02｜可观测性面临的挑战

在疫情期间，企迈的SaaS服务在微信和支付宝小程序线上点餐领域的广泛应用，推动了业务规模的显著增长。然而，随着业务规模的扩大，我们原有的技术架构在性能和稳定性方面逐渐暴露出挑战，这促使我们寻求一个全面的应用可观测性解决方案。

虽然我们的 SRE 团队之前已经利用 Prometheus 和 SkyWalking 等工具建立了监控体系，这些工具确实能帮助我们快速定位一些常规的线上问题，但面对更复杂和深层次的故障时，我们需要更加丰富和有效的手段，以提高问题定位的效率，从而为用户提供更高品质的平台服务。例如，SkyWalking 能迅速指出哪个接口响应迟缓，但关于导致响应慢的具体原因，如网络延迟、接口内部函数执行时间过长，或是第三方平台接口响应慢等，我们希望不再依赖研发和 SRE 团队的经验和推测，而是更多依赖数据进行判断，以提高整体效率。

为了解决这些挑战，企迈的 SRE 团队开始广泛探索各种技术博客和论坛，寻找更优的解决方案。在这个过程中，我们注意到了 eBPF 技术，并了解到 DeepFlow 是一个运用 eBPF 技术出色的可观测性开源项目，具有许多成功的实践案例。经过与社区的多次深入交流，我们决定采用DeepFlow来构建企迈的可观测性平台。以下是我们在实际部署中特别看重的几个方面：

• 技术栈：DeepFlow 使用 cBPF/eBPF 实现了自动化的 AutoMetrics/AutoTagging 机制，既能以业务零侵扰的形式自动化采集到应用/网络的性能指标，又能自动化的打上各种业务/资源标签，让业务研发/SRE 都能快速的查找到所需数据；
• 突出能力：eBPF 技术与 SkyWalking 结合能将应用、网络、系统 Span 数据进行关联能加快故障定界；通过 eBPF 无需插码持续性获取应用程序的函数调用栈快照，可绘制任意进程的 CPU Profile，帮助开发者快速定位函数性能瓶颈；
• 代码开源：DeepFlow 是一个基于 Apache License 的开源项目，有利于我们后续的定制化开发；
• 技术支持：与社区合作近大半年，一直在持续活跃，稳定迭代，同时社区给的技术支持非常到位。例如我们在调用链追踪火焰图中希望将应用 Span 与网络/系统 Span 分开查询展示，以及在部署过程中出现的性能和卡点问题，社区同事都提供了专门的社群和接口人对接我们的需求。

03｜企迈可观测性平台

我们以 DeepFlow 为底座并联合了一些其他开源工具，构造了符合企迈科技业务特点的可观测性平台。我们参考了 DeepFlow 企业版做了 UI 层面的二开，主要聚焦在应用 RED（请求/错误/时延） 指标分析、全栈调用链追踪、持续性能剖析、网络流日志等功能。同时接入了 SkyWalking、Pyroscope 的数据，做深入应用代码层面的分析。因为企迈业务几乎都是 JAVA 开发，对于 JAVA 程序的分析还引入了 Arthas、JProfiler 等分析工具。

• DeepFlow 部署架构：企迈线上环境一共分三个大模块，由灰度发布环境、正式业务环境及运维工具环境组成。其中 deepflow-agent 与 otel-collector 在灰度发布环境及正式业务环境中部署，然后在运维工具环境中部署 deepflow-server/grafana 等后端的工具，对于基础设施 ClickHouse/MySQL 则使用云厂商提供的服务。目前企业已上线 300 个 deepflow-agent，后端配比 16 台 deepflow-server（10C35G），每天落盘 43TB 数据。

DeepFlow 部署架构

• 产品功能-服务 RED 指标量统计，DeepFlow 提供的 RED 指标量提供了一个全面的视角来监控和评估系统的整体表现。它们帮助团队识别问题、优化性能，并确保系统能够稳定可靠地服务于用户。在优化 DeepFlow 的性能和实用性方面，基于业务诉求及对可观测性数据开销的评估，我们去掉了 DeepFlow 秒级数据仅保留分钟级数据。我们不仅优化了系统的整体性能，同时用较低的资源开销满足了业务需求。

服务 RED 指标量统计

• 产品功能-全栈调用链追踪，不仅展示 DeepFlow 的系统与网络 Span，也将 skywalking-agent 数据通过 OpenTelemetry 投递到了 DeepFlow，使得可以从应用、系统及网络三个维度全栈的查看整个分布式调用链。同时利用 trace_id 与企迈的日志系统联动起来，实现了指标、追踪及日志数据的联动。

全栈调用链追踪 全栈调用链追踪

• 产品功能-持续剖析，即展示了 DeepFlow 基于 eBPF 零侵扰采集的 on-cpu 的 profile 数据，也通过 pyroscope-agent 采集了更多应用相关的 profile 数据（每个函数创建的新的 TLAB 对象大小/个数，每个函数争用锁的数量/时间）发送给 DeepFlow，实现了对服务多维度的性能剖析，快递定位疑难杂症。在此过程中，我们结合业务研发的使用场景，做了内核函数的按需展示。

持续剖析

• 产品功能-网络流日志，企迈业务中依赖的第三方服务在出现超时情况时，除了业务日志提示的超时外没有更多的排障手段，此时借助网络流日志可以快速的知道与第三方服务交互的网络情况如何。

网络流日志

04｜排障案例分享

1）第三方服务超时定位

第三方服务超时定位流程对比

最近我们新上线了扫呗支付下单功能，发现上线后我们的支付服务经常超时，通过日志告警发现是因为支付服务需要调用第三方服务完成支付动作，这些第三方服务的接口经常超时。现有业务日志只能知道是第三方服务存在超时情况，但却没办法更进一步分析是网络抖动还是第三方服务存在问题，接下来分享下利用 DeepFlow 数据如何定界问题。

接口超时日志

Step 1: 网络是否抖动。结合业务日志中反馈的域名使用 lookup 找到起对应的 IP 为 2xx.10x.32.xx，使用 IP 查看网络黄金指标量，发现 TCP 建连时延很低且 TCP 重传比例也非常低，这里说明网络整个情况是没问题的。

网络指标量异常

Step 2：网络传输是否异常。分析网络流日志，发现超时时网络传输存在异常，这个异常原因都是服务端重置（数据正常过程中，服务端发送了重置报文）。到此可确定网络并没有存在问题，是第三方服务存在异常。

第三方服务重置

Step 3：提工单给第三方服务。明确为第三方服务的问题后，将现有分析结果提供给第三方并等待他们改进。目前这个问题，第三方已经持续分析了大概快一个月，还并未有结果（推荐使用 DeepFlow，加快分析过程）。

2）大促前压测性能瓶颈定位

品牌方联名 IP 准备做大促，在此之前需要对我们的核心服务进行全链路压测。在压测过程中，主要关注服务的 RT 指标（响应时延）。对于我们的核心服务满意的 RT 值在 50ms 左右，而此次压测值已经高达 2.6s，已经远超过预期值，需要深度分析瓶颈点在哪里。

压测时延高

压测的时间点，发现服务对应 POD 的 CPU 消耗明显上升，需要分析具体原因。

压测 CPU 上升

通过分析 on-cpu 的性能剖析，我们发现 clientWork*** 函数存在明显的性能瓶颈。与研发团队沟通后，确认在查询客户端工作台时，SQL 查询中存在大量的 JOIN 操作，导致了性能瓶颈。研发反馈要从表结构和查询方式上进行优化，以提升性能。

on-cpu 性能剖析

on-cpu 性能剖析细节

05｜未来规划

经过两个版本的迭代，基于 DeepFlow 建设的企迈可观测性平台目前已经上线运行，越来越多的企迈后台服务在接入中；基于 eBPF 可观测取得了一些阶段性成果，在定位问题方面给研发提供了强有力的工具支撑；但我们深知可观测领域的深度不止于此，会加快功能迭代的步伐，大致计划：

• 进一步融合 eBPF 可观测性数据与指标、日志及调用链追踪数据，构建全栈一体化可观测性平台；
• 利用 eBPF 采集进程的性能剖析数据，实现 on-CPU、off-CPU、内存全栈性能数据分析展示；
• 将可观测覆盖面继续延伸到 MQ、Redis 等中间件，甚至 DB 层面，实现真正意义上的全栈全链路可观测；
• 结合 AI 能力，提供根因分析、故障预测、大模型智能助手等功能 同时将进一步加强与 DeepFlow 社区的合作，把 eBPF 可观测性在餐饮 SaaS 行业的实际应用经验和成果分享给社区，促进开源社区的共同发展。