业务百倍增长，得物如何在三个月完成交易平台重构？-InfoQ

得物 App 专注打造新一代潮流网购社区。截止到目前，得物 App 平台用户中，90 后占比超过八成。品牌升级和业务增长的同时，对应的业务架构和技术体系也需要更新迭代。

2020 年 3 月 16 日，得物技术团队在三个月的时间内完成了整个交易体系的重构，交付了交易平台化项目——五彩石项目。整个项目重新设计了 6 个核心交易应用，完成 180 项操作，21 个系统重新发布，相应的优化迭代还涵盖了社区、交易、供应链的解耦，交易平台化的演进、底层交互协议的更新、全链路压测落地等等。为了了解五彩石项目的整个构建过程，InfoQ 采访了得物 App CTO 陈思淼、交易平台和稳定性平台负责人金思宇。

电商平台业务架构的发展

电商起源于 1990 年，经历了 30 年的发展，现在电商平台已经成为了主流购物方式之一。如果从业务架构的角度来看，中国电商平台经历了几个发展阶段呢？陈思淼和金思宇从各自的工作经历出发，表示中国电商平台的业务架构都经历了相似的四个阶段。

第一阶段：通常这时的电商平台都是从零开始搭建的，全家桶系统，包含最基础的交易元素：用户、商品、库存、订单、支付。这些功能可能只是一个系统中的多个子模块，甚至只是一个简单的类，可以满足最基础的交易需求。

第二阶段：随着业务规模逐渐增大，团队人数也越来越多，整个平台维护难度增加，耦合严重，性能瓶颈也逐渐出现。这时就会开始做系统拆分，从业务域、基础服务、前后端分离的角度慢慢分割，拆分后的系统之间进行通信 (同步 / 异步)。

第三阶段：分布式服务，系统拆分之后，虽然各个服务会有多个团队分别负责，职责清晰。不过服务之间的通信增多、依赖关系逐渐复杂，甚至需要支撑业务量会更大，这时就会对服务治理、监控、缓存、数据分片、分布式事务等基础建设有更高的要求。

第四阶段：随着业务发展，在分布式服务的基础上，对服务稳定性、高可用等方面需要有更高的要求。淘系做了单元化、异地多活之后，这基本上变成了多个电商甚至外卖平台追求的统一思路；而在容器化逐渐流行起来后，基于容器化做弹性资源管理以及混合云 (异地多活) 就变成了另一种趋势。

与其它平台相比，电商平台在数据准确性、一致性、安全性，以及服务性能、服务稳定性方面都有比较高的要求，而且一旦出问题很容易被放大

所以，在做电商平台的系统设计和落地时，应当着重考虑以下几个方面：

是否在核心链路上，对于电商平台，交易浏览链路及下单 & 支付链路 (包含优惠活动 & 券) 属于核心链路，需要评估应用是否会对核心链路造成影响，以及属于强依赖还是弱依赖；
容量评估，包括峰值 QPS、每日产生的数据量，进而确认是否需要引入缓存、DB 选型（MySQL/TiDB）、数据是否需要 sharding、是否需要配置限流等；
性能评估，包括上下游依赖、对业务流程的影响、交互采用同步还是异步、对整体 RT 的影响等；对于核心链路上的服务，会在上线前做压测评估；
对数据稳定性的影响，包括对原有库表 & 索引的影响、对原有数据字段的影响、上下游数据一致性影响等。

得物交易平台的差异与发展

得物 App 技术平台构建可以追溯到 2015 年。当时，得物 App 初版以潮流社区 App 上线，打造国内主流 Sneaker 互动社区（2015 年 9 月 -2017 年初）。后来，基于对潮流文化的了解和年轻消费的洞察，慢慢发现社区内很多用户有鉴别的强需求，才衍生出了交易业务 (2017 年下半年)。

得物与其它电商最大的区别是什么呢？得物 CTO 陈思淼表示最大的区别就是交易流程中包含鉴别环节，一次交易存在强参与三个角色：买家、平台、卖家，而不像传统电商，平台很多时候只是提供流量入口。当然相应的，因为平台的“强中心化”深度介入，一笔订单对于卖家视角和买家视角，其生命周期并不相同，以现货交易为例，对于卖家而言，平台收到商品并且鉴别通过，就会收到货款，这笔订单对他而言也就达到了终态；而对于买家，只有在收到货之后才可能是终态。

