还是以上此图（此图在我的另一篇博客草稿中）
1、概述
目的：为持续提高企业对需求、问题的响应速度
用户使用的服务可以简称为前台
系统运营管理可以简称为中台
系统运行状况管理简称为后台
最近在研究一个针对工业管理系统，在不断思考如何搭建架构，网上搜索许多材料以及结合自己的经验做一下总结。
前台后台的概念我们已经非常熟悉，而且现在我公司还在用这样的模式，但大的公司和互联网公司已经是各种中台模式，甚至更复杂的模式。
2、前后台模式
这个模式是我司现在使用也是当前大部分企业管理系统用的模式，前台还是给用户用的。只是后台是运营人员、运维人员、开发人员共用的，主要是运营人员使用。
为什么说主要是运营人员使用，大部分时候是运营人员查看用户账号、用户业务量、客服等数据；当然我们为了跟踪用户使用行为，运营人员也要看用户行为数据。这些数据有疑问开发人员和运维人员也是先看这个后台，与运营人员在内部达成共同语言，大部分时候还是可以解决问题的。
但是当数据不正确的时候，开发人员和运维人员看这个后台就没有太大意义了。开发人员会直接访问数据库查看问题，如果需要解决则直接操作数据库数据，运维人员也是同样的操作方式。如果是小系统或非关键性系统这样的操作是没有大问题的，但是如果这个系统数据比较关键敏感，一旦操作不对，导致数据丢失等，这样的操作就比较危险，加大的系统的风险性。
因此我们既要解决问题，又要有容错性。那么我们就需要让所有的操作可回溯，数据可回滚。在这样的述求下，我们就逐渐需要更加严格操作权限分工、操作/数据可回溯可回滚的机制。
所以中台的概念应运而生！
3、中台
通过第2节的描述，我们基本知道为什么需要中台。那么我们需要一个什么样的中台。在这里，鄙人认为不需要有过于严格的定义，需要根据业务、公司的实际情况进行定义中台。
先说中台需要有什么特点：
a）标准化、规范化
尽量所有操作和数据控制都在中台中进行。什么人能做什么操作，查看修改什么数据都能统一控制，达到标准化。所有的操作都在中台中进行达到规范化，以免因为个人失误造成损失。
b）灵活性
不管怎样，我们的目的还是对需求、问题的快速响应，那么中台提供的操作和数据需要比较灵活，才能做到快速响应；过于灵活就会导致失控，所以需要有权限对操作和数据进行限制。当然权限也要足够灵活，才能做到细粒度控制，才能做到快速响应。
c）管理机制
光有系统没有人操作也是白瞎。所以公司或组织也要建议一套人员管理机制，与中台模式进行匹配。（所以奉劝管理机制不能改革的机构就不要想中台了）
小结：中台就是不要一有问题就直接找开发人员，一找到开发人员，就去操作数据库。（够直白了吧）
以下举一个例，希望有所启发：
针对一个互联网项目，中台需要技术中台、业务中台、数据中台、运维中台
技术中台：
技术中台主要是为提高代码层面的复用性和快速响应。现在流行的说法就是提供微服务，可以抽象技术模块，以接口的方式开放，技术前台根据业务需求组织呈现给用户。用户端可以是app、网站、硬件等。
业务中台：
业务中台主要是运营人员使用。需要提供用户账号管理、用户业务处理、用户行为分析、用户客服管理。
数据中台：
数据中台可以给运营人员和开发人员使用。屏蔽敏感修改删除数据库、数据表、数据行等操作，提供普通数据增删查改。在业务中台中发现数据不正确时可以在数据中台中进行管理。相当于是屏蔽敏感操作后的透明数据库管理。
运维中台：
运维中台是提供给运维人员使用。类似于现在的堡垒机机制，运维人员所有操作都经过一个统一个系统，与数据中台类似，相当于是屏蔽敏感操作的操作系统指令集系统。
业务中台、数据中台、运维中台中所有操作都要求进行记录、可回溯、可回滚。
最后建议：
看完上面的描述，请各位结合自己业务需求考虑是否需要中台，需要什么样的中台，毕竟还是需要工作量的。
强哥说IT
发布了39 篇原创文章 · 获赞 7 · 访问量 4万+
私信
关注
标签：开发人员,用户,人员,中台,思考,操作,数据 来源： https://blog.csdn.net/honey_beeqiang/article/details/104131384
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。