有赞的交易系统架构困局以及破局之道
在开始下面的话题之前，我们先看一看有赞原有的核心交易架构。
初步看去，这套架构方案似乎看不出什么问题。事实情况也这样，我们做这套交易方案支持了日百万级的交易规模，取得了很不错的成果。
在2016年，公司经历了飞速的成长， 整体团队人员扩张了数倍， 公司整体业务线从单一的微商城电商交易型态扩张到支持多个垂直行业。交易团队也碰到了很多尴尬的情况：
垂直行业接入交易很困难，交易团队对于业务团队的支撑响应速度赶不上业务的迭代速度，最后垂直行业被迫自己完全重做了一套针对垂直业务的交易系统。比如：商业化服务订购，收营，批发等业务。浪费了公司宝贵的技术资源。
交易团队的新同学，上手交易核心的开发非常困难，在没有完合弄懂整套系统之间，不敢放手让新同学开发。学习成本极高。
很多的玩法不能进行组合，如果想进行组合，必须要求进行重新编码，把组合的方案当做一个新方案来做。比如：虚拟商品的拼团业务， 酒店的分销业务，等等， 都不能用很简单的方案做支持。 产品运营同学的创造性想法，得不到很快的支持。
上线了一个小需求，导致的主流的核心交易大面积出现故障。影响范围不能进行隔离。
我们的困难根源
在此之前，我们先看一看公司对于交易团队的要求，以及业务团队对于交易能力的诉求。
从上图中，可以看到，从业务团队的视角上来看，交易能力，其实是一种云化能力。不管是什么样的业务场景，只要交易场景存在，那么交易能力就应该能覆盖。换句话说，交易团队存在的价值，就是”能够很快速地支持所有业务的交易“。
这个时候稍微清晰了一点当前的困难的原因：原来的我们，一直是在做微商城的业务，认为”微商城的业务规则=交易的能力“。这个定位与垂直业务的期望很不匹配。
既然”微商城的交易规则“不等于”交易能力“，那么交易能力是什么？ 有什么内容？与垂直业务又有什么关系？
这三个是很有意思的问题。 在弄明白这三个问题之前，我们先把我们从一个互联网从业者的角色，转变成一个普通的人。假设我们要去做三件事情，我们看一看现实生活的交易细节：
我要去路边摊买一斤瓜子。
“老板，多少钱一斤瓜子” 。“12元一斤奶油的” 。“给我称一斤”。 然后老板给我称了一斤，我付钱， 拿瓜子，走人。
我要去楼下吃一碗面。
“老板，热干面多少钱一碗” 。“15元一碗”。“给我来一碗” 。然后我坐下， 吃完面，付钱， 走人。
我要去售楼处，买一套期房。
这个场景就更复杂了，我需要先看房周边的环境，看价格，然后弄清楚开发商的承诺， 然后，找售楼小姐聊价格，拿合同，签字， 付现金首付，然后找银行贷款付完余下的钱。 待房子开发完之后，再找开发商确认收房。最后整个交易才算完毕。（PS：如果房子跟原来说的面积不一致，还需要补款。如果差距太大，还要房闹退款等）。
上面例子，都很平常。但是平常的事情，蕴含着几千年的交易规律。我们仔细品味一下上面的细节，发现从大到小的交易，有几个共同的点：
交易必须有买卖双方。
在初期，买卖双方必须达成一致（如何付钱，如何交货）。达不成一致，就不存在交易。（契约）
达到一致之后，买方付钱，卖家交货。PS：可能是先交货，再付钱。也可能是多次付钱。也可能是多次交货。
只有买卖双方达不成一致，才存在交易退款维权的情况，包括售后服务。
从理论上来说， 线上系统处理的也是真实世界的问题， 只是手段略有不同。我们再回顾一下自己平常碰到过的交易场景，都逃不出这个范畴。 我们完全有理由把这个结论当成线上交易系统的指导思想。我们对于交易系统的抽象理解就是： 交易的本质是：买卖双方就付款细节／交货细节／商品质量细节／赔偿细节，先签定一个契约。而后双方履行契约的全过程。订单仅仅表示双方履约的过程和凭证。
我们看一下新交易的最骨干的模型。
破局之道
搞明白了我们的核心问题， 那么很多事情就迎刃而解了。
快速接入问题：如果我们的交易核心是稳定的，不是给某个业务定制的，那么只要是契约精神可以解决的问题，就应该是交易系统能解决的问题。业务系统只需要做一些适配，就可以无缝接入。接入速度会极大提升。
搞定小需求，影响主流交易的问题：这个是原系统在代码组织层面，只要做好隔离，就可以解决的。
新人学习成本高的问题： 同理，交易的核心是稳定的，不需要关心太多的业务上的问题，理解成本就会极大的降低。新人接手速度会提升。
玩法不能组合的问题：这个问题同样是原设计上的一些缺陷，没有区分横向业务，跟垂直交易。PS：这个会在后面阐述。
要根治交易系统当前碰到的困局，除了重构之外，没有别的捷径可走。
架构演进
在进行本章节的讲解之前，我们再回顾一下，上面讲的三个生活中的交易场景，我们继续仔细品味一下，三个交易场景的细节点，突然有了一个惊人的发现：
如何付钱是标准化程度很高。在日常生活中，付现金／刷卡／三方支付， 可以覆盖大部分的场景。
跟卖家商量，签定契约的过程，标准化程度稍低点。但是，似乎一个行业一个标准。但是都没有逃出，“如何付钱，如何交货，售后保障约束，以及如何违约赔付”的范畴。
如何交货，是标准化程度是最低的。每个场景似乎都不一样。就算是同样行业的不同的店也可能略有不同。PS：比如一顿饭，可以上门吃然后饭馆准备餐具，也可以是送货上门自己吃。
整条交易的流程，是最不可控的，每个阶段的过程，可能是乱序的。PS：比如去餐馆吃饭，可能先付钱再吃饭，也可能是先吃饭再付钱。
弄明白这些特性，直接决定了，我们跟垂直行业的关系。即：什么东西应该交给垂直行业，什么东西，交易系统应该搞定。
以下的新交易的架构大图：
在上图中，明显出现了几个原来没有出现过的一些名词。我们做一下解释：
buy: 业务的buy，由垂直业务掌控，它不一定是一个独立系统, 它的核心使命是包装交易平台提供的各种能力，根据垂直业务规则，做定制。例如，美业的理发业务调用下单接口的时候，可能要做预约时间的选择，buy系统需要做一下这方面的校验与参数拼装。另外，垂直业务的交易确认页面，也是有不同的显示规则，这个需要buy系统做支持。
流程编排引擎：这个是整个新交易的核心思想。业务规则是通过配置化形成的。流程配置化的最小颗粒度是组件。引擎把所有的组件形成一个串，执行业务规则。流程编排引擎的配置规则，是DB中的数据，可以随时添加数据。 所以这个引擎的设计，对于快速支持新的业务形态，起了至关重要的作用。
交货/退货路由引擎：对于交易系统来说，所有的交货/退货过程，都可以看成黑盒子。只要知道路由引擎会把相应的交货过程做掉就可以的。原因是：我们认为交货是一个不可归纳的行为。交货的细节，是需要交还给垂直业务自己去做的。
组件：对于流程中所有元素来说， 所有的东西都是组件，都可以纳入到流程编排的范围之内。如：扣库存组件，校验用户合法性组件，校验地址可达性组件，进入支付组件等等。
对于上面的解释，可能还有三个问题核心未回答：
1. 既然是通过流程编排来配置出一个业务流程，那么，如何定位到一个业务？
行业维度（酒店预订，普通实物交易，外卖，虚拟交易，批发，美业等）
商品类型维度（酒店商品，普通实物商品，会员卡商品，二维码核销商品等等）
营销维度（积分商城，拼团，秒杀，老拼团，普通营销/无营销，等）
交货方式维度（上门自提，快递，同城送，二维码核销，酒店入住，会员卡授权等）
付款方式维度（线上付，代付，货到付款，线下收银等）
2. 交易的核心流程阶段与主模型数据模拟是怎么样的？
横向业务与垂直业务
垂直业务：垂直业务就是我们要支持的业务场景，如“微商城的普通商品拼团的业务”。
横向业务：各种横向业务通过一定规则相互拼装，可以形成垂直业务。在新交易里，横向业务被包装成一个一个的组件，可以通过流程编排的形式串成垂直业务。如：拼团组件。
实施路径
交易是非常核心的系统，新交易系统的上线流程，无异于飞行中换发动机，难度可想而知。我们把实施路径定为以下几个阶段：
1. 正向交易优先启动重构，用新的模型做业务支持。
正向交易实行双写策略，即新模型写一份，再同步写到老模型数据一份。为了不影响外围系统。
上线时，优先灰度内部商户，而后小商户，最后大商户的原则。
上线后，通知外围业务，做消息机制的改造。
优先支持新业务，然后灰度老业务的原则。
2. 订单管理启动重构，在正向交易做完全量切流程之后，再做灰度上线。
订单管理的同步策略，不再依赖DB做数据的导出/查询业务的存储介质。采用宽表的一些介质，做到dump可配置化，导出可配置化。通过这样的方式，一次性丢弃老的数据模型，同时获到业务配置化能力。如ES、HBase。
3. 逆向交易启动重构， 在正向交易做完全量切流程之后，再做灰度上线。遵循逆向交易流程配置化的原则。
4. 等到逆向交易与订单管理做完全量分流之后， 再停用双写策略（原有的老模型自然全量失效）。
有赞的交易系统架构困局以及破局之道相关推荐
- 数字时代，中国1436家农商行的业务困局和破局之道
引言 金融客户,应该算是中国toB市场最优质的客户.因此,为这类客户服务的供应商也特别多,其中既有各种国际巨头IOE.MBB.四大--,它们把这里视为自己的利润主战场:也有N多本土化的服务商,想进来分 ...
- 【SC17观察】美国丹佛现场直击SC17 探寻计算力增长的困局和破局
作为拥有30年历史的全球最大超算会议,今年的SC17放在了美国丹佛举办,来自117个国家和地区的超过10000参会,同时吸引了334家厂商参展,均创下大会历年最高纪录. 这也是笔者第二年参加SC大会, ...
- 致远互联：以数智化指引破局之道
编辑 | 阿冒 设计 | 沐由 "局必方正,象地则也.道必正直,神明德也.棋有白黑,阴阳分也.骈罗列布,效天文也."在<弈旨>一书中,汉代著名史学家和文学家班固曾 ...
- 聊聊互联网行业对35岁码农的偏见，以及大龄码农的破局之道
目录 市场对35岁以上的程序员是否有就业偏见? 为什么会出现对35岁程序员的一些偏见呢? 程序员35岁的破局之道 大家好,今天给大家聊聊目前程序员就业市场上普遍对所谓的35岁码农的偏见问题,以及对于大 ...
- 研发效率破局之道-学习思考
最近公司研发效率有下降的趋势,在学习了极客时间 <研发效率破局之道>之后 有一些思考 效率 站在公司业务领导,或者老板角度看,效率就是最少的人干最多的活,如果领导外行,那么下属就会增加工时 ...
- 前端内卷加速破局之道
什么是内卷?罗振宇有这样一个比喻,江湖中有一本葵花宝典(比如vue3源码),大家都想得到它,因为得到之后,可以天下无敌!但如果有一天,葵花宝典被公开了(vue3源码教程),人人都有机会练,这是好事还是 ...
- 行业观察｜车企数字化营销破局之道
栏目语 随着数字化浪潮不断向前涌进,企业正面临前所未有的历史机遇与挑战.面向"数据定义未来"的新时代,如何数字化转型成为各行各业的关注焦点. 数澜科技开设「数智观察」栏目,聚焦企业 ...
- 城市大脑是成局还是破局？道翰天琼认知智能机器人平台API接口大脑为您揭秘。
城市大脑是成局还是破局?道翰天琼认知智能机器人平台API接口大脑为您揭秘. 在智慧城市的建设大潮中,大数据.云计算.人工智能等新一代信息技术交错纵横,在不断地融合创新中"城市大脑" ...
- 图灵直播——听胡阳老师和大家聊聊《Python Web开发者的破局之道》
Quora联合创始人Adam D"Angelo在Quora开发中选择Python时所说, 到目前为止,我们对这一选择感到非常满意...所有在过去一直使用其他语言的早期员工都乐意转换到Pyth ...
最新文章
- DTS增量/同步支持DDL迁移的说明
- cnocr训练_cnocr: 极简的中文OCR Python包
- python27安装教程-Python2和Python3安装教程
- [Windows]ping itsafe环境变量
- linux 命令02
- 11_拼接与拆分,cat,stack,split,chunk
- 使用脚本在Linux服务器上自动安装Kubernetes的包管理器Helm
- 解决npm 的 shasum check failed for错误
- java开源图像处理ku_83 项开源视觉 SLAM 方案够你用了吗？
- gdiplus拼接两张图片_深色模式下的图片变暗问题，解决了！
- bzoj 3261 最大异或和【可持久化trie】
- C语言入门1（devC的安装）
- 中国私有云发展调查报告（2018年）
- POP3、SMTP和IMAP 协议
- 摄影文件服务器,服务器和摄影摄像设备招标文件.pdf
- 【2023 · CANN训练营第一季】晟腾AI入门课（TensorFlow）第一章 晟腾AI基础知识介绍
- OpenModelica仿真RLC电路
- 高空核爆与雷电电磁脉冲特征及能量吸收技术（摘要）
- ABI and ISA
- Oracle Windows ODBC 数据源配置