618技术实践

基于传统认知，前端产品直接触达消费者，往往具有高度的定制化、需求变更频繁等特点，要求具有很好的动态性, 能够满足不同客户的需求。那么能否建设类似的前端中台产品，我们姑且称之为“前端领域产品”，实现接入

每逢618大促，业务量突增，随之产生的业务咨询量也会增多，因此为了减轻客户售后团队的压力、提升问题响应的速度、 不改变用户的使用习惯 、保障大促业务的稳定性24小时值班应答，第一时间帮忙客户解决问题，

基于本次618大促JDV平台支持大促过程中的表现，共从大促总结、能力沉淀、待提升项3个方向也进行了相应总结和反思。

通过这个预警系统，我们能够提前发现并主动处理对账事后异常，其技术难度并不高， 更多的讲究的是一个方法。对此方法起了一个名字叫"先知预警"，也希望此理论能对您的系统有所帮助。

近三年，京东混沌工程作为大促三道防线之一，在促前扮演了非常重要的角色，而Y的混沌实践，也在不断地进行升级，主要从应用覆盖率和场景覆盖率两个方向明确提升方向，并在集团混沌大赛上取得了一系列突破和成绩。

竞速榜是大促期间各采销群提供的基于京东实时销售数据的排行榜，同样应对大促流量洪峰场景，通过榜单撬动品牌在京东增加资源投入。竞速榜基于用户配置规则进行实时数据计算，榜单排名在大促期间实时变化，

背景 618 大促来了，对于业务团队来说，最重要的事情莫过于各种大促营销。如会场、直播带货、频道内营销等等。而弹窗作为一个极其重要的强触达营销工具，通常用来渲染大促氛围、引流主会场、以及通过频道活动来

大数据时代，越来越多的业务依赖实时数据用于决策，比如促销调整，点击率预估、广告分佣等。为了保障业务的顺利开展，也为了保证整体大数据链路的高可用性，越来越多的0级系统建设双流，以保证日常及大促期间数据流

本篇文章主要介绍在实际的开发过程当中，如何使用GPT帮助开发，优化流程，恰逢今年京东20周年庆，文末会介绍如何与618大促实际的业务相结合，来提升应用价值。全是干货，且本文所有代码和脚本都是利用GPT

路由计算服务是路由系统的核心服务，负责运单路由计划的计算以及实操与计划的匹配。在运维过程中，发现在长期不重启的情况下，有TP99缓慢爬坡的现象。此外，在每周例行调度的试算过程中，能明显看到内存的上涨。

在618保障大促稳定性过程中，消失的异常堆栈可能会给我们带来严重的麻烦，因为这些堆栈信息是我们解决线上问题的关键之一。如何快速定位问题？想必大家心中都有自己的答案，当然最简单直接的办法还是查找异常堆栈

正值618大促，各方接口的调用都会大幅度增加。通过梳理接口依赖关系来减少重复调用，对本系统而言，降低了调用数据接口时的线程占用次数，可以有效降级CPU。对调用方来说，减少了调用次数，可减少调用方的资源

本文将探究京东竞速榜H5页面的核心前端技术，包括动画、样式配置化、皮肤切换、海报技术、调试技巧等方面，希望能够为广大前端开发者提供一些有用的参考和思路。

如何在混沌演练的场景中降低应用的MTTR，必须需要根据监控定位，然后人工进行反馈进行处理吗？是否可以自动化，是否有方案可以降低混沌演练过程中的影响？以此达到快速止血，进一步提高系统的稳定性

大促作为JD一年两度的盛事，质量备战是不可或缺的重要环节。每逢大促都是一次大型的联合战役，在这种战役中，不仅有各种“海陆空”技术争奇斗艳，还会让我们的技术视野变得更宽阔，让我们协同变得更默契，所谓以战

本文主要结合京东购物车的特性，从技术和业务层面综合考量，探索商品附属信息分页加载方案，为逐步扩容的购物车诉求做好底层技术支撑。

每每到618、双11这样的大型活动的时候，每天都有几个重要的大v或者品牌直播需要保障。 以往的重点场次监播方式是这么造的： 对每路直播的源流、各档转码流分别起一个ffplay播放窗口，再手动调整尺寸在

对于一个程序员，或多或少都能说出一些跟三高系统有关的技术点，而我本篇文章的目的，就是帮大家系统的梳理一下三高系统中的第一高：高可用性。