随着得物业务规模的不断增加，推荐业务也越来越复杂，对推荐系统也提出了更高的要求。我们于2022年下半年启动了DGraph的研发，DGraph是一个C++项目，目标是打造一个高效易用的推荐引擎。推荐场景的特点是表多、数据更新频繁、单次查询会涉及多张表。了解这些特点，对于推荐引擎的设计非常重要。通过阅读本文，希望能对大家了解推荐引擎有一定帮助。为什么叫DGraph？因为推荐场景主要是用x2i(KVV)表推荐为主，而x2i数据是图(Graph)的边，所以我们给得物的推荐引擎取名DGraph。
消费者在得物下单购买商品后，卖家不会直接发货给买家，而是先发货给得物，由得物鉴别师团队对商品进行真伪鉴别和瑕疵查验分级，确保是全新正品之后，才会发货给消费者。全流程由得物技术提供的系统能力支撑运作。
商家后台前端代码目前代码量达到十万级，每个迭代团队需要在同一仓库中迭代几十个需求，在日渐庞大的巨石应用下如此活跃的迭代，开发效率与构建效率上给我们带来了一些挑战，我们需要优化以下几点： 代码构建体量大，随着时间推移，构建速度的优化空间较少。 巨石应用下各个业务模块没有做物理拆分，管理与维护难度提升。 应用粒度较粗，在发布节点上需要对应用做进一步拆分以优化发布粒度。 巨石应用下，组件与业务的关系需要梳理，避免出现重复开发的情况。 微前端是目前解决应用拆分的主要解决方案，但是由于其隔离性的机制使得各个子应用间完全隔离，使得用户在开发子应用时无法访问其他子应用页面，这对于各子应用存在关联关系需要同时访问开发的场景开发效率较低，并且目前市面上已经完全封装的主流微前端框架对我们来说是黑盒，无法做到高度自定义，无法满足特定拆分需求，因此我们决定采用模块联邦与大仓模式结合的方式解决以上问题。
得物提供大量商品买卖等服务，资金流转量大，任何由于设计缺陷、系统缺陷、系统故障、人为操作、安全漏洞等因素都会引发直接或间接资金损失。资损防控就是在项目全生命周期内，引入多种资金分析和控制手段，预防资损故障或控制资损故障影响范围。
老网关使用 Spring Cloud Gateway （下称SCG）技术框架搭建，SCG基于webflux 编程范式，webflux是一种响应式编程理念，响应式编程对于提升系统吞吐率和性能有很大帮助; webflux 的底层构建在netty之上性能表现优秀；SCG属于spring生态的产物，具备开箱即用的特点，以较低的使用成本助力得物早期的业务快速发展；但是随着公司业务的快速发展，流量越来越大，网关迭代的业务逻辑越来越多，以及安全审计需求的不断升级和稳定性需求的提高，SCG在以下几个方面逐步暴露了一系列的问题。
订单的履约之路就是从发货开始，看似简单的发货功能，其背后却藏着许多的小秘密。 发货的业务特点： B端业务，性能要求不高，因为存在批量发货的场景。 发货时间比较分散，所以并发量不大。 业务复杂，涉及到N种订单类型的发货，不同的订单类型有着不同的业务规则。 随着公司业务的发展，订单类型的增多，没有进行抽象的发货逻辑随着迭代的推进难免会显得落后。当然，在迭代的过程中，也一直在优化，一直在演进，正所谓没有最好，只有符合当前业务现状的最合理。
Flutter虽然火了很久，但是大家对Flutter代码静态检查原理与应用依然有很多大大小小的问题，在Flutter开发中就存在一些大家都会遇到普适性的问题: 团队沉淀了很多flutter编码规范。目前团队完全靠人工CR，人工CR存在效率低，容易遗漏。 另外一方面,我们在业务迭代中也总结了大量代码质量、代码稳定性、代码性能方面的最佳实践。同样这些最佳实践也是通过人工CR来保证的。 上述两个点，均指向了人工CR的缺陷与不足，因此我们急需一些自动化手段来解决人工CR的效率低、容易遗漏这一问题。 所以想通过本文来为大家介绍下，代码静态分析可以在编码时让IDE实时提示程序员其代码存在缺陷甚至根据最佳实践的内容提示更好的代码实现。
作为客服域访问量最大的页面之一，订单详情页在客服的日常工作中被用来查阅用户的订单信息，以此为进线的买卖家用户提供更好的购买服务，进而提升用户的满意度。无论是一二线客服还是客服管理者，都能在日常使用的系统中直接访问到详情页，因此客服订单详情页的入口也比较多，目前已经超过了10处。
随着自动化测试左移实践深入，越来越多不同类型的需求开始用自动化测试左移来实践，在实践的过程中也有了新的提效诉求，比如技改类的服务拆分项目或者BC流量拆分的项目，在实践过程中，这类需求会期望不同染色环境在相同的配置条件下，拆分后的代码和基准release代码的接口响应response有全量对比结果才能更好达到需求验证点。
