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

本文主要是介绍交易中台架构设计：海量并发高扩展，新业务秒级接入，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

今天将从以下这三方面，来分享一些海量高并发的经验：

中台模式和微服务架构到底有什么样的关系
海量并发的业务中台架构如何设计与实践
秒级新业务接入的交易中台如何设计和实践

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

现在大家应该都知道，中台最早是由芬兰一家著名的游戏公司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：第一是内驱力，就是对自己的职业定位，你想成为什么样的人？这可以说是拉开人与人之间距离的核心发动机；第二是深度思考能力，就是能不能透过现象看出本质问题，这个能力非常重要；第三是技术视野，就是要把你的眼界打开。

这篇关于交易中台架构设计：海量并发高扩展，新业务秒级接入的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！