亿级交易平台:从 0 到 1 设计思路

沙海
沙海
沙海
994
文章
2
评论
2021年4月15日01:12:13
评论
2 6740字阅读22分28秒
摘要

速读摘要

速读摘要

每日优鲜已经完成水果、蔬菜、肉蛋、水产、乳品、零食、速食、饮品、轻食、粮油、日百等全品类布局,通过首创的生鲜到家"前置仓"模式,在中国16个城市为数千万家庭提供"3000款商品,最快30分钟送达"的服务。跟大多数互联网电商一样,随着公司业务的发展,每日优鲜也陆续拓展出了多业务线(极速达、云超、厂家直送、便利购、菜市场等)。后续规划建设交易平台配置中心,统一、动态管理业务配置。陈国民,2017年加入每日优鲜,目前主要从事交易平台建设的相关工作。

原文约 1.1 万 | 图片 17 | 建议阅读 23 分钟 | 评价反馈

亿级交易平台:从 0 到 1 设计思路

芋道源码

以下文章来源于再见伐木机,作者陈国民

亿级交易平台:从 0 到 1 设计思路

再见伐木机

面试经验,技术交流,技术分享

点击上方“芋道源码”,选择“设为星标

管她前浪,还是后浪?

能浪的浪,才是好浪!

每天 8:55 更新文章,每天掉亿点点头发...

源码精品专栏

 

亿级交易平台:从 0 到 1 设计思路

本文主要介绍每日优鲜五年来交易平台实践的心路历程

一、前言

1.1 每日优鲜简介

每日优鲜定位于自营全品类线上综合超市,成立于2014年11月,致力于让每个家庭买得省心,吃的放心。目前,每日优鲜已经完成水果、蔬菜、肉蛋、水产、乳品、零食、速食、饮品、轻食、粮油、日百等全品类布局,通过首创的生鲜到家“前置仓”模式,在中国16个城市为数千万家庭提供“3000款商品,最快30分钟送达”的服务。凭借着上游供应链和智慧连锁核心能力上的长期投入,每日优鲜业务规模已超过百亿。2020年7月,每日优鲜完成由中金资本领投的4.95亿美元融资,在生鲜电商细分领域,市场份额、营收增长、用户规模以及盈利能力均保持行业第一。

1.2 交易平台简介

跟大多数互联网电商一样,随着公司业务的发展,每日优鲜也陆续拓展出了多业务线(极速达、云超、厂家直送、便利购、菜市场等)。各业务线发展初期,为了快速跑通MVP,组建临时团队、从0开始搭建系统,但这就导致烟囱式系统林立、数据相互割裂,不仅成本高企,也为业务整合带来困难,技术架构从烟囱式系统走向平台化架构成为必然选择;对交易系统来说,各业务形态的订单数据模型差异不大、交易业务流程类似,构架一套交易平台来支撑多业务形态的交易业务具有可行性,因此“每日优鲜交易平台”应运而生。目前每日优鲜交易平台拥有数十亿的海量订单数据、能够稳定地支撑公司数十种业务形态、也能够在3天内高效支持新业务的接入。

二、背景

2.1 没有交易平台时面临的困难是什么?

2.1.1 成本高企

各业务团队都有交易系统,重复造轮子,造成运维成本、研发成本的浪费。

2.1.2 数据割裂

各业务团队的订单数据的割裂存储、数据模型的不统一,造成依赖于订单数据的大数据、财务、客服等服务为了适配不同数据模型,冗余了大量的适配逻辑和兼容逻辑,增加了这些系统的复杂度;复杂度的增加,不仅仅是沟通成本、研发成本的增加,也降低了系统稳定性。

2.1.3 业务迭代需求响应慢

交易系统功能定制化,抽象性、扩展性、复用性都较差,需求响应慢,影响业务迭代效率。

2.1.4 创新业务试错成本高

创新项目不能利用现有交易系统,只能组建临时团队,搭建新的交易系统,拉高了试错成本。而较高的试错成本,会阻碍创新项目启动的机会,延误商机。

2.2 交易平台要解决的核心问题是什么?

2.2.1 什么是交易平台?

交易平台是支持多业务形态下的正向、逆向交易流程的一套软件系统。它具有较高的数据模型抽象性、业务功能抽象性,通过对基础功能(能力域)的配置化流程编排,可支持差异化的业务流程,也可快速支持新业务;能够隔离业务间的相互影响,保障多业务平稳运行。

2.2.2 交易平台要解决的核心问题

2.2.2.1 效率问题

