【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

  • 2020-05-23
  • 本文字数:6724 字

    阅读完需:约 22 分钟

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

本文由 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-05-23 10:004161

评论 2 条评论

发布
用户头像
的事情无

首先要定义状态机的框架,抽象业务场景状态的角色,包括初识状态、目标状态,还有角色及角色不同的操作权限,以及操作对应的事件、事件操作相应的 Action 实现(Handler)。需要展开说明一下

...

开说明一下的是事件的定义,就是角色 A 在初始状态 S1 下,执行 OP1 操作,将使用 Handler 来处理业务逻辑,执行成功将状态设置为目标状态 S2。这些就是交易中台 FSM 普适的架构设计和实践。

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

一文带你弄懂Kubernetes应用配置管理时间

Java-fenn

java;

Java 进阶 (八)Java 加密技术之对称加密、非对称加密、不可逆加密算法

Java-fenn

Java

字节架构师离职后,熬夜整理55W字Java面试手册,逆风翻盘进阿里

钟奕礼

Java 编程 架构 后端 java面试

字节前端二面高频面试题

loveX001

JavaScript 前端

干货 | H5性能分析实战来啦~

霍格沃兹测试开发学社

设备健康管理平台如何为企业打造五大核心设备管理体系?

PreMaint

企业设备管理 预测性维护 设备健康管理

大数据和人工智能离不开云计算,他们之间有什么关系?

Finovy Cloud

人工智能 云计算 大数据

HiveServer2 内存泄漏问题定位与优化方案

Java-fenn

Java Java 面试 #java

字节码增强技术之 Java Agent 入门

Java快了!

java;

Java 序列化10倍性能优化对比测试

FunTester

干货 | Docker 还可以搭建Web服务器nginx ?这么宝藏的吗?

霍格沃兹测试开发学社

Docker常用命令原理与实战

Java-fenn

java;

LED显示屏有哪些让你无法拒绝的优点

Dylan

LED显示屏 户外LED显示屏

耗时半年,堪称奇迹!阿里架构师整合出258W字Java全栈面试题

钟奕礼

Java 编程 程序员 架构 java面试

干货 | APP自动化Android之属性获取与断言

霍格沃兹测试开发学社

Chrome已实现对H.265/HEVC的硬解支持

微帧Visionular

真的强!来自扫地僧总结的39W字上千道Java一线大厂面试题手册,成功助我拿下蚂蚁金服offer!

钟奕礼

Java 编程 架构 后端 java面试

python 基于aiohttp的异步爬虫实战时间

Java-fenn

Java

龙蜥开发者说:海纳百川,有容乃大,我在龙蜥社区的升级之旅 | 第 11 期

OpenAnolis小助手

开源 Linux内核 sig 龙蜥开发者说 epbf

这份数据安全自查checklist请拿好,帮你补齐安全短板的妙招全在里面!

Java-fenn

java;

泪洒阿里,面试惜败闭关2月金九银十再战Alibaba!

钟奕礼

Java 编程 架构 后端 java面试

数字藏品:为什么这么火爆,那么多人购买?

开源直播系统源码

区块链+ NFT 数字藏品 数字藏品开发 数字藏品系统

直播回顾|容器如何提升应用的稳定性?(附PPT下载)

BoCloud博云

云计算 容器 云原生

5000页?一份字节跳动Java面试全解手册发布!瞬间登顶各大搜索栏

钟奕礼

Java 编程 架构 后端 java面试

ChunJun Meetup演讲分享 | 基于袋鼠云开源框架的数仓一体化建设探索

袋鼠云数栈

工赋开发者社区 | Transformers如何用于遥感?阿联酋MBZUAI最新《Transformers遥感处理》综述,涵盖60+种ViT遥感方法

工赋开发者社区

GitHub永远的神!“阿里爸爸”终于总结出15W字Java源码真题手册

钟奕礼

Java 编程 架构 java面试 技术宅

袋鼠云产品功能更新报告01期丨用诚心倾听您的需求

袋鼠云数栈

实战 | 电商业务性能测试(二): Jmeter 参数化功能实现注册登录的数据驱动

霍格沃兹测试开发学社

干货 | Chrome 浏览器+Postman还能这样做接口测试 ?

霍格沃兹测试开发学社

真的香!这份《Java面试题库大全》在Github一夜爆火后直接被各大厂要求封杀!

钟奕礼

Java 编程 架构 java面试 技术宅

交易中台架构设计:海量并发高扩展,新业务秒级接入_架构_dbaplus社群_InfoQ精选文章