一、正文

1.1 原则

在公司业务层面通过把公共能力下沉为服务，并且做好服务连接，赋能业务部门。

公共能力下沉为服务：公共业务能力抽象与建模
服务连接：做好公共能力下沉服务的全连接，使得小前台业务一键接入

1.2 中台的落地方案

中台的全面落地需要公司组织架构层面和业务层面的调整。

1.2.1 组织架构调整

就是公司层面的人员和组织架构调整，会涉及到部门之间的合作方式，员工的汇报领导的变化，大家都懂的，可以参考下阿里内部组织架构：

阿里组织架构.png

1.2.2 业务架构调整

大中台业务架构调整
- 公司交付物：产品
  - 业务架构（OLTP）：
    - 个性化业务架构
    - 公共业务架构（业务中台）
- 数据架构（OLAP）
  - 个性数据架构
  - 公共数据架构（数据中台）
- 技术架构
  - 技术支撑（技术中台）

1.3 实现的关键点

在实践中台模式时，需要重点关注以下几个关键要点：

业务统一的标识
业务和中台连接的配置：业务需要接入哪些中台？
统一的分发服务：根据业务标识和配置，将请求分发给对应的中台

下面结合下面的电商业务中台架构设计实践来谈谈上面的关键要点如何落地：

业务电商中台架构设计实践

首先，我们关注到上述架构设计中有三个核心模块，他们分别是：

业务注册中心：一个新服务需要接入后才能使用到后续中台系统所提供的服务。需要注册方提供业务线的类型信息，以及一级、二级的应用分类（具体有几级可以根据公司的实际业务场景来确定），注册完成之后就会得到一个唯一的业务ID标识，这个ID在后续的其他管理模块会用到。
业务分发配置中心：有了唯一的业务标识，那么这个新的业务产生的哪一类型的数据，需要以何种方式接入到哪些中台系统呢？这些信息需要在配置中心中进行配置，以便中台系统对接入进行管理和分发。
业务分发连接中心：这个就是根据业务标识ID和分发配置进行规则匹配和分发，可以理解为一个逻辑上的路由器。

接着，我们根据两条线来讲解上述架构的处理流程

业务配置流：1，2，3，4
业务数据流：5，6

数据存储

有时候，一些业务个性化数据也需要存储在中台，这时候通常采用如下的思路:

公共数据表+业务个性化扩展数据表

数据存储.png

第一张表是公共数据表，一目了然，就不再做过多介绍。
第二、三张表实际是一个表，该表作为个性化扩展数据表，其中表2中的属性字段key1-keyN没有明确的含义。value表示实际用到的业务字段值，没有用到就不填。每一行记录所表示的含义为某个采用infoId表示的业务，需要使用到的个性化数据的字段。通常N取32，其中key1-key16可以为long类型，key17-key32为varchar类型，这样基本可以囊括各种扩展字段的数据类型。这就限制了，该业务线最多能够使用16个long类型字段，以及16个varchar类型的个性化数据字段。