随着得物App和商品体量的快速发展,圈选场景的商品集也在迅速膨胀,这些海量数据如何在不拖垮服务内存的前提下进行内存diff,一直是困扰在我们的难题,最终通过引入RoadingBitMap很好的解决了海量数据内存diff的问题。

当前我们微服务容器化部署JVM 实例很多,常常需要进行JVM heap dump analysis,为了提升JVM 问题排查效率,得物技术保障团队研究了JVM内存Dump 原理与设计开发了JVM 内存在线分析。

随着客服域章鱼工作台的独立孵化，热线作为重要的一部分，从工单迁移至章鱼工作台，这个时候的章鱼只能接打电话，查询基本信息，因为从工单迁移出来失去了和工单的绑定，因此与工单的重新结合，成为热线的一个里程碑式升级。

分类TAB商品流是得物app购买页面内除“推荐”页外的所有TAB内的商品推荐流，如“鞋类”、“箱包”等。当用户进入分类TAB中，我们可以简化为给定<userId, tabId, itemId> 三元组的商品流推荐，可以看出，分类TAB的推荐场景跟其他“开放式”推荐场景的最大差异在于，是限定条件下（品类）的推荐，与搜索场景有一点相似度，分类TAB代表着用户的品类意图。以我们目前的迭代进度，现阶段主要聚焦于<userId, ItemId>的二元建模，实际上<userId, tabId>，即用户的行为与TAB的相关性，以及<tabId, itemId>，即TAB与商品的相关性，是我们后续进行差异化建模需要着重考虑的；以下的相关进展主要讲述较为通用的商品推荐模型的落地迭代。我们以多目标排序模型作为精排策略。

客服的演进从开始的初始的平台到现在的成熟系统，在整个得物客服组成员的共同努力下，一步步的不断完善优化才有了在巨多会话量压力下，仍然稳定好用的系统。

团队归属于后方业务支撑部门，组内的项目都以pc中后台应用为主。对比移动端应用，代码库比较庞大，业务逻辑也相对复杂。在持续的迭代过程中，我们发现当前的代码仓库仍然有不少可以优化的点：

• 可以减弱对ui框架的依赖
  21年前端平台决定技术栈统一迁移到React生态，后续平台的基础建设也都围绕React展开，这就使得商家使用Vue生态做开发的系统面临技术栈迁移的难题，将业务逻辑和UI框架节藕变得异常重要。
• 代码风格可以更加统一
  随着代码量和团队成员的增加，应用里风格迥异的代码也越来越多。为了能够持续迅速的进行迭代，团队急需一套统一的顶层代码架构设计方案。
• 可以集成自动化测试用例
  随着业务变得越来越复杂，在迅速的迭代过程中团队需要频繁地对功能进行回归，因此我们对于自动化单测用例的诉求也变的越来越强烈。

为了完成以上的优化，四组对现有的应用架构做了一次重构，而重构的核心就是整洁架构。

随着得物 App 用户开始快速增长，业务线日趋丰富，也对底层数据库带来了较大的压力。各个业务线对于数据分片、读写分离、影子库路由等等的需求成为了刚需，所以需要一个统一的中间件来支撑这些需求，得物“彩虹桥”中间件平台应运而生。

Mock是一个接口编辑模拟工具，可以快速手动或者基于YAPI创建Mock接口模拟数据调试，同时支持场景，场景组的快速切换，方便在开发期和测试阶段试验不同数据返回的UI功能逻辑。

Mooncake数据模拟平台是得物统一的针对端侧（包括前端，客户端），与服务侧联调Mock的一款工具产品，在平台内部可以快速的创建各个项目产品的Mock多场景数据。本文主要聚焦Mooncake数据模拟平台的探索和实践。

Android 应用层的开发有很多模块，其中 WebView 就是最重要的模块之一。对于一个百万级用户的应用，WebView 必然是不可或缺的，而对于 得物App 这样的电商应用，更是不言而喻。而对于大部分开发者而言，并没有深入的去了解过 WebView 的一些实现细节，本文就从 WebView 启动的视角分析一下 Android Oreo 下的 WebView 多进程模式，帮助大家更深入的了解 WebView，并提供一些优化上的思路。

现货业务目前基于算法模型+运营配置得出订单预计履约时长，由于时效策略调整需求且现货订单数据回收周期较长，因此需要建设时效仿真平台能力，产品自行根据业务需要进行时效仿真实验并得到对应结果。

本文探索了基于用例驱动的架构设计逻辑，核心思想是采用用例驱动设计，基于“演绎法+自上而下”的逻辑来设计技术方案，帮助开发人员理清技术方案设计思路并提升技术方案的质量和评审效率。

本文主要介绍得物实时调试的全套解决方案，实现对测试包还原出包环境和无需编译就可以进行断点调试的功能。整体按实时调试方案的可行性分析，方向调研，优化方案设计，推进优化落地，最后在团队推广的流程。本文主要讲4个主要内容，包括:Attach to Process介绍，环境还原，实时调试探索，组件化工程的实时调试。

项目文档是对于项目一个快速了解的一个最好方式，能从中获取到其是所服务的业务，参与开发所具备的知识体系，开发前所需做哪些准备，遇到问题所需询问的时的人员，不仅能帮助新手快速上手，同时也有助于多个项目并行时，相互之间进行切换起到温故的效果。

zookeeper是一个比较成熟的，经过市场验证的分布式协调框架，可以协助我们快速的解决分布式系统中遇到的一些难题。另从上面的介绍中发现，zookeeper的核心是zab，etcd的核心是raft，那可以思考下，还有哪些一致性算法？

异地多活的概念以及为什么要做异地多活这里就不进行概述了。概念性的很多，像什么同城双活、两地三中心、三地五中心等等概念。如果有对这些容灾架构模式感兴趣的可以阅读下这篇文章进行了解：《浅谈业务级灾备的架构模式》。

在我们开发测试过程中，登录验证码几乎随处可见。特别是春节抢票，有没有被12306的验证码搞的崩溃呢？ 教大家一个办法：利用机器学习来自动识别验证码！