快速成为*架构师的内功修炼
查看直播——海量并发高度扩展的交易中台架构设计与实践
一、中台模式和微服务架构的关系
首先讲讲中台模式是怎么来的。在很早之前，芬兰的一家非常著名的游戏公司叫Supercell。
这家公司在开发游戏的时候，能以非常快的速度开发出一个游戏。这个游戏其实就是一个业务。
这个业务之所以能够开发出来，一定会有一些公共的东西来进行赋能和支持。
Supercell以小前台的方式组织了若干个开发团队。每个团队包含开发一款游戏所需的各种角色，可以快速决策、快速开发。基础设施、游戏引擎、内部开发工具和平台则由类似 “部落” 部门提供。部落可以根据需要扩展为多个小分队，但各个小分队都保持共同的目标。部落本身并不提供游戏给消费者，它只提供一些能力，赋能给你的前台业务。这里说的部落，在我看来其实就是一个中台。**游戏本身就是小前台。
**
对于任何一家公司而言，中台可以分为技术中台，业务中台，算法中台和数据中台。
今天我们主要讲业务中台。业务中台的落地，可以采用单体架构，微服务架构等等。大家可以看到，微服务架构仅仅是业务中台落地的一种典型技术架构实现方式。
二、海量并发的业务中台架构如何设计与实践
今天我们要讲整个的业务中台，它是基于微服务架构的方式实现。在微服务架构模式里面，哪些是属于你的业务中台，哪些属于你的前台，哪些是公共的，哪些是个性化的东西，我们要把它区别出来，这是一个很关键的因素。
微服务架构分为几部分。
第一部分是网关层。很显然它就做一些和网关相关的事情。比如说通用参数的一个检查，路由的一些转发，协议的一些转化。它是一个服务的概念。
第二部分是业务逻辑层。对于电商来说，一定会有自己的业务层。比如说，APP有APP的业务逻辑，小程序也有小程序专门的一些业务逻辑，但它们都要有一个商品发布逻辑层。它属于第三部分，公共逻辑层。在这一层里面，把一些公共的东西全部下沉下来，沉淀在这一层里面。
第四部分是数据访问层，包括商品数据访问层，搜索数据访问层，推荐数据访问层，交易数据访问层。
第五部分是持久化层。每一层都是由一个服务构成，当然，每一层可能有多个进程，这就是整个的业务架构逻辑。
在这个架构里面，除业务逻辑层以外，其他属于中台。具体来说，公共逻辑层，网关层，数据访问层是业务中台。持久化层，注册中心，配置中心，是技术中台。而业务逻辑层则属于业务前台。我们可以通过这样的方式来构建业务架构逻辑。
构建完以后，我们把业务层面公共能力下沉为服务，并做好服务连接。做好公共服务的全连接，使得前台业务一键接入。
举个例子，现在来了一个APP，那么它最终需要接入的中台是比较多的，比如说你的网关层，你的公共逻辑层，数据访问层，我们能不能做到业务中台设计的时候能让业务很方便的去接入。另外一块，做好公共服务的一个全连接，它有很多的服务，商品的列表页，商品的详情页，商品的发布服务，搜索服务，推荐服务等等。新的一个业务，要去接入这些服务的话，其实是非常繁琐的。
我希望你这时候能给我一个proxy，帮我去连接好这些东西。我的业务接入的时候，一键接入 proxy就好了，这样的话，业务接入的成本是非常低的。
所以在这种情况下，首先，得对你的业务做一个标识，做一个ID化。标识的目的是让你做一个标准化，有了标准化以后，接下来接入的时候，你的整个业务只需要完成一个填空题就好了。怎么样做一个ID标识，往往可以给你的业务做一个三级的分类。
比如说，一级业务是电商，二级业务是手机，三级业务是好货。当然，你最终需要几级体系，取决于你的业务特点的需求。这是一套标准化的东西，我们要去构建这样的一二三级的一个业务。我们也是按照这样的思路去构建我们的这样一个生态。
三、秒级新业务接入的交易中台如何设计和实践
交易中台有很多流程，或者说很多状态。比如说，已支付，已发货，退款，拒绝退款等等。在这种情况下，我们如何方便地让多个业务接入。
多个业务之间有一个28原则，可能80%的流程都是公共的，只有20%的流程是有差异的。在这种情况下，交易的流程该怎么去设计，是一个比较好的问题。如下图所示，以电商订单状态为例，退款在发货前和发货后，流程完全不同。
相似业务有两套业务流程，这种情况是很常见的。在业务初创期，可以硬编码，通过IF和ELSE语句定制化链路，分别针对不同的流程。
随着业务量越来越多，复杂度会很大，定制化链路不一定可行。在这种情况下，我们要运用架构设计的哲学：抽象。可以对业务场景做一个抽象：状态和动作。于是，一个新的解决方案应运而生，有限状态机（FSM）：有限状态以及在状态之间转移和动作等行为的数学模型。于是，可以定义交易中台普适的FSM，定义状态机的一个框架，以及抽象业务场景的状态角色。首先，有两个状态，一个是初始状态，一个是目标状态。初始状态和目标状态之间有转移关系。第二，定义角色。不同角色有不同的操作权限，比如卖家、买家、系统、客服。第三，定义操作，对应事件。第四，定义Handler，事件操作相应的Action实现。其中，一个事件定义为：角色A，在初始状态S1下，执行OP1操作，将使用handler来处理业务逻辑，执行成功将状态设置为目标状态S2。
定义状态机框架以后，接下来就是FSM的落地。本质上是一个状态转移表的定义。如下图所示，状态转移表里面有这样几个角色。第一个是op_type，代表具体的一个操作，只不过我们把这些action变成了一个具体数字。第二个是role，代表你是买家，卖家，还是客户。第三个是source_status，即源状态。第四个是target_status，即目标状态。第五个是handler，代表从源状态到目标状态以后要执行什么操作，比如说拒绝订单的行为。
如果你是Java生态的，可以通过Spring State Machine框架来实现。如果你是其他语言的，可以通过其他语言的框架进行实现。假设我们现在已经有了这样一张表，当一个新的业务需要接入的时候，只需要配置状态转移表，以及新handler业务处理的编写，基本上可以秒级完成业务接入。
回到刚才C2C的交易和B2C的交易，假设我们已经有了中台能力，通过中台FSM能力，只需要把状态图画出来，相应的状态流转表的配置就有了。handler只需要关注当前操作的业务逻辑，极大的解耦状态和业务。所以实际过程中，不用去烦恼具体的一些事情。
关键词：微服务架构，中台模式，业务中台，交易中台，有限状态机