业务百倍增长,得物如何在三个月完成交易平台重构?
业务百倍增长,得物如何在三个月完成交易平台重构? https://mp.weixin.qq.com/s/DqGdR7Awp0P66cQzYAOutw
作者 | 田晓旭嘉宾 | 陈思淼、金思宇得物 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。
-
同步内部通讯选择了 Feign;注册中心采用 Consul,配置中心选择了相对友好的 Apollo;
-
异步通讯统一选择了 RocketMQ,结束了原有多个 MQ 中间件混用的局面。
-
存储方面,Redis+ 阿里云 RDS,在部分大数据量场景做了数据 sharding(sharding-jdbc)。
交易平台化项目上线后,经过后期的不断迭代优化,目前交易平台主要架构图如下:
4交易平台化项目遇到的挑战
技术选型只是完成了第一步,在得物交易平台的整个落地过程中还有很多难题需要解决,在金思宇看来主要的挑战有三个:
首先是协调问题,因为只重构了部分核心项目(6 个),而整个交易流程涉及到的上下游很多,所有的上下游系统都需要协调来配合改造升级。据了解,当时涉及到的上下游系统共有 87 个,整个项目的上线及流量切换流程被拆解成了 180+ 个操作步骤,最终才完成上线。
其次是数据异构迁移,由于底层数据模型做了重新设计,原本分散在各个系统内的订单、库存、超时信息等都需要统一转换为新的数据结构,并清洗到新的系统中,同时保证时效,尽可能的降低对线上的影响。当时有 27 亿 + 条数据在此过程中被迁移,采用全量铺底 + 增量追加的方式,在低流量时段停机 40 分钟内完成。
最后是项目周期,整个交易平台的项目周期是 2019 年 12 月 16 日到 2020 年 3 月 16 日。在项目后期,受疫情影响,全体项目成员远程办公,团队沟通,项目效率,提测质量,上下游配合等有较大影响。
整个项目落地之后带来的变化还是很明显的,经统计,得物 App 线上问题数目及客诉数减少了 80% 以上。同时,该项目还在不断迭代优化,目前需求迭代可以保持 1 到 2 周迭代一次,落地成本也明显缩小。
5经验总结与分享
历经三个月,得物交易平台五彩石项目成功交付,陈思淼和金思宇全程参与了整个项目的迭代优化过程,并分享了一些经验,与大家共勉。
-
在项目迭代优化过程中,对原有业务的深入理解很关键,不要否定原有的设计、系统,也不要急于落地新的东西,耐心吃透原有的业务逻辑,会让之后的路顺畅很多。
-
架构设计是非常重要的,尤其对于一个庞大的重构项目,不但自己要想清楚,还需要明确输出,同步给团队自己的设计思路,同时充分吸收大家的反馈,有选择的进行修正。
-
越是庞大的项目,越是需要精细化的管理和推进,得物当时选择了小团队日会、全体项目同学双日报、各 TL 周会的方式,及时发现问题并快速推进解决。
-
相信团队的力量,基本每个项目都不是一个人可以单独完成的,肯定需要团队内、外部的鼎力配合与相互协作,所以相信团队的力量。
采访嘉宾
陈思淼,得物 App CTO & 国际事业部 (POIZON Global) 总经理,负责得物 App 技术搭建、技术架构及团队管理工作。陈思淼具备多年顶级互联网平台和电商平台技术工作经验。此前在阿里工作十一年,先后担任淘宝资深技术专家,商家事业部技术负责人,Lazada CTO,阿里国际中台技术负责人等职务。
金思宇,得物 App 交易平台 & 稳定性平台 Leader,毕业于东北大学,先后在中兴通讯、阿里巴巴、唯品会任职;对电商及上下游有比较丰富的开发及业务架构经验。目前带领团队支撑得物 App 交易平台的需求迭代,完善业务基础能力,同时负责技术部稳定性体系搭建及持续建设。