好了，失踪博主又回来更新了。终于有时间再输出了，这一次主要是关于企业中台的相关内容。其实近一年都在0-1的搭建中台，中间也有走过弯路和摸索。最近才真正系统性的梳理了一下内容，所以来进行一个分享，当然，中台其实是一个“水”很深的方向，所以我也是基于自己的工作经历和认知做一个参考分享。

--题记

part 1 什么是中台

简单来讲，中台的主要目标：为了企业增效降本，减少重复造轮子，把整个业务流程标准化，可以多次复用，快速产出。中台服务于前台，本质上是拼接复用，只不过因为落地的方案需要技术、数据、引擎能力的支持，所以才会有细化。因此核心就是把业务共性需求抽离出来，以组件化的思路做成一个可供前端业务快速复用模块/组件的支撑性平台。

当然，中台本身也还具有很多其他的功能，这和每个企业的内部形式有关。例如我所负责的中台，其实核心的目标就2个，1是降本增效，能够支持快速开发新产品；2是串联公司“烟囱式”的所有系统，受公司发展历史影响，我所在的企业，在各个阶段开发和引入了很多平台系统，使得公司内部各个系统之间如同烟囱一样，业务流程上相互影响，但是系统之间又彼此隔离，互不串联。

part 2 中台的分类

根据不同的定位和使用场景，中台大方向可以分为4类：业务中台、技术中台、数据中台、引擎中台，四种中台彼此独立却又互相配合，以提供解决方案去满足实际需求。需要注意的是，这里的需求，既包含业务需求，也有产研需求。

• 业务中台：主要为了前台业务服务，重点在于把公司业务上的共性需求抽离出来。例如：登录服务、账号等级体系、权限体系、会员体系，涉及充值业务的充值体系，产品层面的消息提醒、公告服务等。这里的关键点是“共享”和直接复用，所以一般不会区分前台和后台的效果。类似于微服务的概念，这个产品需要就上，另一个产品需要也可以直接上。前端和后端都不进行修改，针对单模块几乎0成本，从而去达到减少开发、快速上线的效果。

• 技术中台：在应用层之下的底层服务，部分会涉及到一些架构的内容。在具体聊技术中台前，需要引入三个词“saas、paas、laas”。技术中台其实更多的内容是跟pass层相关联的，服务于saas层。更多的使用场景在前端应用层面无法进行标准化，但是后端pass层其实都是同一套逻辑和架构体系的情况，这个时候，就可以把前端和后端拆分开，将后端的服务进行“复用”，前端根据实际需求就行修改或者定制化开发，从而缩减开发成本和减少开发周期。关于技术中台，适用场景更多在B端、G端以及游戏行业的自研厂商，也就是前端需要进行换皮包装，后端其实一直都是同一套逻辑的“新瓶装旧酒”的场景。

此外，技术中台也会涉及到更垂直化的偏技术性的内容，例如API网关等，上份工作经历里设计过一套公司内用的API网关，这里面会有几个关键点需要注意：

1. 如何梳理公司原有的API对接方案去建立新的对接流程
2. 如何在新的流程下统一API接口的对接方案
3. 在对接过程中针对于对接的细节内容（如MD5的多种加密协议梳理、如统一轮询逻辑、负载均衡策略、熔断策略、流量统计、告警、监控等，这里面对于灵活告警、自动告警等的规划和设计该如何进行）

自动化告警其实大家可以参考下近2年新提出的”RPA“概念，至于网关的设计竞品大家其实还是建议参考腾讯云网关和阿里云网关这两类比较主流的产品。而至于监控告警这块则可以细分为2块，1是对接层面的告警，如代码层面的401、403、404...等报错，当然，这里分前后端；2是设备层面的监控和告警，这里大概率会涉及到运维产品，如Devops等，当然，如果你的企业没有使用Devops的产品，而外采的例如”上海新炬“的运维产品，则又需要具体关注内部的方式。

• 数据中台：数据中台，既围绕数据进行处理的中台。

前面提到了业务中台和技术中台，都是在应用层去为了“复用”而作的工作。其实并没有涉及到数据层面，这里会涉及到”数据流“和”数仓“2个内容，数据流又因为中台的特殊性需要在多个平台系统之间流传，所以如何去细化梳理数据流的走向需要各位关注。而在梳理完数据流之后，怎么把每个平台的数据进行统一到数据中台，放入数仓，进行清洗后再把其他系统需要的数据信息通过API接口给予到各自的系统也是一个十分复杂的工作。

• 引擎中台：更偏技术底层的”引擎“层面的内容。这里的内容则会更深入了，举几个例子，我们审核产品里面会常用到的”流程引擎“，游戏行业会经常提到的”Unity3D、虚幻引擎、CryEngine 3 ”等。总之来说，引擎中台其实核心就是围绕“引擎”“通用”2个词的一系列设计和开发。但相较而言的，引擎这块所需要的成本是相当之高。目前国内真的听过在引擎进行自研有所建树的消息还是较少，大多还是选择的开源和国外的引擎居多。

part 3 为什么目前都在逐渐拆中台了？

先要说明的是，目前网上炒的比较火的拆中台不等于去中台，只是把大中台拆分成垂直领域的细化中台。所以现在出现了很多如:销售中台、财务中台、政务中台等的某个垂直领域的中台产品。中台的实际作用依旧是存在的，只是不再依赖于“大”中台，对于精细化、垂直化的中台需求性更高。

从时代发展因素讲，阿里以前提“大中台 小前台”的概念时，实际在市场快速增长的环境。那个时候企业更多的需要是减少开发周期，追求上线速度，去获取用户量，同时，在那个阶段，各个行业其实都没有发展的很成熟，“垂直化”的概念也并不如目前的“重”，所以讲究“大中台”去进行功能糅杂，重“快速”轻“精致”，但是目前整个市场已经进入存量市场，已经从野蛮增长的时代步入到精细化需要去打产品差异化的时代了。

2是收益比在降低。大中台需要的研发成本、开发周期是十分巨大的，同时在目前重视产品“垂直化”的时代下，大中台所能达到的“复用”效果反而在降低，在负效应的roi下，企业从投入成本，收益效果的维度考虑，也必然会逐步拆大中台，去拆分到精细化的垂直领域中台探索。

part 4 后记

1. 其实中台是个复杂性很高的产品，在近一年多的经历里，我都在0-1负责一家上市企业的中台搭建。从实际工作经历的感受来总结的话，并不是简单几句就能说清楚的
2. 中台的每一个方向都完全可以单独拿出来仔细讲解，本文更多的是以科普和分享的维度进行开眼和基本描述，太多细节的内容从复杂性和商业保密的角度就不在此进行展开，如果有兴趣的，欢迎私聊讨论
3. 后续如果精力和时间足够会展开把中台的各个方向单独拿出来讲解，有兴趣的可以关注
4. 本文仅供讨论和参考，不涉及商用，如有问题，欢迎指正，侵权必究