中台思考

还是以上此图（此图在我的另一篇博客草稿中）

1、概述

目的：为持续提高企业对需求、问题的响应速度

用户使用的服务可以简称为前台

系统运营管理可以简称为中台

系统运行状况管理简称为后台

最近在研究一个针对互联网管理系统，在不断思考如何搭建架构，网上搜索许多材料以及结合自己的经验做一下总结。

前台后台的概念我们已经非常熟悉，而且现在我公司还在用这样的模式，但大的公司和互联网公司已经是各种中台模式，甚至更复杂的模式。

2、前后台模式

这个模式是我司现在使用也是当前大部分企业管理系统用的模式，前台还是给用户用的。只是后台是运营人员、运维人员、开发人员共用的，主要是运营人员使用。

为什么说主要是运营人员使用，大部分时候是运营人员查看用户账号、用户业务量、客服等数据；当然我们为了跟踪用户使用行为，运营人员也要看用户行为数据。这些数据有疑问开发人员和运维人员也是先看这个后台，与运营人员在内部达成共同语言，大部分时候还是可以解决问题的。

但是当数据不正确的时候，开发人员和运维人员看这个后台就没有太大意义了。开发人员会直接访问数据库查看问题，如果需要解决则直接操作数据库数据，运维人员也是同样的操作方式。如果是小系统或非关键性系统这样的操作是没有大问题的，但是如果这个系统数据比较关键敏感，一旦操作不对，导致数据丢失等，这样的操作就比较危险，加大的系统的风险性。

因此我们既要解决问题，又要有容错性。那么我们就需要让所有的操作可回溯，数据可回滚。在这样的述求下，我们就逐渐需要更加严格操作权限分工、操作/数据可回溯可回滚的机制。

所以中台的概念应运而生！

3、中台

通过第2节的描述，我们基本知道为什么需要中台。那么我们需要一个什么样的中台。在这里，鄙人认为不需要有过于严格的定义，需要根据业务、公司的实际情况进行定义中台。

先说中台需要有什么特点：

a）标准化、规范化

    尽量所有操作和数据控制都在中台中进行。什么人能做什么操作，查看修改什么数据都能统一控制，达到标准化。所有的操作都在中台中进行达到规范化，以免因为个人失误造成损失。

b）灵活性

    不管怎样，我们的目的还是对需求、问题的快速响应，那么中台提供的操作和数据需要比较灵活，才能做到快速响应；过于灵活就会导致失控，所以需要有权限对操作和数据进行限制。当然权限也要足够灵活，才能做到细粒度控制，才能做到快速响应。

c）管理机制

光有系统没有人操作也是白瞎。所以公司或组织也要建议一套人员管理机制，与中台模式进行匹配。（所以奉劝管理机制不能改革的机构就不要想中台了）

小结：中台就是不要一有问题就直接找开发人员，一找到开发人员，就去操作数据库。（够直白了吧）

以下举一个例，希望有所启发：

    针对一个互联网项目，中台需要技术中台、业务中台、数据中台、运维中台

技术中台：

    技术中台主要是为提高代码层面的复用性和快速响应。现在流行的说法就是提供微服务，可以抽象技术模块，以接口的方式开放，技术前台根据业务需求组织呈现给用户。用户端可以是app、网站、硬件等。

业务中台：

    业务中台主要是运营人员使用。需要提供用户账号管理、用户业务处理、用户行为分析、用户客服管理。

数据中台：

    数据中台可以给运营人员和开发人员使用。屏蔽敏感修改删除数据库、数据表、数据行等操作，提供普通数据增删查改。在业务中台中发现数据不正确时可以在数据中台中进行管理。相当于是屏蔽敏感操作后的透明数据库管理。

运维中台：

    运维中台是提供给运维人员使用。类似于现在的堡垒机机制，运维人员所有操作都经过一个统一个系统，与数据中台类似，相当于是屏蔽敏感操作的操作系统指令集系统。

业务中台、数据中台、运维中台中所有操作都要求进行记录、可回溯、可回滚。

 

最后建议：

看完上面的描述，请各位结合自己业务需求考虑是否需要中台，需要什么样的中台，毕竟还是需要工作量的。