交易中台架构设计:海量并发高扩展,新业务秒级接入

本文根据孙玄老师在〖deeplus直播第219期〗线上分享演讲内容整理而成。


孙玄

奈学教育CEO

  • 10年技术老兵,擅长系统架构设计、大数据、运维、机器学习、技术管理等领域;

  • 曾供职于百度、58集团、转转等公司。

大家好,今天我将从以下这三方面,来和大家分享一些海量高并发的经验:

  1. 中台模式和微服务架构到底有什么样的关系

  2. 海量并发的业务中台架构如何设计与实践

  3. 秒级新业务接入的交易中台如何设计和实践

一、中台模式与微服务架构的关系

现在大家应该都知道,中台最早是由芬兰一家著名的游戏公司Supercell提出的,以小前台的模式来组织若干个开发团队。

也就是说,你的每个前台的开发团队,只需要了解开发一个业务/一个游戏所需要的业务逻辑就行。这样的话,像每个业务会需要一些公共的东西,比如说像游戏引擎、一些内部的开发工具、基础设施等等,就不需要花时间去关注,会有一些专门的“部落”,也就是中台部门来负责提供。“部落”可以根据需要扩展为多个小分队,每个小分队都保持共同的目标,“部落”本身并不会提供游戏给消费者。

怎么理解呢?

首先我们都知道公司里面会分为多个前台,每个前台需要写自己的业务逻辑,这个业务逻辑的底层是一个公共的东西,比如说你的游戏引擎、内部的开发工具、平台、基础设施等等。

那什么是中台?这些游戏引擎、内部的开发工具、平台、基础设施等等就属于中台。

那什么是前台?你的每个产品其实就是一个前台,或者说,你每一个产品需要的业务模式就是前台。

这种中台模式在业界渐渐流行了起来,在2015年的时候,阿里巴巴张勇(逍遥子)宣布启动中台战略,构建符合数据技术时代,更具备创新性和灵活性的“大中台、小前台”的组织机制和业务机制,实现管理模式创新。

这时候是想做一个什么事情呢?其实阿里巴巴想做的一件事情就是把一些产品的技术力量、数据运营力量从前台剥离出来,成为独立的中台。这个中台就包括了像搜索事业部、共享业务事业部、数据平台事业部等,为前台即零售电商事业群提供服务。

也就是说,中台总共包含了这样的四部分:

  • 搜索事业部,做的是算法中台。其实从名字来看,搜索事业部更多是在搞搜索,搜索中主要的两件事一个是召回,一个是排序。所以搜索事业部在做的事情其实就是算法相关的一些事情,会偏多一些;

  • 共享业务事业部,做的是业务中台,包括比如交易中心、商品中心、用户中心……;

  • 数据平台事业部,围绕数据,也就是做数据中台;

  • 另外它还会涉及到一块儿技术相关的(技术中台),比如存储、开发的整个框架等等。

那么今天我重点想讲的是业务中台,一个业务中台到底包含哪些东西,这个对我们也是比较重要的一部分。要考虑的是怎么样让你的业务支撑的更加快一些。

业务中台在我看来更多是一种从公司层面的组织架构,或者说业务架构。我们将业务中台抽象出来,既然它是一种业务架构和组织架构的结合体,那么我该怎样实现它呢?

实现的时候,我可以采用微服务架构,也可以采用单体架构,还可以采用SOA架构,还可以采用数据架构。

所以大家想一下,业务中台也好,技术中台也好,它想要承担的责任是什么呢?业务中台在实现过程中可以采用微服务架构,就仅此而已吗?

在我看来,微服务架构其实仅仅是中台模式落地的一种典型技术架构实现方式。这一点大家一定要记住。

理解了这点之后,就不会把整个的微服务架构和整个的业务中台混为一谈了。这也是实际过程中比较重要的一部分,我觉得也比较重要。

接下来,也就是本次分享的第二部分,我们来分析一下,业务中台在实现微服务架构的时候,应该怎么做?

二、海量并发的业务中台架构

如何设计与实践

大家可以想一下,假如你要做一个交易业务中台,或者打算做一个电商业务,业务里面一个请求过来,比如说发布一个商品,到了你的服务端,你要构建你服务的一套架构,要怎样构建呢?

首先业务过来,一定要有一个接入,负责接入这个请求。接入请求是为了做什么呢?比如可能是负责和前端的一个连接,连接后,要对请求做一些处理,比如说对它做一些请求鉴权、通用参数的检查、路由的转发等等,这些东西总得有一个服务来做,这个服务我们就叫做网关层。

