VOP作为京东企业业务对外的API对接采购供应链解决方案平台，一直致力于从企业采购数字化领域出发，发挥京东数智化供应链能力，通过产业链上下游耦合与链接，有效助力企业客户的成本优化与资产效能提升。本文将介绍VOP如何通过亿级消息仓库系统来保障上千家企业KA客户与京东的数据交互。
现代互联网很多业务场景，比如秒杀、下单、查询商品详情，最大特点就是高并发，而往往我们的系统不能承受这么大的流量，这时候限流熔断就发挥作用了，限制请求数，快速失败，保证系统满负载又不超限。本文为大家介绍几种常见的限流算法及方案
在研发项目中，经常能遇到复杂的状态流转类的业务场景，比如游戏编程中NPC的跳跃、前进、转向等状态变化，电商领域订单的状态变化等。这类情况其实可以有一种优雅的实现方法：状态机。本文重点介绍有限状态机，并结合具体项目，通过状态机的应用将状态和业务逻辑解耦，便于简化复杂业务逻辑，降低理解成本。另外，重点讲解如何优雅的解决更广泛的复杂业务问题。
本文主要介绍了全渠道质量团队是如何利用R2来保障业务质量的。从为什么引入R2开始，一步步介绍引入R2到全渠道落地及收益情况。基于长城项目促销业务，详细介绍了全渠道接入R2的应用情况和R2的使用情况，以及R2助力发现的问题汇总
每逢618大促，业务量突增，随之产生的业务咨询量也会增多，因此为了减轻客户售后团队的压力、提升问题响应的速度、不改变用户的使用习惯、保障大促业务的稳定性24小时值班应答，第一时间帮忙客户解决问题，我们通过RPA+智能问答实现微信端智能客服，技术赋能业务，来保障整体业务的发展壮大。
Sleuth 简介 随着业务的发展，系统规模变得越来越大，微服务拆分越来越细，各微服务间的调用关系也越来越复杂。客户端请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果，几平每一个请求都会形成一个复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟超时或者错误都有可能引起整
在一些复杂的业务表中间查询数据，有时候操作会比较复杂一些，不过基于SqlSugar的相关操作，处理的代码会比较简单一些，以前我在随笔《基于SqlSugar的开发框架循序渐进介绍（2）-- 基于中间表的查询处理》介绍过基于主表和中间表的联合查询，而往往实际会比这个会复杂一些。本篇随笔介绍联合多个表进行查询以及树形列表的条件展示的处理实现，系统能够给大家一些参考思路。
摘要：其实游戏客户对数据库的诉求是很明确的，数据库应当“放心存放心用”。 本文分享自华为云社区《华为云GaussDB(for Redis)揭秘第27期：聊聊游戏业务怎么用高斯Redis》，作者：高斯Redis官方博客。 华为云数据库团队是比较重视技术洞察的，对客户真实的业务场景也比较看重。年初出差了
摘要：应用业务模型ABM（Application Business Model）是MSSI为客户提供的统一模型管理服务。 本文分享自华为云社区《【云图说】 | 第274期 MSSI之应用业务模型ABM，搭建业务与技术的数据治理桥梁》，作者：阅识风云。 应用业务模型ABM（Application Bu
产品生产制造是制造企业的核心业务活动，本期基于对生产制造活动的关键业务模型拆解来普及相关的基础业务知识，然后介绍传统信息化架构下生产制造活动涉及的主要应用系统，最后介绍基于统一数字平台构建业务一体化应用的企业数字化系统方案。
在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性，这里主要讲如何去补偿？补偿的方案哪些？这就引出来数据监控系统了。有小伙伴会问了，为什么业务状态监控系统可以做补偿？别急，且看本文。
复杂系统的架构设计不是一蹴而就的，合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。
之前总聊微服务，今天换一个话题---低代码。低代码这个词也是最近这几年很火的概念，尤其是遇到大环境下行，很多大厂和互联网那个公司也在慢慢在低代码方向发力，当然，对于传统项目交付型的软件公司，低代码也具有相当大的吸引力。
本篇文章主要介绍在实际的开发过程当中，如何使用GPT帮助开发，优化流程，恰逢今年京东20周年庆，文末会介绍如何与618大促实际的业务相结合，来提升应用价值。全是干货，且本文所有代码和脚本都是利用GPT生成的，请放心食用。
本文通过实际业务需求场景建模案例，为读者提供一种业务模型向数据模型设计的方法论，用于指导实际开发中如何进行业务模型向数据模型转化抽象，并对设计的数据模型可用性、扩展性提供了建议性思考
在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性，关于一致性的补偿，已经由算法部的大佬总结过就不再赘述。这里主要讲如何去补偿？补偿的方案哪些？这就引出来数据监控系统了。有小伙伴会问了，为什么业务状态监控系统可以做补偿？别急，往下看。
随着需求不断迭代，业务系统的业务代码突飞猛进，在你自豪于自己的代码量产出很高时，有没有回头看看线上真正的客户使用量又有多少呢？
本文旨在通过一个简化场景（“单服务应用”）下的负载测试，为“JSF业务线程池大小配置”提供基准测试结果，并形成一些普遍适用的结论。
在实际项目开发中无论 M 端、PC 端，或多或少都有一个 utils 文件目录去管理项目中用到的一些常用的工具方法，比如：时间处理、价格处理、解析url参数、加载脚本等，其中很多是重复、基础、或基于某种业务场景的工具，存在项目间冗余的痛点以及工具方法规范不统一的问题
结合京东业务研发实际情况，针对后端研发人员，设计一个微服务低代码平台，助力更高效低交付业务需求。现已结业，将我在本次项目中沉淀设计出的设计文档整理成文，期待与大家有进一步的碰撞沟通