除此之外，由于得物定位是潮流电商，因此对于平台内销售的商品，其潮流属性以及能否被鉴别有一定标准，所有商品都是平台统一维护（上下架、商品资料更新等等），也没有店铺的概念；

最初，得物平台内的交易与社区、鉴别“环环相扣”，所以当时的交易平台是写在同一个 PHP 项目内，集群部署、共享缓存、数据库。虽然，是很简单的设计，但对于当时的得物却是最合适的：能运行，迭代速度快，可以快速响应需求，很好的支撑了那个阶段的业务发展。

随着得物的业务发展，交易平台必须能够支持更大规模的业务、支撑其差异化的交易。因此，交易平台的迭代优化势在必行。

2019 年下半年，由于业务发展太快，原有的交易平台开始暴露出问题。一方面是无法承载更大的流量，经常出现性能瓶颈，比如大促期间百倍流量突然到访，压力倍增，稳定性也受影响；另一方面，原有系统架构也难以支撑日渐复杂的业务需求，重复轮子越造越多。

在这种情况下，得物 CTO 陈思淼决定启动交易平台化项目，统一规划 & 重构整个交易体系，也就是“五彩石”项目。

其实在此之前，得物交易平台也一直在做优化，包括服务拆分、引入新开发语言等等，但是底层数据模型并没有发生变化。因此，五彩石项目首先重新设计了原本的商品、多个订单系统、出价，形成了新的商品中心、订单中心、出价中心、销售库存中心、寄存中心以及超时中心。而支付和营销、商家，只是配合做了一部分调整，没有纳入项目范围。

交易平台化项目的业务架构及技术选型

受限于早期的团队技术基础和业务模式，最初得物交易平台技术选型和业务架构设计做了很多妥协。因此，在交易平台化项目中着重对此前痛点进行了针对性设计，当然在此过程中经历了太多挑战，在技术选型和模型设计时也有很多思考与决策。

首先是比较复杂的业务模型设计，当时团队几位骨干讨论了将近两周，梳理出原有 9 个系统中的数十个对象，然后合并类似的对象及行为，抽取出 6 个核心业务域，按照领域驱动设计的思路逐步设计整个系统。

以订单系统为例，当时得物存在多个订单系统，分别面向不同类型卖家，在每个订单系统中都包含了整个下单与支付逻辑，并维护了各自的库存，而其他业务拥有各自的模型设计，生命周期有太多差异。如果从更高的视角看，这些都是围绕订单这一模型的分场景行为。所以最终合并成统一的订单中心，并引入状态机引擎 Spring Statemachine 来解耦各个不同的交易流程，并在公用节点引入扩展点来实现差异化细节，而不应该属于订单领域的库存、物流、支付等信息，则分别划归到各自领域。

设计商品模型时遇到了更多细节挑战。商品其实是整个交易体系中最基础也最复杂的模块之一，原设计在平台不断扩充品类的需求下难以为继，经过多次讨论，得物最终参考业界内多个主流电商平台的设计，引入 SPU-Item-SKU 模型，同时针对搜索 & 推荐场景引入 CSPU（区别于天猫达尔文商品体系的 CSPU）、前后端数据解耦 (前后端类目)、属性分类 (销售属性、基本属性、供应链属性、扩展属性) 等等，完成了最终的商品域模型及行为设计。

目前很多人在谈领域驱动设计（DDD），DDD 确实有很多可取之处，但在应用时也很容易陷入争论，例如领域、实体、值对象、聚合、聚合根、限界上下文、CQRS、事件溯源、分层架构、六边形架构等等。实际上，DDD 的核心还是领域模型本身，通过领域实体、领域服务完成对应的业务逻辑落地才是 DDD 的核心目标，至于其它，选择最合适自己、合适团队的方式就足够了。

再聊聊技术选型，按照当时的项目周期，可选空间相对有限，只能尽量满足“够用”的需求：