图1

网关层并不负责处理具体的业务逻辑。比如说你发布商品的时候,一定会有一个具体的业务逻辑,这个业务逻辑是谁来处理呢?当然是交给下一层——业务逻辑层。

业务逻辑层里就是对你业务的一个数据的处理。举个例子,比如说我们整个的业务逻辑层包含什么东西呢?你使用微信,给你好久没有联系的一个朋友发了一条消息:“哥们儿,今天有空吗?我们约个饭”

当你发出去后,微信告诉你信息已发送,但被对方拒收。说明什么?说明你被对方拉黑了。在座的各位都有过这种经历吧?没有的话,你的人生是不完整的,哈哈。

那这种情况下,他拉黑的处理,对我们来说就是一个业务逻辑的处理。这个业务逻辑处理,包含“拉黑”这个操作,包括不管你是发消息,还是聊天、转账,都需要这样的一个模块。既然是一个模块,我们就把他抽出来,变成了一个业务公共的逻辑层。

所以我们逻辑层一般来说会分为两部分,一部分是个性化的业务,另一部分是公共的业务。比如“拉黑”这种操作,就是公共的。但不管是公共的业务逻辑,还是个性化的业务逻辑,都需要访问数据。所以接下来的一层就是数据访问层(见图1)。

数据访问层很显然,就是提供底层数据库的一个增删改查;以及当数据量比较大的时候,要能够做到分库分表,做一个Sharding的工作;以及要做到屏蔽底层数据存储差异性。

再往下就是DB和Cache。

那么,在这个架构里面,大家想想看,我们整个的业务逻辑层包含了哪些部分呢?

图2

所谓中台,其实就是哪些东西是公共的,是不变的。

那很显然,网关是不变的;业务逻辑层是变化的,但业务逻辑层里中台的部分,是不变化的;数据访问层也是公共的;包括底层的db,不属于业务范畴,其实是一个技术的支撑,我们叫技术中台。

所以在这个架构里面,我们就会看到:

  • 网关层属于业务中台;

  • 公共的业务逻辑层属于业务中台;

  • 数据访问层属于业务中台;

  • 个性化业务逻辑层属于业务前台;

  • 底层DB属于技术中台;

  • 注册中心,已有的配置中心,也可以划入技术中台的范畴。

所以我们就会看到,实际上当你将整个的业务按照微服务这样来落地的时候,网关层、公共业务逻辑层、数据访问层这些都属于中台范畴;个性化的业务逻辑层属于前台范畴。大家一定要搞清楚。

搞清楚之后,我们做中台就比较简单了,也就是说,取决于能不能在业务层面将公共能力下沉为服务,并做好服务连接。

怎么理解呢?

比如说,像网关层、公共的业务逻辑层等,你应该把它抽象出来,做为一个独立的服务来执行。这是我们在整体的思路上需要去沉淀的。

那么下沉为服务后,服务连接要怎么去做呢?我们接下来花点时间讲讲这块儿。

比如转转,里面有些怎样的业务呢?因为它是转卖的二手商品,所以就会有C2C(个人对个人)、B2C(商家对个人)、C2B(个人对商家)各种不同的商品模式,会有很多不同的业务。

图3

在这些业务里面,不论是C2C、B2C还是C2B,这几种业务模式里面都一定会有些公共的业务逻辑,也一定会有个性化的部分。个性化的东西,比如你是C2C的,有C2C的业务逻辑层;B2C的,有B2C的业务逻辑层;C2B的有C2B的业务逻辑层,那么这时我们在沉淀中台的时候,就将公共的东西抽出来,变成我们的业务中台,这个是我们实际过程中在做的一个事儿。

刚才说到了,我们在实现中台架构的时候,其实就是实现了微服务架构,里面网关、公共逻辑层、数据访问层属于业务中台。但是业务逻辑层,很显然,它是个性化的,属于小前台。我们重点聚焦的就是业务中台的范畴可以怎么去做,也就是将公共能力下沉为服务。

图4

另外一块,业务中台可能会有很多,比如说商品、交易、搜索、推荐……确实,如果我的前台业务,比如说新做了一个业务线,怎样才能让它一键接入呢?这个对我们来说也是一个比较有意思的事情。

大家可以看这个图,一起想想看:

图5

图中右边部分,使我们整个的一个中台,比如说商品中心、用户中心、交易中心、搜索中心等等,还有很多的一些其他的事情,也可以去做。在这种情况下,有这么多的中台需要接入,当我如果真的需要接入一个小前台的时候,难道这些中心我都要一个一个接入吗?