如何快速支持业务需求?说到底就是如何抽象数据模型和业务流程,提高系统的扩展性和复用性,包括如下几个面向:

  • 不同业务形态的数据模型的差异如何存储、传递?

  • 不同业务形态的功能的差异如何处理?

  • 不同业务形态、不同类型的订单,业务流程差异如何支持?

  • 如何定义和管理不同业务形态、不同订单类型?

2.2.2.2 稳定问题

如何保障系统平稳运行?包括系统稳定性和业务正确性,具体面向如下:

  • 多业务在一套系统运行,存在相互影响的可能,如何避免?

  • 出现问题如何快速定位?如何确定是哪个业务出了问题?

  • 业务的正确性如何保障?如何快速主动发现问题?有问题的数据如何快速修复?

2.2.2.3 性能问题

作为交易系统,管理海量正向数据、逆向数据的读写,如何满足C端、B端的读写性能要求?具体面向如下:

  • 海量数据怎么存储才能保证读写性能?是否要分库分表?

  • 多维度的复杂查询如何支持?在分库分表情况下,如何支持复杂查询?

  • 读写流量如何避免相互影响?

  • C端、B端流量如何避免相互影响?

2.3 交易平台的价值

2.3.1 降低成本

收敛各业务团队的烟囱式交易系统,降低运维成本、研发成本。

2.3.2 提高效率

高扩展性、高复用性,对内对外大幅提高研发效率。交易平台自身对接新业务需求仅需3天;数据模型的统一,降低大数据、财务等外部关联服务的复杂度,提高的这些关联服务支持新需求的效率。

2.3.3 业务赋能

创新项目可以低成本跑通 MVP,降低试错成本;体现技术驱动业务发展的能力。

2.3.4 标杆系统

交易平台率先完成平台化,对标行业领先;随着交易平台的价值的逐步体现,在公司内部树立标杆形象,促进达成建设平台化架构的共识,引领兄弟部门平台化建设的步伐;最终形成业务中台化,打造全链路的高效、稳定的业务赋能能力。

三、技术实现

3.1 业务架构

交易平台承接各业务前台的交易应用的请求,依赖商品、营销、支付等基础服务,处理各业务形态的正向交易、逆向交易,具体业务包括正向交易、逆向交易、履约分发、订单中心、数据处理、运营工具、公共组件等。

亿级交易平台:从 0 到 1 设计思路

图片

3.2 系统架构

按照功能,交易平台内部系统划分为4层,包括存储层、数据处理层、业务层和应用层。其中业务层按照订单生命周期划分为生单模块、支付模块、履约模块、逆向模块以及查询模块。

亿级交易平台:从 0 到 1 设计思路

图片

3.3 技术保障

3.3.1 差异管理方案

3.3.1.1 业务身份定义

作为平台化架构,定义业务身份是首要任务。业务身份的定义,是用于区分不同业务、不同品类的差异功能,是业务管理单元;需要定义一套合理且具有扩展性的业务身份方便业务管理。基于业务场景,我们使用3个维度定义业务身份:

  • 业务线:区分不同运营团队所运营的业务,比如主商城、便利购、开放平台等

  • 渠道:同一个业务线,有不同的流量渠道,比如便利购业务下有普通柜、智能柜等

  • 订单类型:根据商品类型、履约形态的不同,定义不同的订单类型,比如极速达订单、云超订单等

亿级交易平台:从 0 到 1 设计思路

图片

3.3.2 扩展性方案

3.3.2.1 数据模型扩展

订单数据模型,除了通用的买家信息、卖家信息、商品信息、支付信息、买家履约信息(支付信息)、卖家履约信息等基本信息之外,不同业务形态的订单还有差异化的数据需要存储和传递。我们的解决方案是通用信息结构化存储+差异信息JSON存储,具体如下:

  • 通用信息:通用信息结构化存储

  • 差异信息:服务间传递、存储用JSON格式, 后续处理由业务自定义逻辑处理,与通用逻辑解耦

  • 金额类信息:预期到有频繁的扩展需求,金额类型和金额值采用KV结构化存储,提高可扩展性

  • 亿级交易平台:从 0 到 1 设计思路

    图片

3.3.2.2 业务功能扩展

支持多业务问题本质上是业务功能如何抽象的问题,而差异逻辑处理则是在抽象通用基础能力的基础上,如何在部分处理环节支持差异性逻辑。我们采用的是抽象通用能力+预留扩展点的方式,具体如下:

  • 抽象通用能力:调研业务场景,对功能进行统一抽象,形成业务通用能力域,方便多业务复用

  • 预留扩展点:在通用能力域中针对可能存在差异地方预留扩展点,方便差异逻辑的实现;差异逻辑可通过配置化解决,也可用差异化代码实现。

