技术架构分层交互规范

本文大纲：

1. 分层交互规范

• 命名标准约定

• 产品业务层职责

• 中台业务层职责

• 中台服务层职责

2. 思考几个问题

分层交互规范

上篇文章已经介绍过，在公司业务层面通过把公共能力下沉为服务，并做好服务间连接，持续赋能业务部门。中台在公司组织架构层面一般是独立的中台部门。

先看一张很经典的电商领域的技术架构图，如下：



电商技术架构图

中台服务在逻辑上分为中台服务层（数据访问层，提供基础能力）和中台业务层（公共逻辑层，提供抽象、整合、封装好的公共通用能力）两层。这样做的好处是，中台服务层聚焦于稳定收敛的业务模型和基础服务本身，一般不会随着业务和前台产品的调整发生变化，可以简单理解为业务模型的DAO。中台业务层则专注于通过流程编排类的技术手段，将基础能力构建成公共业务的解决方案，解决共性部分和个性化部分的问题。

下面是一张中台服务落地实践的分层交互图。



分层交互规范图

1、命名标准约定

包括项目工程命名与工程内部主要接口类层面的命名规约。

• Biz：跨多实体业务逻辑（即跨多个Service，业务逻辑处理）

• Service：单实体领域内微服务（具有职责单一/高度内聚/接口原子性等特征）

2、产品业务层

产品业务层一般被划分到各个业务产品线部门，是连接前台产品（如ios 、android APP , H5 APP ,PC 站点，微信、支付宝小程序）和中台产品层的纽带。这个层主要做参数转换，路由分发，调用中台服务，结果封装。这块还需要做好请求路由映射规范，负载均衡方案，跨越问题和安全问题（注意的是，这部分很多公司大量微服务化后，细分出了专门的服务接入层，也叫网关层）。

2.1 上游发布

• 通信协议

• Http：提供给Web端

• Dubbo：提供给客户端API层

• 数据模型

• Param：请求参数封装

• VO：承载响应实体信息

• 接口命名

• Controller结尾：发布Http接口

• Facade结尾：发布Dubbo接口

2.2 内部逻辑：

• Biz：业务逻辑流程处理

• Service：封装一些基础服务。沉淀和抽象出通用独立的公共基础组件（如抽象封装分库分表访问，读写分离），这些组件在服务本项目本团队的同时，还可以可以开源出去服务更多的人。

2.3 下游依赖：

• 详见：中台业务层——上游发布

3、中台业务层

中台业务层属于公共业务逻辑层，为了应对不同的业务场景（如电商业务的一口价、拍卖、抽奖、预售），将原子的基础能力编排成满足不同场景的解决方案，以服务的方式透出出去。

3.1 上游发布

• 通信协议

• Dubbo：提供给产品业务层

• 数据模型

• Param：请求参数封装

• DTO：承载响应实体信息

• 接口命名

• Facade：发布Dubbo接口

3.2 内部逻辑：

• Biz：业务逻辑流程处理

• Service：封装一些基础服务

3.3 下游依赖：

• 详见：中台服务层——上游发布

4、中台服务层

也叫数据访问层，它有稳定的业务模型，将这个域的基础能力沉淀下来形成原子的基础能力。

4.1 上游发布：

• 通信协议：

• Dubbo：提供给中台业务层

• 数据模型：

• Param：请求参数封装

• Entity：

• 承载实体信息，建议直接以业务实体命名（例如Housedel）

• 不含业务逻辑，所以数据模型应当是上下游通用的

• 接口命名：

• Service：

• 发布Dubbo接口

• 不含业务逻辑，所以对上游发布的接口和封装数据源访问的接口的定义应当是一致的

4.2 内部逻辑：

• Service：封装数据源访问，提供原子性接口。

4.3 下游依赖：

• 通信协议：

• TCP：各种数据存储系统（例如MySQL、TiDB）原生协议

• 数据模型：

• Entity：承载实体信息，建议直接以业务实体命名（例如Housedel）

• 接口命名：

• DAO：数据源访问封装

思考问题

抛几个问题，欢迎一起交流思考。

1. 是否允许产品业务层直接访问中台服务层？业务逻辑特别薄的时候中台业务层有可能影响开发效率？

1. 中台服务层的安全性如何保证？统一记录访问日志，或者接口鉴权，还是IP白名单？

1. 中台服务层、中台业务层是否应该把代码写一起？如何权衡RPC调用风险和工程搭建成本。

1. 中台业务层提供的接口如何保证事务性？引入分布式事务、保证最终一致性，大事务是否有必要拆分成多个小事务，下沉到服务层。

后续还会推出系列其他文章。欢迎大家关注我，一起交流技术方案和产品玩法。