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

在我看来，微服务架构其实仅仅是中台模式落地的一种典型技术架构实现方式。这一点大家一定要记住。
理解了这点之后，就不会把整个的微服务架构和整个的业务中台混为一谈了。这也是实际过程中比较重要的一部分，我觉得也比较重要。
接下来，也就是本次分享的第二部分，我们来分析一下，业务中台在实现微服务架构的时候，应该怎么做？
二、海量并发的业务中台架构
如何设计与实践
大家可以想一下，假如你要做一个交易业务中台，或者打算做一个电商业务，业务里面一个请求过来，比如说发布一个商品，到了你的服务端，你要构建你服务的一套架构，要怎样构建呢？
首先业务过来，一定要有一个接入，负责接入这个请求。接入请求是为了做什么呢？比如可能是负责和前端的一个连接，连接后，要对请求做一些处理，比如说对它做一些请求鉴权、通用参数的检查、路由的转发等等，这些东西总得有一个服务来做，这个服务我们就叫做网关层。

本文插图

图1
网关层并不负责处理具体的业务逻辑。比如说你发布商品的时候，一定会有一个具体的业务逻辑，这个业务逻辑是谁来处理呢？当然是交给下一层——业务逻辑层。
业务逻辑层里就是对你业务的一个数据的处理。举个例子，比如说我们整个的业务逻辑层包含什么东西呢？你使用微信，给你好久没有联系的一个朋友发了一条消息：“哥们儿，今天有空吗？我们约个饭”
当你发出去后，微信告诉你信息已发送，但被对方拒收。说明什么？说明你被对方拉黑了。在座的各位都有过这种经历吧？没有的话，你的人生是不完整的，哈哈。
那这种情况下，他拉黑的处理，对我们来说就是一个业务逻辑的处理。这个业务逻辑处理，包含“拉黑”这个操作，包括不管你是发消息，还是聊天、转账，都需要这样的一个模块。既然是一个模块，我们就把他抽出来，变成了一个业务公共的逻辑层。
所以我们逻辑层一般来说会分为两部分，一部分是个性化的业务，另一部分是公共的业务。比如“拉黑”这种操作，就是公共的。但不管是公共的业务逻辑，还是个性化的业务逻辑，都需要访问数据。所以接下来的一层就是数据访问层（见图1）。
数据访问层很显然，就是提供底层数据库的一个增删改查；以及当数据量比较大的时候，要能够做到分库分表，做一个Sharding的工作；以及要做到屏蔽底层数据存储差异性。
再往下就是DB和Cache 。
那么，在这个架构里面，大家想想看，我们整个的业务逻辑层包含了哪些部分呢？

本文插图

图2
所谓中台，其实就是哪些东西是公共的，是不变的。
那很显然，网关是不变的；业务逻辑层是变化的，但业务逻辑层里中台的部分，是不变化的；数据访问层也是公共的；包括底层的db ，不属于业务范畴，其实是一个技术的支撑，我们叫技术中台。
所以在这个架构里面，我们就会看到：