亿级交易平台:从 0 到 1 设计思路

图片

3.3.2.3 业务流程扩展

差异化流程的本质是串联能力节点形成业务流程,信息可在能力节点之间传递。我们采用流程编排+标准上下文的方式实现,具体如下:

  • 流程编排:我们团队自研流程引擎ark-maze组件,进行业务流程编排

  • 标准上下文:流程节点之间数据通过上下文传递,定义业务流程通用的上下文结构

流程引擎ark-maze组件,以“责任链”模式来组织复杂处理流程的执行过程,保障服务节点能够按照顺序执行,并且能够传递执行结果;发生异常可逆序进行回滚操作;支持节点的串行、并行执行。ark-maze组件架构图如下:

亿级交易平台:从 0 到 1 设计思路

图片

3.3.3 稳定性方案

3.3.3.1 服务隔离

一套系统支持多个业务形态,导致业务间相互影响的原因如下:

  • 应用资源相互影响:某业务占用资源过多,影响其它业务

  • 存储相互影响:共享存储,导致业务间相互影响 我们采用多级别隔离机制,具体如下:

  • 线程池隔离:我们的分布式服务框架采用的是阿里开源框架dubbo,不同业务使用不同的dubbo的group,达到dubbo线程池的隔离,避免多业务争抢线程池的情况。

  • 服务器隔离:服务器按业务线分组独立部署,不同业务请求路由到相应的服务器集群。基于业务线配置不同profile文件,服务器按profile分组部署,不同的proflie注册不同group的dubbo服务,dubbo消费者使用不同group的服务。

  • 存储隔离:使用分库策略,不同业务数据路由到不同数据库集群。权衡业务流程规模、系统复杂度、运维成本,目前每日优鲜在【线程池隔离】级别。

亿级交易平台:从 0 到 1 设计思路

图片

3.3.3.2 分业务监控

多业务监控本质上是在原有监控指标增加业务维度即可,相关监控指标包括:应用指标:异常日志、调用量等;业务指标:下单数、支付数、取消数等;

亿级交易平台:从 0 到 1 设计思路

图片

3.3.3.3 业务保障系统

如何保障多业务正常运行?其本质就是如何快速发现问题,并且具有一定的自动修复的能力。我们搭建了业务保障平台,实时地发现业务数据的一致性和正确性问题,某些异常场景能做到自动修复,如果不能自动修复,第一时间报警给相关负责人。业务保障平台通过事件触发执行校验规则,规则支持自定义脚本和自定义api接口。

3.3.4 高性能方案

3.3.4.1 存储高性能

作为交易系统,存储海量订单数据,对外提供高可用、高性能的读写服务是必须要支持的。为了保障高可用、高性能,我们采用如下方案:

  • 分库分表:为了解决单库单表的存储上限和并发处理上限的问题,我们在设计初期以当时预估的5年内的订单规模,设计为N个分库N个分表。以订单号后N位取模作为分库分表的路由规则。

  • 读写分离:Mysql集群采用1主+1备+N从的高可用架构。写流量走主库,主库配置备库,保障高可用;读流量走从库,有实时性要求的读流量也走主库,由上游应用根据业务场景来决定;B端、C端读流量分离,避免B端流量影响C端用户流量。

  • ES搜索引擎:Mysql采用分库分表的方案,导致Mysql不能提供多表联合查询和多维度的复杂查询,采用其他搜索引擎提供复杂查询能力成为必然。我们采用分布式文档数据库Elasticsearch搜索引擎。监听Mysql数据库的binlog实时同步增量异构数据到Elasticsearch。为了保障ES集群的高可用,搭建2套ES集群作为互备,也能做到B端、C端流量的分离;Mysql数据同步ES有秒级的延迟,有实时性要求的C端流量不走ES,只能走Mysql主库查询,例如:待支付订单列表页查询Mysql,而其它实时性要求不高的或者用户无需感知实时状态的订单列表页(如:待配送、配送中的订单列表页)查询ES。

3.3.4.2 流程异步化

非核心业务处理如果混杂在核心链路中,影响核心流程的性能和稳定性。非核心处理剥离出来,异步化处理,提高整体的性能和稳定性。以订单取消流程为例:

亿级交易平台:从 0 到 1 设计思路

图片

3.3.5 一致性方案

3.3.5.1 最终一致性事务框架miss-tfc

