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

嘉宾 | 陈思淼、金思宇

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

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

1 电商平台业务架构的发展

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

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

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

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

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

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

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

是否在核心链路上，对于电商平台，交易浏览链路及下单 & 支付链路 (包含优惠活动 & 券) 属于核心链路，需要评估应用是否会对核心链路造成影响，以及属于强依赖还是弱依赖;

容量评估，包括峰值 QPS、每日产生的数据量，进而确认是否需要引入缓存、DB 选型(MySQL/TiDB)、数据是否需要 sharding、是否需要配置限流等;

性能评估，包括上下游依赖、对业务流程的影响、交互采用同步还是异步、对整体 RT 的影响等;对于核心链路上的服务，会在上线前做压测评估;

对数据稳定性的影响，包括对原有库表 & 索引的影响、对原有数据字段的影响、上下游数据一致性影响等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

采用了基础架构团队基于 SpringCloud 全家桶封装了一套脚手架 Fusion，同时加入了 prometheus 监控埋点，而内嵌的 Web 容器选择了相较于 Tomcat 性能更好的 undertow。