很显然,对我们来说太麻烦了。我们希望怎样?

我们希望,一个业务,首先能够给我分配一个ID,比如是1,就将这个业务注册为业务中心的1号,注册完后,接下来我对这个业务的标识就都会通过这个ID来做。当然这个ID有可能是一个ID,也有可能是一个三级ID。比如说一级类,二级类,三级类……

那在这种情况下,大家可以想一个问题:你现在已经对这个业务做好一个标识了,那接下来这个业务需要哪些中台的能力呢?

你需要做什么?你需要做一个配置。

那这个配置配的是什么呢?

举个例子,就是把你这个业务需要的中台,比如要接入商品中心、搜索中心,接下来要做的的事情就是把ID和搜索中心构建起来就好了,你需要在配置中心里配置一下你前台所需要接入的中台。

配置完以后会有一个接入策略,也就是以什么方式进行接入,比方说商品要接入到搜索,需要告诉我搜索在接入时要提供哪些字段可建索引、哪些字段不能建索引。首先对业务进行标识以后,业务要接入哪些中台需要有个配置,配置完后业务要怎么接入需要有个接入策略,这样当我要发布一个商品的时候,把商品推到搜索中心,搜索中心拿到商品后按照配置规则就会知道哪些字段可建索引、哪些字段不可建索引,最终把整个事情构建起来。因此构建这样一套接入体系很重要。

三、秒级新业务接入的交易中台

如何设计与实践

要构建一个中台,首先要做一个微服务架构,把微服务架构里的网关、公用业务逻辑、访问顺序做成中台,把个性化的部分做成业务逻辑层这个小前台,然后接入的时候把整个业务通过这种方式进行接入。

那么,秒级新业务的接入我们应该怎么做呢?

图6

大家可以从上图看到,在很多情况下订单的整个流程是比较复杂的,电商订单的状态持续变化,每个状态的逻辑关联关系在不同的状态里变化都是不一样的。比如说退款这个操作,在发货前和发货后是完全不同的流程,发货前申请退款就会马上给予退款,但在已发货的状态下申请退款,就需要看商家是否同意,同意则退款完成,不同意则会驳回。

图7

在很多情况下,同一个业务或者两个不同的业务,它们80%的业务流程都是一样的,只有20%不同,如果每一个不同的场景全都通过硬编码的方式来做,那整个业务的复杂度就会比较高。大家可以对比看看上图中C2C交易与自营交易的流程。

图8

如果是在业务初创期,可以用硬编码就行,硬编码就是同一个状态它在满足不同流程里的继续往下不同的流转,你就可以if else。比如说if这个时间等于1干什么事情,else if这个时间等于2干什么事情。这时如果你的状态不复杂的情况下,这个事情做起来是比较简单的。但如果状态比较复杂的情况下用硬编码,基本上你就废了,那这种情况下怎么做呢?

这时无非就是要做什么事情?从一个初始状态到目标状态,你给它一个动作以后让它进行流转,就是在有限状态以及在状态之间的一个转移的数据模型,也就是状态和动作之间的转移。什么是动作和转移?可以看回图6的例子,已支付是一个初始状态,申请退款是一个动作,然后它就进入了退款这个目标状态。其实所有状态之间的转移,都可以用图8说的FSM状态机来表达。

图9

这个FSM解决方案的作用是,怎样在动作的加持下进行状态的流转,之后我们就可以对状态机进行抽象。那么状态机包含哪些要素?

图10

首先要定义状态机的框架,抽象业务场景状态的角色,包括初识状态、目标状态,还有角色及角色不同的操作权限,以及操作对应的事件、事件操作相应的Action实现(Handler)。需要展开说明一下的是事件的定义,就是角色A在初始状态S1下,执行OP1操作,将使用Handler来处理业务逻辑,执行成功将状态设置为目标状态S2。这些就是交易中台FSM普适的架构设计和实践。

图11

如果要用一些结构化来描述应该怎么描述呢?FSM落地其实无非就是状态转移表的定义,状态转移表里包含操作、角色、初始状态、目标状态、Handler这几个因素,只要构建起这个状态转移表,其他就好办了。如果你用Java语言,那这套框架可以基于Spring State Machine来做。

假设现在有了这套状态转移表,或者说是整个通用的FSM框架表,那么要接入新事件的话需要做什么事情?首先是要配置好这个表,然后进行新Handler业务处理的编写,这样就能很快进行接入。如果你没有新的Handler,那整个接入就是秒级的,如果有新的Handler需要做的话,写几行代码就可以了,所以说这套东西对于我们来说整个处理是非常快的。

