《为什么要刻意区分中台和平台.docx》由会员分享，可在线阅读，更多相关《为什么要刻意区分中台和平台.docx（7页珍藏版）》请在课桌文档上搜索。
1、有位同行领导问了一个非甫好的问题：在我们中台研究中为什么要刻意区分中台和平台，这么做有什么意义？这是一个非常非常好的问题，也是我们中台研究的一个重点，也是我们非常希望解释清楚的一个问题。要解释清楚平台和中台的区别，需要从中台的本质和目的说起.中台本质上是一种架构方式，目的是为了实现且用，减少电鱼投入，提升效率.在中台架构中，平台处于什么样的位SS,起什么作用是中台研究需要厘清楚的问题.如果把这些问题考虑清楚了，也就容易理解中台和平台的区别了.中台本质和目的中台的本质是一种分布式应用系统分层架构方式。有企业直接分为前-中台架构.也有企业分为前-中-后台架构.不管分为几层，这其实并不是一种新的技术
2、或架构，只不过在企业规模化发展到一定阶段，企业资源（数据、应用、人力等）如果无法实现复用,其交互和协作成本和代价往往是级数增长，不得不调整来实现资源系用以提升效率的方法,简单地思考一个问题：设想数据散落于不同的系统之中，这势必会带来数据的大0冗余.随着企业规模的不断扩张、系统数后的不断增长、系统交互的频繁且杂、数据费的厚炸性激增等等，仅仅冗余数据就可能会导致成数倍数十倍的浪费.前些年的SOA-ESB架构就曾尝试从业务层面的集成来解决这样的问题，但ESB最大的缺陷是没有从数据层面考虑，只做业务系统集成而没有触达数据，数据依旧散落于各个单体系统中.ESB通过加息集成的方式来尝试解决巨用问题，但加层
3、集成的方式也使系统层次豆杂化，响应链路变长,响应延迟增加，从而导致很多ESB项目并不成功.而中台的思想是包括从数据展面来重构企业整体架构，这就解决了单体系统数据散落的问题,从数据层和业务层实现了宜用.另外应用系统还涉及很多的公共组件和能力，比如日志、认证和权限、配苣、消息、安全等，这些公共的技术组件往往是可以复用的.这也使很多人误把平台当作了中台。虽然中台和平台在内容上有圭0的部分，但其概念是有本质区别的，不能混为一谈.业务、数据、公共技术组件的可宜用能力提取就是中台的能力。从而以电构的方式从架构层面彻底解决了业务、数据、公共技术组件的复用问题.中台架构层次划分中台复用的粒度软件一直都在尝试实
4、现豆用，从代码豆用、函数豆用、类豆用到组件豆用服务系用、平台复用等不同层级和粒度的或用，各有优缺点。对于分布式中台架构来说，嘟种豆用粒度是合适的？哪种豆用粒度的价值最高？从这些年技术的发展来看，云计箕解决了算力问题，使数据可以通过分布式计算来支撑大数据运算需求，有了大数据才带来了人工智能的快速发展.云计克的云原生技术：容器、微服务、DevOps等为中台架构的复用粒度提供了一种很好的解决方案，那就是服务化或微服务化（微服务粒度是另一个概念）.服务层级的且用粒度更适合中台架构.从数据、业务、公共技术组件层次可以推导出可复用的数据服务、业务服务和技术服务，从而构建起数据中台服务、技术中台服务和业务中
5、台服务.通过中台服务的编排而实现敏捷构建业务应用（实际就是应用client端），从而支持响应企业业务的敏捷变化和变革，快速实现数字化和智能化转型.业务服务业务服务业务服务数据.服务，数据.服务.技术服务数据.服务，IIHIMIIIll技术组件、数据、业务流程服务化以实现可豆用中台可聂用服务来自哪里？数据服务来自于各系统融合后的可复用数据抽象和提取，比如说客户数据，多个业务系统都会用到客户数据，因此客户数据就可以构建为可聂用数据服务,从而也实现了数据的一致性和完整性,其实这也是主数据建设的主要任务.主数据就是企业内共享和豆用的数据，以企业主数据来构建中台数据服务，是一个相对比较好的方式.技术中台
6、服务则来自于公共的技术组件，比如说登录认证，每个业务系统都需要登录认证模块.传统单体系统每个业务应用都要开发一遍登录认证，这就造成了大量的重复建设和浪费，如果把登录认证提取为中台公共认证技术服务，每个系统都可以共享使用这个服务，不但提升研发的效率，而极大地减少函复建设和投入.中台业务服务则意味若业务流程的新建或者业务流程的重构。业务服务的设计有个简单的方法，就是通过梳理业务流程来找出流程交叉点，这个交叉点就是一个业务服务（或叫业务服务操作Operation）,例如在不同的业务流程中都会用到“客户信息查询，这个客户信息查询”就可以作为客户业务服务的一个操作.通过这样方式比国外某著名企业所推的DD
7、D简单得多，也更符合企业实际业务逻担。平台支撑中台架构既然中台架构中合适的粒度是服务化，那么无论数据服务、公共组件服务、业务服务都需要有相应的平台来支撑运行.数据服务需要数据库或数据仓降或大数据平台等来支撑，公共组件服务需要诸如日志平台、认证平台、权限平台、配置平台、安全平台、消息平台来支撑，即便是服务通过编徘的轻量应用客户端，也需要部署于不同的渠道来触达不同的客户，比如App,Web、微信小程序等，都需要这些平台和工具的支撑.因此我们说1平台支撑中台，用平台能力支撑着中台可复用服务，以及前台轻量应用.从中台架构来说，这些平台、工具就是中台架构中的“后台“运行支撑平台.从架构角度，每个平台或系
8、统都可能划分为前、中、后等不同的层次，其实中台架构层次并没有从根本上脱离“业务表示层、业务逻辑层和数访问层、运行支撑层（包括数据存储层）”这样的架构层次划分.中台是从架构角度来说的，而平台是从技术角度来说的，平台和中台是完全两个概念.平台的架构可能分前、中、后台，只不过新的中台”瞭念被京予了新的内涵，涵义更广。不过从企业系统落地的可行方案来看，需要明确区分这两个概念才能更好的去实施中台，才能使中台”具备落地可行性.业务表示层业务逻辑层和数据访问层运行支撑层和数据存储层前台轻量应用客户端中台可复用服务后台支撑平台系统架构层次与中台架构层次中台架构中的前台或前端是“轻豌应用客户端，中台或中间层是可
9、聂用服务（可以是微服务，也可以是ESB服务等），后台或后端是支建这些可且用服务运行的工具或平台，因此可以说平台支厚中台“。这些平台一方面支撑着中台可兔用服务，另一方面也意味若平台支撑着中台架构.以里构的方式，意味着企业业务系统会逐步被电构的服务和应用取代，拆分为数据服务、业务服务和应用Qient,以及基明的技术组件服务.数据实现融合，以标准化的治理的数据存储于数据库或数据平台之中，彻底解决了数据散落的问三S.不再有一个一个独立的单体系统，而是实现了高度豆用的中台服务和前台轻量应用客户端.根据业务需要通过服务编排敏捷响应业务变化需求.业务限务业务啜务业务服务技术服务暨务1数据库技术服务一1可女用
10、服务提取、沉淀数据仓库系统架构演化趋势明确区分中台和平台的好处第一、明确了中台和平台的概念和区别，在进行中台建设时就能有的放矢,不会混淆.中台是从架构角度来说的，明确了中台架构，也就知道了架构的前、中、后台各是什么，就有了明确的方向.建中台就是建设可豆用服务”,这使中台建设的目标非常明确,有了可复用服务，就能通过编排来快速构建业务应用.随着可且用服务量的增加，会带来业务应用研发质的变化.第二、松帮合了平台和中台可豆用服务,明确了可且用能力的粒度。以平台作为可复用膜次，则显得粒度过粗,在复用时也需要很多额外的工作.比如说消息平台，是可且用于各个业务系统的.但要使用这些平台，需要使用其提供的API
11、来实现对接，API一旦变动，则使用这些API的服务就需要改变，这就带来了很多工作量.而在平台之上提取、抽象、封装一层可且用服务，源于平台而高于平台，比如,消息批量发送服务，其支撑平台可以是Kafka、RabbitMQ,ActiveMQ等等，则通过封装的可且用服务API可直接用于业务应用的编排。底层平台的变化对业务应用来说是透明的.不可见的.第三、中台和平台分留,则更好地实现自主可控，不再受制于人.松耦合中台可系用服务和平台之间的关系，则在更容易更换中台下的支棒平台，对上层业务应用不可见，从而根据需要而采购或研发支撑平台，不再因为受制于某厂商的产品而迟迟难以有进展.第四、契合系统架构演化趋势.自云计算解决了算力问题，我们可以不需要过多关注基础设施资源.不管通过ESB集成，或者通过微服务重构，都在解决业务、数据、组件的融合豆用问题.系统架构演化趋势是从单体架构走向分布式融合架构.中台服务架构提供了一种可行的分布式融合架构落地方式，为企业业务系统的架构和建设提供了可行方案.