采用了基础架构团队基于 SpringCloud 全家桶封装了一套脚手架 Fusion，同时加入了 prometheus 监控埋点，而内嵌的 Web 容器选择了相较于 Tomcat 性能更好的 undertow。
同步内部通讯选择了 Feign；注册中心采用 Consul，配置中心选择了相对友好的 Apollo；
异步通讯统一选择了 RocketMQ，结束了原有多个 MQ 中间件混用的局面。
存储方面，Redis+ 阿里云 RDS，在部分大数据量场景做了数据 sharding(sharding-jdbc)。

交易平台化项目上线后，经过后期的不断迭代优化，目前交易平台主要架构图如下：

交易平台化项目遇到的挑战

技术选型只是完成了第一步，在得物交易平台的整个落地过程中还有很多难题需要解决，在金思宇看来主要的挑战有三个：

首先是协调问题，因为只重构了部分核心项目（6 个），而整个交易流程涉及到的上下游很多，所有的上下游系统都需要协调来配合改造升级。据了解，当时涉及到的上下游系统共有 87 个，整个项目的上线及流量切换流程被拆解成了 180+ 个操作步骤，最终才完成上线。

其次是数据异构迁移，由于底层数据模型做了重新设计，原本分散在各个系统内的订单、库存、超时信息等都需要统一转换为新的数据结构，并清洗到新的系统中，同时保证时效，尽可能的降低对线上的影响。当时有 27 亿 + 条数据在此过程中被迁移，采用全量铺底 + 增量追加的方式，在低流量时段停机 40 分钟内完成。

最后是项目周期，整个交易平台的项目周期是 2019 年 12 月 16 日到 2020 年 3 月 16 日。在项目后期，受疫情影响，全体项目成员远程办公，团队沟通，项目效率，提测质量，上下游配合等有较大影响。

整个项目落地之后带来的变化还是很明显的，经统计，得物 App 线上问题数目及客诉数减少了 80% 以上。同时，该项目还在不断迭代优化，目前需求迭代可以保持 1 到 2 周迭代一次，落地成本也明显缩小。

经验总结与分享

历经三个月，得物交易平台五彩石项目成功交付，陈思淼和金思宇全程参与了整个项目的迭代优化过程，并分享了一些经验，与大家共勉。

在项目迭代优化过程中，对原有业务的深入理解很关键，不要否定原有的设计、系统，也不要急于落地新的东西，耐心吃透原有的业务逻辑，会让之后的路顺畅很多。
架构设计是非常重要的，尤其对于一个庞大的重构项目，不但自己要想清楚，还需要明确输出，同步给团队自己的设计思路，同时充分吸收大家的反馈，有选择的进行修正。
越是庞大的项目，越是需要精细化的管理和推进，得物当时选择了小团队日会、全体项目同学双日报、各 TL 周会的方式，及时发现问题并快速推进解决。
相信团队的力量，基本每个项目都不是一个人可以单独完成的，肯定需要团队内、外部的鼎力配合与相互协作，所以相信团队的力量。

采访嘉宾

陈思淼，得物 App CTO & 国际事业部 (POIZON Global) 总经理，负责得物 App 技术搭建、技术架构及团队管理工作。陈思淼具备多年顶级互联网平台和电商平台技术工作经验。此前在阿里工作十一年，先后担任淘宝资深技术专家，商家事业部技术负责人，Lazada CTO，阿里国际中台技术负责人等职务。

金思宇，得物 App 交易平台 & 稳定性平台 Leader，毕业于东北大学，先后在中兴通讯、阿里巴巴、唯品会任职；对电商及上下游有比较丰富的开发及业务架构经验。目前带领团队支撑得物 App 交易平台的需求迭代，完善业务基础能力，同时负责技术部稳定性体系搭建及持续建设。

陈思淼和金思宇将在 2020 年 12 月 20-21 日 QCon 全球软件开发大会（上海站）上分享，介绍得物 App 的业务架构演进过程和技术细节。此外，还有来自百度、腾讯、滴滴的专家来分享各自的经验，精彩别错过！