供应链仓储域子域繁多，例如库存域，lpn域等，平时开发的过程中涉及很多分布式事务的场景，例如收货加库存，发货扣库存，拣货入箱，发货出箱等一些分布式事务场景，所以迫切需要出一套分布式事务处理方案，在调研了市场上的分布式事务解决方案，结合wms自身业务域不是强一致性的特色，选择了最终一致性，且使用本地消息表去实现它。 本地消息表这个方案最初是ebay提出的，核心就是将需要分布式处理的任务通过本地消息日志存储的方式来异步执行。该方案可以存到本地文本，数据库或消息队列，再通过异步线程或者自动job发起重试。
测试环境治理一直是各大公司非常重要的一个课题，测试环境稳定性很大程度影响迭代开发&测试效率。 综合来看，测试环境不稳定的原因主要有以下几点： 测试环境的变更非终态变更，经常会有代码发布/配置发布导致服务无法启动或者链路有问题的情况。 变更频繁，开发需要联调、测试需要迭代测试，代码需要变更，配置也需要变更，权限控制就比较难做，增加了测试环境不稳定性。 并行需求，同一时间单个应用需要多个分支同时支持多个需求的测试，测试环境资源的抢占和冲突比较明显。 得物测试环境稳定性治理也经历了几个阶段：
CDN域名太多造成请求碎片化，导致以下几个问题： TCP建连频繁，网络请求性能差 用于请求CDN静态资源的网络连接池资源有限，由于不同域名会各自创建TCP连接，进而竞争TCP连接池资源，导致TCP连接频繁中断。再次发起网络请求需要重新进行TCP建连增加了建连阶段耗时（包括：DNS解析、TCP握手、TLS握手），导致总耗时升高。 域名太多，日常维护成本高 域名太多导致域名管理、性能监控、性能优化、线上变更复杂度增加，人力成本及运维成本高。 如：得物IPv6升级项目、TLS1.3协议升级项目都需要按域名分批执行多次线上变更流程（包括：测试回归，变更申请，变更评审，变更验证，性能监控）。 部分域名命名不规范，存在下线风险 由于历史原因，存在多个不符合现有新域名规范的域名名称（如：xxx.poizon.com，xxx.dewu.com）。非得物主体的域名，存在被强制下线的风险，比如旧域名下线项目，投入了大量人力成本进行改造。 DNS解析IP频繁，阿里云HttpDNS服务成本高 域名太多增加了每个域名在TCP建连时调用阿里云HttpDNS解析对应IP的频次，解析次数升高导致HttpDNS服务成本
得物技术一直以"上海最好的技术团队"为目标，打造学习型组织、形成技术知识沉淀、持续提升技术硬实力。对内我们做SmartCode技术沙龙、毒享会、技术夜校、毒家博客、得物小报、技术双月刊，持续打造学习型组织，营造良好技术氛围。对外我们持续提供得物技术沙龙、得物技术公众号、得物技术直播，主题覆盖稳定生产、技术架构、端智能、体验创新、算法架构、云原生、大数据、研发效能、项目管理等，期待与你一起交流，共同探索。 本次对内技术沙龙SmartCode邀请到阿里的资深技术专家朱国云（宗岱）老师来给我们分享《内存数据库Tair实战》，因为他有10多年的分布式存储、数据库的从业经验，并主导了Tair在阿里电商的双十一大促和单元化建设中的高效运行。本次分享，朱老师从“Tair的发展历史、Tair重要节点的技术挑战以及云原生内存数据库Tair的产品形态、Tair关键能力解读”等内容展开，得物内部的技术同学表示干货很多，也学到了很多。为此，经过朱老师的允许，我们整理了老师演讲的主要内容，供大家学习和参考。
2020 年 3月，得物技术团队在三个月的时间内完成了整个交易体系的重构，交付了五彩石项目，业务系统也进入了微服务时代。系统服务拆分之后，虽然每个服务都会有不同的团队各司其职，但服务之间的依赖也变得复杂，对服务治理等相关的基础建设要求也更高。 对服务进行监控是服务治理、稳定性建设中的一个重要的环节，它能帮助提早发现问题，预估系统水位，以及对故障进行分析等等。从 2019 年末到现在，得物的应用服务监控系统经历了三大演进阶段，如今，整个得物的应用微服务监控体系已经全面融入云原生可观测性技术 OpenTelemetry。
大数据时代，数据的来源极其广泛，各种类型的数据在快速产生，数据也是爆发性增长。从数据的产生，通过加工融合流转产生新的数据，到最终消亡，数据之间的关联关系可以称之为数据血缘关系。在数据中台的大背景下，数仓的开发者经常需要解决以下问题： 面对成百上千张的数据表，不知道该如何关联，也不知道这些表具有什么业务价值 执行过长，慢的无法忍受的SQL脚本，却不敢轻易进行整改 数据表是否包含机密数据需要被清理，以及这些机密数据是否被转存导致权限放大 其实，以上的这些问题都可以统一归类为数据发现问题。大部分企业会针对离线数仓任务进行SQL分析，构建表和字段的血缘关系，数据发现包括但不限于: 数据 表/列的业务分类分级和机密字段识别等。
在所有的互联网企业中，告警经常性的误告，都是让技术人员最头疼的问题之一。试想一下，在凌晨两三点时，你收到了来自告警平台的电话告警，于是你揉了揉惺忪的双眼，短暂的回味了下刚才的美梦，下床打开电脑，开始排查问题，却发现这是一个误告，线上业务都是在有序的运行当中，于是你关上电脑，重新上床睡觉，但此时你已睡意全无，在床上辗转反侧一个小时才睡着，于是乎，第二天同事看到了一脸沧桑的你。这种误告一次两次还能接受，但如果是每隔一天或者是每晚都会触发呢？
供应链时效域历经近一年的发展，在预估时效方面沉淀出了一套理论和两把利器（预估模型和路由系统）。以现货为例，通过持续的技术方案升级，预估模型的准确率最高接近了90%，具备了透出给用户的条件。但在接入前台场景的过程中，前台对我们提出接口性能的要求。 以接入的商详浮层场景为例，接口调用链路经过商详、出价、交易，给到我们供应链只有15ms的时间，在15ms内完成所有的业务逻辑处理是一个不小的挑战。