通常在核心业务流程中存在发送MQ,发起RPC调用第三方、刷新ES等场景,如:在生单流程中,需要在保存数据库后发送一条MQ消息。而以上这些场景是需要保证一定要执行的。当机器遇到宕机这类故障后,这些任务则有几率不会被执行。为了解决以上问题,通常的做法是每个业务写一个任务表定期执行;但是这样做带来的问题是巨多的任务表,维护和操作也不方便,重复的操作逻辑也会散落在各个业务处理中。我们团队miss-tfc框架则是为了解决以上问题而生的,它会把需要执行的任务持久化到数据库中,然后不断的重试补偿动作,直到任务处理成功。架构原理:通过拦截器配置指定类的指定方法保存起来镜像存储到任务表,并且与当前业务的写库事务绑定在一个事务中。等事务提交后,可以选择性的配置实时当前同步线程做、实时异步线程做、异步调度做等。

3.3.6 灰度方案

3.3.6.1 增量数据双向同步

交易平台收敛原来的各业务团队的烟囱式老交易系统,涉及读写流量的平滑切换处理,我们采用【灰度写流量->写全量->灰度读流量->读全量->老系统下线 】的方案。在这个过程中,考虑到用户列表等业务场景需要全量订单数据的情况,新老数据库都需要持有全量订单数据,我们用【增量数据双向同步】机制来保障。增量数据双向同步:交易平台的增量数据同步到老订单数据库,老订单系统的增量数据同步到交易平台数据库,使新老订单库同时保有全量订单数据。

亿级交易平台:从 0 到 1 设计思路

图片

四、踩过的坑

4.1 过度设计

4.1.1 过早的服务器隔离

在各业务形态流量规模还没有到影响稳定性的情况下,过早的以业务线维度部署服务器达到所谓的服务器隔离的级别,导致了测试机器、生产机器的成本浪费,同时也增加了测试的复杂度和成本。

  • 解决方案:隔离级别从服务器隔离 降为 线程池隔离

4.2 依赖组件

4.2.1 核心链路依赖开源组件

订单状态的流转,我们采用了消息驱动的方案;为了与业务代码解耦,消息是用阿里开源的数据库同步系统otter监听数据库订单表的binlog来发出的。支付成功后的履约分发等核心链路也依赖这种消息驱动;某次网络问题导致otter消息阻塞,造成近30分钟的订单不能履约的故障。开源组件本身的设计不足、或者对开源组件没有完全掌握,遇到问题不能快速定位、快速解决,都是稳定性不可控的因素。

  • 解决方案:痛定思痛,我们从核心链路彻底去掉开源组件otter,自研一致性组件miss-tfc,详细参考【3.3.5.1 最终一致性事务框架miss-tfc】;针对自研组件,我们有更大的热情、更强的自主性进行长期地维护、推广和完善。

五、未来展望

经过了2年多的持续建设,目前交易平台能够高效、稳定地支撑公司业务的快速发展,但还是存在一些功能需要持续完善。

5.1 业务参数动态配置化

目前业务参数配置较为混乱,在系统配置文件(yml文件)、分布式配置中心(missconf)都有,静态、动态的区分混乱,导致管理成本高。后续规划建设交易平台配置中心,统一、动态管理业务配置。

5.2 流程编排可视化

搭建业务流程管理中心,能力地图、流程编排可视化展示,流程编排可动态生效。

5.3 订单全链路监控

建立基于订单生命周期全链路的数据流,实时跟踪订单各个环节的处理状态,并将作业数据可视化;有效防止订单流转失败、漏单、超卖等其他系统异常和业务异常情况;掌握各系统作业效率,帮助内部效率提升。

六、总结

在每日优鲜交易平台建设过程中,我们借鉴行业最佳实践,也踩过大大小小的坑,探索并形成了自己的平台化架构建设的方法论,希望对大家有一些启发;同时也欢迎大家来件一起探讨。

作者简介

  • 陈国民,2017年加入每日优鲜,目前主要从事交易平台建设的相关工作。邮箱:chengm@missfresh.cn

  • 感谢芋艿的表弟苏磊(公众号:?再见伐木鸡?)、张祖瑞对本文的指正。

  • 感谢晋冰、陈思彤对本文的指导。

欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢

亿级交易平台:从 0 到 1 设计思路

已在知识星球更新源码解析如下:

亿级交易平台:从 0 到 1 设计思路

亿级交易平台:从 0 到 1 设计思路

亿级交易平台:从 0 到 1 设计思路

亿级交易平台:从 0 到 1 设计思路

最近更新《芋道 SpringBoot 2.X 入门》系列,已经 20 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。

获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。

文章有帮助的话,在看,转发吧。谢谢支持哟 (*^__^*)

阅读原文

继续阅读
weinxin
资源分享QQ群
本站是一个IT技术分享社区, 会经常分享资源和教程; 分享的时代, 请别再沉默!
沙海
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: