其他分享
首页 > 其他分享> > [转]有赞的交易系统架构困局以及破局之道

[转]有赞的交易系统架构困局以及破局之道

作者:互联网

在开始下面的话题之前,我们先看一看有赞原有的核心交易架构。

640?wx_fmt=png

初步看去,这套架构方案似乎看不出什么问题。事实情况也这样,我们做这套交易方案支持了日百万级的交易规模,取得了很不错的成果。

在2016年,公司经历了飞速的成长, 整体团队人员扩张了数倍, 公司整体业务线从单一的微商城电商交易型态扩张到支持多个垂直行业。交易团队也碰到了很多尴尬的情况:

 

我们的困难根源

 

在此之前,我们先看一看公司对于交易团队的要求,以及业务团队对于交易能力的诉求。

640?wx_fmt=png

从上图中,可以看到,从业务团队的视角上来看,交易能力,其实是一种云化能力。不管是什么样的业务场景,只要交易场景存在,那么交易能力就应该能覆盖。换句话说,交易团队存在的价值,就是”能够很快速地支持所有业务的交易“。

这个时候稍微清晰了一点当前的困难的原因:原来的我们,一直是在做微商城的业务,认为”微商城的业务规则=交易的能力“。这个定位与垂直业务的期望很不匹配。

既然”微商城的交易规则“不等于”交易能力“,那么交易能力是什么? 有什么内容?与垂直业务又有什么关系?

这三个是很有意思的问题。 在弄明白这三个问题之前,我们先把我们从一个互联网从业者的角色,转变成一个普通的人。假设我们要去做三件事情,我们看一看现实生活的交易细节:

上面例子,都很平常。但是平常的事情,蕴含着几千年的交易规律。我们仔细品味一下上面的细节,发现从大到小的交易,有几个共同的点:

从理论上来说, 线上系统处理的也是真实世界的问题, 只是手段略有不同。我们再回顾一下自己平常碰到过的交易场景,都逃不出这个范畴。 我们完全有理由把这个结论当成线上交易系统的指导思想。我们对于交易系统的抽象理解就是: 交易的本质是:买卖双方就付款细节/交货细节/商品质量细节/赔偿细节,先签定一个契约。而后双方履行契约的全过程。订单仅仅表示双方履约的过程和凭证。

我们看一下新交易的最骨干的模型。

640?wx_fmt=png

 

破局之道

 

搞明白了我们的核心问题, 那么很多事情就迎刃而解了。

要根治交易系统当前碰到的困局,除了重构之外,没有别的捷径可走。

 

架构演进

 

在进行本章节的讲解之前,我们再回顾一下,上面讲的三个生活中的交易场景,我们继续仔细品味一下,三个交易场景的细节点,突然有了一个惊人的发现:

弄明白这些特性,直接决定了,我们跟垂直行业的关系。即:什么东西应该交给垂直行业,什么东西,交易系统应该搞定。

以下的新交易的架构大图:

640?wx_fmt=png

在上图中,明显出现了几个原来没有出现过的一些名词。我们做一下解释:

buy: 业务的buy,由垂直业务掌控,它不一定是一个独立系统, 它的核心使命是包装交易平台提供的各种能力,根据垂直业务规则,做定制。例如,美业的理发业务调用下单接口的时候,可能要做预约时间的选择,buy系统需要做一下这方面的校验与参数拼装。另外,垂直业务的交易确认页面,也是有不同的显示规则,这个需要buy系统做支持。

流程编排引擎:这个是整个新交易的核心思想。业务规则是通过配置化形成的。流程配置化的最小颗粒度是组件。引擎把所有的组件形成一个串,执行业务规则。流程编排引擎的配置规则,是DB中的数据,可以随时添加数据。 所以这个引擎的设计,对于快速支持新的业务形态,起了至关重要的作用。

交货/退货路由引擎:对于交易系统来说,所有的交货/退货过程,都可以看成黑盒子。只要知道路由引擎会把相应的交货过程做掉就可以的。原因是:我们认为交货是一个不可归纳的行为。交货的细节,是需要交还给垂直业务自己去做的。

组件:对于流程中所有元素来说, 所有的东西都是组件,都可以纳入到流程编排的范围之内。如:扣库存组件,校验用户合法性组件,校验地址可达性组件,进入支付组件等等。

对于上面的解释,可能还有三个问题核心未回答:

1. 既然是通过流程编排来配置出一个业务流程,那么,如何定位到一个业务?

2. 交易的核心流程阶段与主模型数据模拟是怎么样的?

640?wx_fmt=png

  1. 横向业务与垂直业务

  2. 垂直业务:垂直业务就是我们要支持的业务场景,如“微商城的普通商品拼团的业务”。

  3. 横向业务:各种横向业务通过一定规则相互拼装,可以形成垂直业务。在新交易里,横向业务被包装成一个一个的组件,可以通过流程编排的形式串成垂直业务。如:拼团组件。

 

实施路径

 

交易是非常核心的系统,新交易系统的上线流程,无异于飞行中换发动机,难度可想而知。我们把实施路径定为以下几个阶段:

1. 正向交易优先启动重构,用新的模型做业务支持。

2. 订单管理启动重构,在正向交易做完全量切流程之后,再做灰度上线。

订单管理的同步策略,不再依赖DB做数据的导出/查询业务的存储介质。采用宽表的一些介质,做到dump可配置化,导出可配置化。通过这样的方式,一次性丢弃老的数据模型,同时获到业务配置化能力。如ES、HBase。

3. 逆向交易启动重构, 在正向交易做完全量切流程之后,再做灰度上线。 遵循逆向交易流程配置化的原则。

4. 等到逆向交易与订单管理做完全量分流之后, 再停用双写策略(原有的老模型自然全量失效)。

标签:有赞,交货,流程,业务,垂直,困局,付钱,交易,破局
来源: https://blog.csdn.net/linchare/article/details/117133842