我们需要将两套方案结合起来看,但是实际归因时为了确保准确性还采用后者来计算App网速,这样会漏掉一小部分弱网日志,但是不会误判。 因此我们通过流量的消耗来计算App网速,通过在内存中维护一个记录最近3s,6s,9s的流量消耗的队列,可以算出最近App的网络下行速率。 同时判定弱网的最低阈值,可以线下用charles限速来找出能够满足App加载页面的最小带宽。采用三个3s阶段中平均速率的最大值40KB/s作为下行速率。 问题分析工具分析单个白屏日志的工具:网络库和图片库的现场信息便于定位图片加载耗时集中在哪些阶段白屏现场页面内容问题比例下图是目前得物App线上白屏问题的分布,问题分配的比例在99.7%以上。 *文 / Jordas本文属得物技术原创,未经得物技术许可严禁转载,否则依法追究法律责任!
得物开放平台接入得物SDK 千寻简笔记介绍千寻简文库已开源,Gitee与GitHub搜索chihiro-doc,包含笔记源文件.md,以及PDF版本方便阅读,文库采用精美主题,阅读体验更佳,如果文章对你有帮助请帮我点一个 @[toc]简介本文接入得物开放平台,本文关键词得物开放平台、得物SDK、得物PUSH、获取订单、虚拟发货实现步骤1 引入依赖在得物开放平台下载JDK,本文以得物JDK1.3.8.RELEASE为基础进行接入 2 配置在得物开放平台中 -> 控制台 -> 应用管理 -> 我的应用 -> 应用详情 -> 应用信息即可查看应用证书,AppKey、App secret2.1 配置公钥私钥application-dev.yml 新增得物配置信息,其他环境一样配置### 得物配置dewu: gatewayHost: https://openapi.dewu.com appKey: xxx secret: xxxx2.2 -> 控制台 -> 应用管理 -> 我的应用 -> 应用详情 -> 应用信息即可查看应用证书,AppKey、App secret3.1 新建接口接收得物回调DewuController.javaimport
背景 得物App版本订单详情页中的文案有对应的文案配置后台统一收口文案取值,优化订单详情页的信息展示效果。 基于交易侧业务的广度和复杂度,仅仅靠人还是有一定的局限性,当面对此类业务特性时,功能为主+技术辅助的方式也更多的被应用,对于此次的需求,得物小伙伴们也尝试使用更多的方式尽可能保障线上质量,接下来就介绍下配置类文案测试订单侧的测试右移实践 分析思考 2.1 需求简介 在得物App的版本迭代中,为提升用户体验,产品侧提出订单详情页优化新需求,定义客户端模块组件,制定各个模块的信息展示规范,重新梳理订单详情页的全部文案,搭建文案配置后台,支持订单详情页头部文案支持可配置 (2)自动化脚本进行接口测试的方式校验 使用自动化脚本进行接口测试的方式讨论发现有如下优缺点: 图片 (3)业务监控平台增加脚本实现线上提前灰度 得物自研业务监控平台实现提前灰度方案优缺点如下: 图片 3.2.1 业务监控平台 得物自研的一款用于数据和状态验证的平台,数据流向如下: 图片 3.2.2 脚本实现 通过业务监控平台建立校验接口返回值文案中包含异常数据则飞书告警的规则,及时发现问题,具体实现如下
得物App的启动框架任务在近几年已经先后做过多轮优化,常规的抓trace寻找耗时点并异步化已经不能带来明显的收益,得从锁竞争,CPU利用率的角度去挖掘优化点,这类优化可能短期收益不会特别明显,但从长远来看能够提前规避很多劣化问题 2.ARouter优化在当下组件化流行的时代,路由组件已经几乎是所有大型安卓App必备的基础组件,目前得物使用的是开源的ARouter框架。 除此之外,so的加载任务不建议和其他需要IO资源的任务并发执行,在得物App中实测这两种情况下该任务的耗时相差巨大。 以上第一张图为优化之前得物App启动阶段任务的有向无环图,红框表示该任务在主线程执行。我们着重关注阻塞主线程任务执行的任务。 *文/Jordas本文属得物技术原创,更多精彩文章请看:得物技术官网 未经得物技术许可严禁转载,否则依法追究法律责任!
0.前情摘要 在一次飞行途中,我司客户遭遇到了得物App在飞机上的WiFi网络访问异常的问题。这让我们意识到在特定场景下,用户可能面临无法使用得物App的困扰。 为得物er稳定访问得物提供保障,同时也输出类似疑难问题排查模板。 1.知识速递 1.1 什么是空中WiFi技术? ,的确存在访问不了得物App的情况。 ,发现命中此策略 同时也从client端及防火墙出口同时进行了抓包: 电脑client侧: 图片 防火墙出口侧: 图片 基于上面的证据链,基本可以确认防火墙的策略误判了公司 得物App 的域名为下载类网站 2.8 进展同步 4/18,厂商进行了全网策略发布 4/19,我司ac设备自动进行了策略更新 4/21,请朋友帮忙在同一航班验证得物App使用流畅,验证通过 3.网络技术点回顾 3.1 traceroute
一、背景随着得物App各业务功能的丰富和升级,得物App内可供用户体验的内容和活动逐步增多,在用户App内体验时长不断增长的大背景下,App使用过程中的体验问题变得愈发重要。 针对应用体验类问题在传统自动化方式下的检测难题,我们结合AI模型在内部场景应用的经验,开始尝试在App上利用大型模型的分析能力进行巡检,并最终实现得物App智能巡检的应用落地。 页面展示一致性检测前面两个检测能力都是针对单页面的异常问题检测,目前,得物App上的不同业务页面比较复杂,通用用户需要在多个不同页面中跳转,在这种情况下,会出现不同页面中的UI信息展示的是否符合预期标准的问题 往期回顾1.深度实践:得物算法域全景可观测性从0到1的演进之路2.前端平台大仓应用稳定性治理之路|得物技术3.RocketMQ高性能揭秘:承载万亿级流量的架构奥秘|得物技术4.PAG在得物社区S级活动的落地 5.AntDesign6.0尝鲜:上手现代化组件开发|得物技术文/锦祥关注得物技术,每周更新技术干货要是觉得文章对你有帮助的话,欢迎评论转发点赞~未经得物技术许可严禁转载,否则依法追究法律责任。
1.前言 在离线数据研发中,随着业务的快速发展以及业务复杂度的不断提高,数据量的不断增长,尤其得物这种业务的高速增长,必然带来数据逻辑复杂度的提升,数据量越大,复杂度越高,对任务的性能的要求就越高,因此 2.任务优化策略 2.1 优化方向 图片 补充说明:目前得物大数据在阿里云的dataworks 环境下,集群层面做了比较多的工作,IO、网络、机架感应等暂时无需过多关注,如有自建集群时,可重点关注,我们重点关注 前文讲述,目前的得物的数据平台特性(dataworks),我们在IO、网络、RPC 通信机制等暂时涉入不深,且对于面向业务的数据研发来言,大部分人不会过多关注底层的实现原理,暂不做过多深入探讨。
11 月 12 日,有网友在某平台发布一段视频,视频中该网友声称收到在得物 App 购买的商品后发现货物存在问题,随即拍下视频反馈给得物官方,并上传了一些与商品相关的视频证据到平台。 之后发生的事情就非常诡异了,该网友手机突然弹出两条信息,疑似是得物涉嫌通过调用其手机权限,删除了相册中与得物货物相关的视频。 【图片来源于互联网】 这一视频迅速传播,有关得物 APP 侵害用户个人信息的言论广为流传,13 日一早,这一消息迅速登上“热搜”,并引发网友的广泛吐槽,得物方面不得不站出来回应。 得物APP表示绝不会侵害用户权益 对于网友曝光的得物 APP 调用客户手机权限,删除其录下的货物有问题视频证据一事,得物 App 发布官方声明,收到用户反馈后,已第一时间联系用户和手机厂商进行核查,一定会对此事负责到底 APP侵权事件时有发生 “得物 APP 删除用户照片”并非偶然,国内多家互联网厂商都曾发生过类似事件,豆瓣、拼多多等知名 App 均曾被手机系统检测到删除照片或视频。
一、背 景得物DBA自2020年初开始自建TiDB,5年以来随着NewSQL数据库迭代发展、运维体系逐步完善、产品自身能力逐步提升,接入业务涵盖了多个业务线和关键场景。 得物管理类目配置线上化:从业务痛点到技术实现2. 大模型如何革新搜索相关性?智能升级让搜索更“懂你”|得物技术3. RAG—Chunking策略实战|得物技术4. 告别数据无序:得物数据研发与管理平台的破局之路5. 从一次启动失败深入剖析:Spring循环依赖的真相|得物技术文 /岱影关注得物技术,每周更新技术干货要是觉得文章对你有帮助的话,欢迎评论转发点赞~未经得物技术许可严禁转载,否则依法追究法律责任。
内部工具演进:从被动式SaaS到Agentic工作流传统的数仓研发平台(如得物App内部数据研发平台Galaxy)、BI系统及指标字典,在形态上多属于被动式内部SaaS工具:即工具仅提供标准化的功能模块与图形化界面 三、工程实践落地:基于规范化I/O的效能演进本章将结合得物App数仓研发实证,以实际应用阐述上述底层逻辑在实际业务线中的落地场景。 往期回顾1.ClaudeCode+OpenSpec正在加速AICoding落地:从模型博弈到工程化的范式转移|得物技术2.大禹平台:流批一体离线Dump平台的设计与应用|得物技术3.基于CursorAgent 的流水线AICR实践|得物技术4.从IDE到Terminal:适合后端宝宝体质的ClaudeCode工作流|得物技术5.AI编程能力边界探索:基于ClaudeCode的SpecCoding项目实战|得物技术文 /博温关注得物技术,每周更新技术干货要是觉得文章对你有帮助的话,欢迎评论转发点赞~未经得物技术许可严禁转载,否则依法追究法律责任。
得物的校招薪资水平跟大厂一样,开的都挺高的,校招毕业年薪 40w 起步,最高档 offer 都到 50w 级别了。不过,得物工作强度会比较高,所以才开了比较有竞争力的薪资。 很多同学就好奇得物的面试难度如何?那么,今天跟大家分享得物的后端面经,其实跟面试难度大厂差不多,围绕八股+项目+算法这三个方面来考察。
1 前言 随着得物业务规模的不断增加,推荐业务也越来越复杂,对推荐系统也提出了更高的要求。 因为推荐场景主要是用 x2i(KVV)表推荐为主,而 x2i 数据是图(Graph)的边,所以我们给得物的推荐引擎取名 DGraph。 图片 图10 3 后记 DGraph 是得物在推荐业务上一次非常成功的探索 *文/寻风 本文属得物技术原创,更多精彩文章请看:得物技术官网 未经得物技术许可严禁转载,否则依法追究法律责任!
一、前言通过修复历史遗留的Crash漏报问题(包括端侧SDK采集的兼容性优化及Crash平台的数据消费机制完善),得物Android端的Crash监控体系得到显著增强,使得历史Crash数据的完整捕获能力得到系统性改善 /apex/com.android.runtime/lib64/bionic/libc.so (__stack_chk_fail+20)#02 pc 000000000000a768 /data/app 和音视频的小伙伴一努力下,经历了几个版本终于解决了这个系统bug,目前仅剩老版本App有零星的上报。 此问题从21年首次上报以来在得物的Crash列表中一直处于较前的位置。 文 / 亚鹏关注得物技术,每周更新技术干货要是觉得文章对你有帮助的话,欢迎评论转发点赞~未经得物技术许可严禁转载,否则依法追究法律责任。
一、前言 自建 Redis 系统是得物 DBA 团队自研高性能分布式 KV 缓存系统,目前管理的 ECS 内存总容量超过数十TB,数百多个 Redis 缓存集群实例,数万多个 Redis 数据节点,其中内存规格超过 *文 / Miro 未经得物技术许可严禁转载,否则依法追究法律责任!
1.前言 在离线数据研发中,随着业务的快速发展以及业务复杂度的不断提高,数据量的不断增长,尤其得物这种业务的高速增长,必然带来数据逻辑复杂度的提升,数据量越大,复杂度越高,对任务的性能的要求就越高,因此 2.任务优化策略 2.1 优化方向 图片 补充说明:目前得物大数据在阿里云的dataworks 环境下,集群层面做了比较多的工作,IO、网络、机架感应等暂时无需过多关注,如有自建集群时,可重点关注,我们重点关注 前文讲述,目前的得物的数据平台特性(dataworks),我们在IO、网络、RPC 通信机制等暂时涉入不深,且对于面向业务的数据研发来言,大部分人不会过多关注底层的实现原理,暂不做过多深入探讨。
而目前因为项目业务场景的扩展,要越来越多的承担toC的功能,在得物App中使用场景也同样增加,这对项目性能和稳定性又带来了额外的挑战。 ---本文属得物技术原创,来源于:得物技术官网得物技术文章可以任意分享和转发,但请务必注明版权和来源:得物技术官网
得物测试环境稳定性治理也经历了几个阶段:2020~2021:多套物理环境隔离方案(基于ECS)T0、T1、T2三套测试环境,每套环境物理隔离,无资源冲突和共享。 2021~2022:MF全链路容器环境方案(基于容器)随着业务增长,3套测试环境已明显不能满足业务需求,因此去年得物基于容器快速搭建了10套MF环境用于支撑独立项目的测试。 下面主要介绍得物染色环境是如何做的2.染色环境方案2.1 基本思路图片如下图所示,最初的设想是:服务可以按照流量标把流量路由到相应染色服务上如果染色标对应染色环境没有此服务,则流量会走到基准环境如果染色环境服务添加了 后续得物也会尝试用染色的能力解决生产灰度发布问题,相信也会有不错的效果。---*文/大地关注得物技术,每周一三五晚18:30更新技术干货要是觉得文章对你有帮助的话,欢迎评论转发点赞~
告别数据无序:得物数据研发与管理平台的破局之路2. 从一次启动失败深入剖析:Spring循环依赖的真相|得物技术3. Apex AI辅助编码助手的设计和实践|得物技术4. 从 JSON 字符串到 Java 对象:Fastjson 1.2.83 全程解析|得物技术5. 用好 TTL Agent 不踩雷:避开内存泄露与CPU 100%两大核心坑|得物技术文 /昆岚关注得物技术,每周更新技术干货要是觉得文章对你有帮助的话,欢迎评论转发点赞~未经得物技术许可严禁转载,否则依法追究法律责任
*文/Jeremy 本文属得物技术原创,更多精彩文章请看:得物技术官网 未经得物技术许可严禁转载,否则依法追究法律责任!
那容器SRE究竟要怎么结合业务,得物容器SRE又有哪些最佳实践,本文就得物容器SRE的一些事情向大家做介绍。 做成了C/S模型,但需要强制让所有接入ASI的基础组件在关键的位置统一使用Defender做K8S流量风制,这个目前在得物这个阶段很难推得动,所以可以降级到Webhook机制去实现。 4.总结上述几个案例都是得物容器SRE团队在日常工作中真实发生的事件,覆盖的也只是多项工作中的冰山一角,写这篇文章也是想让大家认知到我们团队,了解我们容器SRE。 我们是得物容器SRE团队。我们团队的宗旨是为全司提供稳定、高效、安全的支撑和服务。 得物容器化集群维护、系统网络维护以及系统基础组件维护。保障基础环境的稳定、高效,并提供丰富的工具和平台提升系统的自动化、可视化、智能化。