写点什么

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

2020 年 5 月 23 日

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

本文由 dbaplus 社群授权转载。


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


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


作者介绍


孙玄,奈学教育 CEO


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

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


原文链接


https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650788522&idx=1&sn=2a09b0565d3ad9c25f0cbc21700effc0&chksm=f3f9673fc48eee29ba29c60fb1f928e75a000901c5a46920da461ebcf2d3aa6f274b8e5288b8&scene=27#wechat_redirect


2020 年 5 月 23 日 10:002588

评论 1 条评论

发布
用户头像
说明你被对方拉黑了。在座的各位都有过这种经历吧?没有的话,你的人生是不完整的,哈哈。
讲的太好了,谢谢。
2020 年 07 月 20 日 11:17
回复
没有更多了
发现更多内容

ARTS Week1

姜海天

深入计算机底层,从几本靠谱的书开始

HackMSF

计算机工作原理

ARTS-01

NIMO

ARTS 打卡计划 ARTS活动

那些会阻碍程序员成长的细节[2]

码闻强

程序员 程序人生

MAC OS 下 HomeBrew 使用

耳东

macos brew homebrew

ARTS week 2

刘昱

【ARTS打卡】Week01

Rex

学习

John 易筋 ARTS打卡Week 02

John(易筋)

ARTS 打卡计划 ARTS活动 arts

Element-UI实战系列:Table+Pagination组件实现已选和全选功能

brave heart

Vue 前端 Element

Apache DolphinScheduler新特性与Roadmap路线

海豚调度

数据中台 大数据任务调度 工作流调度 海豚调度 数据湖调度

clang-format 使用与集成介绍

Geek_101627

[ARTS打卡] week 01

Mau

ARTS 打卡计划

2万字长文带你细细盘点五种负载均衡策略。

why技术

Java 负载均衡 源码分析 dubbo java面试

你会写测试用例吗

鱼贩

如何使用 Apache CXF 快速实现一个 WebService

Rayjun

Java WebService CXF

后疫情时代,区块链的发展迎来曙光!

CECBC区块链专委会

CECBC 区块链技术

Mysql索引不会怎么办?6000字长文教会你

Super~琪琪

MySQL 数据库 sql 索引

时代在变,产品运营能力很重要

夜来妖

程序员人生 程序人生 产品经理 产品推荐 程序媛

ARTS week2

紫枫

ARTS 打卡计划

ARTS 打卡 WEEK2

编程之心

ARTS 打卡计划

MySQL 可重复读,差点就我背上了一个 P0 事故!

楼下小黑哥

Java MySQL

【openlayers】在vue中使用ol

学习委员

Java html Vue 地图 openlayers

区块链技术大显身手,仅用20分钟就打完一场官司!

CECBC区块链专委会

CECBC 区块链技术 数字版权 存证

ARTS打卡第一周

GKNick

如何设置线程池参数?美团给出了一个让面试官虎躯一震的回答。

why技术

Java 源码分析 面试题 线程池

体验一次简洁的代码

你当像鸟飞往你的山

ARTS-1

你当像鸟飞往你的山

ARTS 打卡计划

我的编程之路 -6(新时代)

顿晓

android 编程之路 时代

愚蠢写作术(1):怎么让你的标题被读者忽视

史方远

个人成长 写作

Java日志门面系统

泛泛之辈

Java 日志 slf4j

ARTS打卡计划_第一周

叫不醒装睡的人

ARTS 打卡计划

NLP领域的2020年大事记及2021展望

NLP领域的2020年大事记及2021展望

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