得物流量录制回放平台经过几个月的建设，目前已支持了多个域的日常开发回归工作，沉淀了1000+自动化回归用例，帮助开发人员在上线前发现了多起隐藏bug。作为一个阶段的小结，仅以此文记录下得物流量录制回放体系建设的经验和踩过的坑...

当我们收到线上服务的报警，如何正确的处理？当遇到莫名的性能问题，如何定位到 RootCase ?线上问题诊断总是困难重重，但是我们可以通过成熟的方法论和工具链来帮助我们迅速定位问题。这里根据我们内部的实践和大家做一个分享。

回顾从零到一的特征处理以及从DeepFm到适应工程架构的DLRM的优化之路。

这里先简单介绍一下白屏监控实现方式，在进入webview后，由客户端对webview进行截屏随后上传图片到 OSS，并进行埋点。

在flink层消费埋点数据，获取图片，对图片判定结果(白屏，非白屏)进行落库。

最开始的判断方式是对图片像素点进行遍历，看是否有纯色区域占比大于90%，有的话就认为是白屏。

这种策略发布后我们发现了很多bad case， 最典型的当属任务完成倒计时、用户搜索页面，这种页面纯色区域都是大于90%的，但是我们不能认为他是白屏，针对各种复杂的情况，我们最终考虑由机器学习来自动识别我们的图片。

随着抖音、快手等短视频的崛起，短视频正在成为大家主要的娱乐消费内容，得物正在向社区化转型，短视频是非常重要的社区内容载体。但是短视频的播放卡顿在大多数场景下比较影响用户的体验。所以我们需要一整套行之有效的播放器优化的方案。

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。

Sentinel是面向分布式服务架构的流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来帮助您保障微服务的稳定性。

我们都知道MySQL被称为关系型数据库，其他众多存储引擎被称为非关系型数据库，这里要聊的GDB就是其中的一种。说来也讽刺，MySQL被称为关系型数据库，但是实际上处理关联关系并不那么友好。Join语句稍有不慎就是一个慢查询，DBA同学也往往盯着Join语句，常常建议我们能不用就不用。而GDB（Graph Database）的图形结构存储本身，就代表着关联关系，能够很好处理这些问题。

在社区业务中，关系尤其重要，特别是用户与用户之间的关注关系、用户与内容的点赞关系等等。这些信息能代表用户的喜好，我们能使用这些信息让他们找到志同道合者，让他们看到更多喜好的内容。本文中，我们通过几个问题，来聊聊GDB在得物社区亿级别关系链中的实战。

随着得物App业务高速发展，Android项目的代码量与组件数量迅速增加，项目编译时长也明显升高。今年初增量编译平均耗时接近3.9分钟，严重影响了开发效率，也促使我们探索各种措施缩短编译时间提升开发效率。

卡顿就是在应用使用过程中出现界面不响应或者界面渲染粘滞的情况，用户在操作App时，会出现的页面掉帧现象，给用户直接观感受就是页面卡卡的，严重影响用户体验。

在移动端App开发中，由于H5 Web页面具有原生应用不具备的多平台复用、热更新等诸多便利特性，我们往往会将一部分对性能体验要求不是特别高的页面采用H5 Web完成，然后App基于WebView作为容器承载页面，而跨端通讯就是这一场景下的刚需功能。

对于做 CV 同学的人来说，图像识别是入门中最简单的模型，也是最最基础的模型。在不同的 CV 任务中，即使发展多年，都一直保留着利用训练好的图像识别任务重的模型权重，作为 backbone 用于加速训练收敛的作用。但是面对一些图像识别的任务，我们如何根据业务需求去改造一个已经比较完备的识别任务，还是蛮有意思的一个话题。

我在社区搜索迁移项目中首次落地了 Diff 自动化测试，从测试到上线的过程中,累计发现很多处bug，发现了很多潜在的、不易发现的问题；最终该项目上线后流量从5%提升到100%，仅用一周完成全量的切换，且过程中指标无异常。

大促，对于电商公司来说就像家常便饭。那么如何保证大促时线上系统的稳定性呢？答案就是：全链路压测。

全链路压测就是对业务功能的整条链路进行压测，并且使用真实的线上环境，这样才能保证压测结果跟大促时的流量应对不会差太多。但是压测的时候需要对底层存储进行影子库的配置，所谓影子库就是复制一份一样的业务数据库，当压测的流量来临时数据操作都是走影子库，这样才能保证真实的业务数据不被污染。

今天分享下压测过程中遇到的一些问题，也是一些经验，能够帮助我们在后续的工作中对设计方案，编码的重视。当你写一个接口，面临调用量 100 的QPS和 1000的QPS，所需要考虑的点不止多一星半点。

自从入职得物，接触工单系统之后，我碰到一些大大小小的问题；于是做了些记录与分析，分享下问题的排查思路。

在项目在起步阶段，一般都会为了快速上线快速给业务提供服务，欠缺设计考虑。一方面是因为业务在初期阶段需求不明确，另一方面也是因为开发难以预料到后面业务发展导致以前的代码变成了后来的问题。

iOS内存泄漏是一个不起眼的小问题，但是随着业务增加，项目越来越大，内存泄漏导致的卡顿、耗电、OOM等问题也会越来越多，得物作为快速崛起的一家公司，技术没有完全跟上业务的发展，此问题更为严重。

在得物APM架构团队的研发实践中，我们参考了市面的一些内存泄漏监控方案，研发了基于对象关系扫描，精准定位泄漏对象的方案，并可用于生产环境。

本文主要分享下该解决方案的技术背景，技术原理，为该问题的解决提供相对比较完整的方案和一些新的思路。

每个电商公司订单系统大概率都会有主子订单的概念，而主子订单与业务模式和业务特征紧密相连，得物的订单设计是什么样子？