原标题：以物换物实体店（以物换物实体店怎么盈利）

以物换物创业简介（以物换物实体店）

以物换物实体店

获取内容App专注于打造新一代潮流网购社区。截至目前，App平台80%以上的用户都是90后出生的。随着品牌升级和业务增长，相应的业务架构和技术体系需要更新迭代。

2021年3月16日，吴德技术团队在三个月内完成了整个交易系统的改造，交付交易平台项目——彩石项目。整个项目重新设计了6个核心交易应用，完成了180项操作，重新发布了21个系统。相应的优化迭代也涵盖了社区、交易、供应链的解耦，交易平台化的演进，底层交互协议的更新，全链路压力测试的落地。为了了解彩石项目的整个建设过程，InfoQ采访了Get Things App CTO陈思邈、交易平台及稳定平台负责人金。

电商平台业务架构的发展

电子商务起源于1990年，经历了30年的发展。现在电子商务平台已经成为主流的购物方式之一。从业务架构来看，中国电商平台经历了几个发展阶段？基于各自的工作经验，陈思邈和金表示，中国电商平台的业务架构经历了四个类似的阶段。

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

第二阶段：随着业务规模的逐渐增大，团队数量不断增加，整个平台的维护难度不断增加，耦合严重，性能瓶颈逐渐显现。此时系统会进行拆分，从业务域、基础服务、前端分离的角度慢慢拆分，拆分后的系统会进行通信(同步/异步)。

第三阶段：分布式服务。系统拆分后，每个服务将有多个团队负责，职责明确。但是，服务之间的通信越来越多，依赖关系也越来越复杂，甚至配套业务量也会更大。此时，对服务治理、监控、缓存、数据分片和分布式事务等基础设施的要求会更高。

第四阶段：随着业务的发展，在分布式服务的基础上，对服务稳定性和高可用性提出了更高的要求。淘系单元化、异地居住后，这基本成为很多电商甚至外卖平台追求的统一理念；集装箱化流行后，基于集装箱化和混合云(异地多活动)的灵活资源管理成为另一种趋势。

与其他平台相比，电商平台在数据准确性、一致性、安全性、服务性能和服务稳定性等方面都有更高的要求，一旦出现问题就容易被放大

因此，在做电商平台的系统设计和落地时，要重点关注以下几个方面：

是否在核心环节上，对于电商平台来说，交易浏览环节和订单支付环节(包括优惠活动优惠券)属于核心环节，需要评估申请是否会影响核心环节，属于强依赖还是弱依赖；容量评估，包括峰值QPS和每日数据量，以确认是否应引入缓存，数据库选择(MySQL/TiDB)，数据应硬化，并应配置电流限制。绩效评估，包括上下游依赖，对业务流程的影响，交互是同步还是异步，对整体RT的影响；对于核心环节上的服务，上线前会进行测试评估；对数据稳定性的影响，包括对原数据库表索引的影响、对原数据字段的影响、对上下游数据一致性的影响。

ss="pgc-h-arrow-right">得物交易平台的差异与发展

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

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

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

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

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

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

在这种情况下，得物 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 分钟内完成。

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

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

经验总结与分享

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

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

采访嘉宾

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

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

延伸阅读：

给世界多一个操作系统的选择，openEuler的开源故事-InfoQ

关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书，点击文末「了解更多」，即可移步InfoQ官网，获取最新资讯～

以物换物创业