图12

如果我们有了这套FSM状态机,这时再去接入不同的业务,无非就是在数据库里配置一下,写一些配置表就好了。也就是说通过中台FSM能力,只要将状态图绘制出来,相应的状态流转表配置就已经产生。然后Handler只需要关注当前操作的业务逻辑就行,极大地解耦状态和业务。这套FSM在早期的百度和58都很好地满足了业务场景。

>>>>

Q & A

Q1:为什么不用MySQL做分库分表?

A:分库分表用MySQL还是可以的,但毕竟你的数据访问层还是要关注分库分表这个动作,这个时候业务开发起来工作量就比较大,所以最好的方式是你的业务同学不需要关注分库分表,把分库分表的东西下沉到DB层,让DB层直接来做就好。另外,分表还会带来很多问题,比如查询有多维度的情况下,其实不是很好分表,分表后反而会带来很多问题。

Q2:互联网app类的架构能大概讲一下吗?

A:微服务架构包含网关层、业务逻辑层、数据访问层以及DB,其实这就是一个APP的后台架构,目前基本都采用微服务架构来做,但有些公司是业务逻辑层和数据访问层合在一起的,我个人是建议分开。

Q3:请问状态机机制有什么缺点?

A:我觉得缺点只有一个,就是开发成本比较高,但一旦开发出来之后,只要配置就好了,整个灵活性很高。

Q4:订单属于交易领域吗?

A:是的,属于交易的子领域,但是订单和交易要分成两个不同的服务,因为它们属于一个大的领域,但不同的子领域,订单是一个服务,交易是一个服务,还有清算、结算也是一个服务。

Q5:你们的中台系统都是多IDC的吗?

A:我们原来是多机房的,有两个机房,北京一个,天津一个,在这种情况下我们的整个中台其实是两个机房的。

Q6:能介绍一下您对中台的理解吗?

A:中台本身就是把一些公共的东西做一个抽象,比如把业务的东西抽象出来那它就是一个中台,然后用中台来服务不同的业务。

Q7:你们用Redis都存储什么数据?用哨兵还是cluster?

A:用Redis存我们的缓存数据。目前主要是用cluster模式,如果量小的话可以用Redis的主从模式,通过哨兵机制来做,但如果是比较成型的还是推荐用cluster模式来做。

Q8:ui层的网关用kong么?

A:不是,推荐大家用zuul。

Q9:状态机有决策表吗?决策树是否都能达到目的?

A:这个不需要,因为它其实现在这个还不涉及到智能决策问题,本质上就是流程都是确定的一个状态,确定的东西其实没必要引入一些智能的角色,直接把需要流转的东西配置在状态表里就好。

Q10:spring cloud gateway上生产如何?

A:还不是非常成熟,不建议直接上生产。

Q11:一个微服务都要对应单独的一个库吗?

A:不一定,有可能会存在多个微服务对应一个DB,还是要看你业务本身的设计,没必要为了对应而对应。

Q12:docker swarm的overlay网络是不是慢?用什么网络好?

A:docker本身没问题,但swarm用得比较少,我建议你直接用k8s就好了。

Q13:k8s和docker的关系?

A:docker本身是一个容器,目的是让你方便扩容。想想看当你有很多个容器的时候,每个容器的生命周期、重启、迁移等,总得有个地方去管理,而k8s就是对docker进行管理的系统。

Q14:您是怎么快速构建知识体系的?

A:很多同学学习了半天,学习了很多知识点,但光有知识点是没用的,因为无论你最终做一个架构师也好、工程师也好,你都需要具备架构设计的能力,也就是当你面对一个业务场景,能不能给出一个迎刃而解的方案,这种光有很多知识点是没用的,要由点连成线,由线成面。那这个过程需要干什么呢?我觉得最主要是通过深度思考来把这些知识点关联起来,这个东西其实很难的,最好的方式就是跟着大牛,让他带着你去做。

Q15:老师的职业路线很好,能讲一下您每段职业当时的想法吗?

A:第一是内驱力,就是对自己的职业定位,你想成为什么样的人?这可以说是拉开人与人之间距离的核心发动机;第二是深度思考能力,就是能不能透过现象看出本质问题,这个能力非常重要;第三是技术视野,就是要把你的眼界打开。

特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:

长按订阅更多精彩▼

如有收获,点个在看,诚挚感谢
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读