科技动态

大中台(1.10)

在整个微服务架构,平台 应用的构建模式下,对于中台如何构建始终都是一个重要的关注点。中台本身就体现了SOA和业务的思想,体现了大架构规划设计中的微服务模块划分和服务识别。在前面自己也写过一篇关于微服务架构中台构建的文章,今年对于大中台的构建和思考将是一个重点。

对于大中台,可以看到谈的最多的仍然是在互联网电商类应用中,电商上层的业务应用类型太多,变化也快,需要有一个稳定,可共享,可复用的能力中心来提供中台能力。而对于各类运营商和服务商,类似电信运营商,大中台的构建更多体现在BSS域,即面向C端客户或政企B端客户的时候,渠道,网厅客服和业务办理,电商,自服务APP等,也都需要一个完整稳定,可共享能力的中台。

也就是说前台响应业务变化的需求也迫切,对敏捷的要求越高,越是需要有强大的中台能力支撑。共性的东西,基础可复用的东西我都不需要考虑,只需要考虑如何去应用能力和组装能力。

1. 大中台首先是一个由业务变更催生的业务概念

当我们一谈到中台的时候,很容易想到我们整体IT分层架构中中台层的构建,但是大中台首先是一个业务概念,要在业务上理解大中台产生的背景,导致的业务和组织架构变革,才能够更好的理解后续大中台如何构建。要明白,技术一定都是为业务和流程服务的,业务和流程首先要变更,技术只是如何更敏捷的支撑而已。

对于大中台,摘录知乎东子的部分回答

https://www.zhihu.com/question/38278138/answer/164057098

什么是“大中台、小前台”

关键词:精准打击、管理高效、资源整合、灵活敏捷

阿里巴巴
“大中台、小前台”机制的提出,某种程度上是从传统的事业部制向准事业部制的转换。就阿里巴巴而言,“前台”就是贴近最终用户/商家的业务部门,包括零售电商、广告业务、云计算、物流以及其它创新业务等;而“中台”则是强调资源整合、能力沉淀的平台体系,为“前台”的业务开展提供底层的技术、数据等资源和能力的支持,中台将集合整个集团的运营数据能力、产品技术能力,对各前台业务形成强力支撑。

前台和中台本质上是工作分工的问题。比如,某部门要开发一款App,是部门内部(大前台)自己组织一套技术、产品、设计、运营的团队,还是集团为其提供资源(大中台),由专门的技术团队来帮助其开发、设计产品等等。

所以说, “小前台 大中台”的运营模式,就是美军的“特种部队(小前台)
航母舰群(大中台)”的组织结构方式,以促进管理更加扁平化。

十几人甚至几人组成的特种部队在战场一线,可以根据实际情况迅速决策,并引导精准打击。而精准打击的导弹往往是从航母舰群上发射而出,后方会提供强大的侦查火力后勤支援。所以如果中台没有办法承接前线的需求,前线就会不认可它服务的价值。

原因、解决的问题

关键词:组织膨胀、避免重复、加强集权、管理高效、资源整合、灵活敏捷、存在风险

当我们开展具体的业务时,每个团队都需要有技术、产品、市场等方面的基础支持,传统互联网公司的每个业务部门都会有自己专属的业务、市场、产品等人员。随着公司的发展壮大,许多业务部门内提供基础支持的工作可能会有很大程度上的重复(例:两个相互独立的业务部门同时开发APP,两个团队很可能在同时开发同样的功能,重复解决同样技术问题,同时写差不多的代码),信息不能共享,导致许多资源被浪费。

并且,每个业务团队的水平参差不齐,怎样使每个团队都能够在既保证质量、又保证效率的前提下完成任务。为此,我们 急需一个有效的机制来将公司内部的技术、数据、产品等资源进行整合,统一为业务线提供支持和帮助
。同时,各事业部就像一个个子公司,都是实行独立核算,导致各事业部往往从自身利益出发,影响事业部之间的协作,难以形成企业合力。

阿里巴巴近年来迅速扩张、员工众多,所以可能会存在管理不善、效率低下、各事业部各自为政等问题。为了解决以上问题,阿里提出了“大中台,小前台”机制。 “小前台
大中台”的运营模式促使组织管理更加扁平化,使得管理更加高效,组织运作效率提高,业务更加敏捷灵活:

其“中台”的设置就是为了 提炼各个业务条线的共性需求,并将这些打造成组件化的资源包,然后以接口的形式提供给前台各业务部门使用
,可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷,最大限度地减少“重复造轮子”的KPI项目。前台要做什么业务,需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发,而是 在底层不变动的情况下,在更丰富灵活的“大中台”基础上获取支持,让“小前台”更加灵活敏捷
,让每一个新的前台业务创新能够真正意义上“站在阿里巴巴这个巨人的肩膀上”,而不用每次开辟一个新业务都像新建一家创业公司那么艰难。

2. 从业务到技术,技术要和业务匹配

前面在将大中台的时候,从业务概念和业务变革上面可以看到,业务的目标很简单,就是要资源整合共享,要敏捷灵活和快速响应,要扁平化和管理高效。而这些最终在通过IT架构和应用系统落地的时候,这些刚好也是IT建设的关键目标。

如果业务上谈大中台 小前台,那么在IT应用架构里面可以谈厚平台
轻应用。

其中大中台为企业内部大的业务职能中心,对于到厚平台层能力中心提供;而对于小前台为前端的各类创新业务,对应到IT应用架构中的轻应用。

在平台
应用的构建模式中,有一个关键点就是高效和敏捷,可以看到类似前面经常谈到的DevOps实现开发运维过程一体化和自动化,提升高效敏捷;而对于微服务架构,中台和前台分层,组件化和模块化,则更多的是能够更好的通过组装来响应前端业务。中台和前台分层,中台的核心是提供各种共享能力,而前台的核心则是快速的组装和组合这些能力。这也正是SOA架构的核心思想。

可以再看下原来我们对SOA架构核心的理解,强调最多的就是业务能力组件化和组件能力的服务化,而对于SOA定义里面的两个关键点, 一个是找到服务,一个是组装服务。

1. 找到服务:中台的各个中心或微服务模块如何划分和定义,每个微服务模块应该暴露哪些接口服务能力。

2. 组装服务:上层应用应该如何去消费这些服务,应该如何根据业务去组合和组装这些服务。

中台最终提供可共享,可重用的能力中心,而前台则是去使用和消费这个能力。中台和前台,更加中间的这个能力服务层,实现了高度松耦合特征。正是这种松耦合,实现了高效,敏捷和灵活性。

3. 应用架构-中台模块应该长什么样子?

这个是需要进一步阐述和讲清楚的问题,因为这个不讲清楚容易产生误解。即在整体微服务架构化后的中台各个中心,类似产品中心,客户中心,计费中心等。

要意识到这里的中台仍然是一个完整的应用,而不仅仅是逻辑层,仅仅是接口服务能力暴露,当然也有特殊场景,但是大部分场景下各个中台的模块都是自带前端的,本身也是一个能够完成自内聚的一个业务模块。比如说订单中心,这个中台模块既可以通过前端各类电商或APP应用通过接口导入订单,但是其本身也具备完整的订单管理功能。是一个完整的应用。

正式这个原因,我们谈中台和前台,而不是谈中台和前端,对于前台而言同样的道理,也是一个完整的应用模块,这个应用模块仅仅是调用了中台层各个模块的接口服务能力而已。而不仅仅是我们开发单个系统的时候说的前端开发,这样理解就有问题了。

这个前台,虽然很多基础能力不用自己提供,不用自己做了,但是仍然还有大量的业务规则和逻辑处理,还有基于这些业务逻辑处理带来的服务组装和组合,这些工作仍然要在前台模块来完成。同时前台模块本身仍然也是自带自己对应的数据库,存储一些基础元数据和过程数据。

从大IT应用架构看,我们分层规划的中台和前台,都是独立的各个微服务应用模块,对应每个微服务模块一般都自带完整的数据库
业务逻辑(或叫领域服务层)
前端。到了一个单独的微服务模块内部,这个时候你的业务逻辑层可以独立打包,你的前端开发可以独立打包,这个时候才是我们传统讲的比较多的前后端分离。

再和IT团队架构对应,对应各个微服务模块的开发对应的是团队分工,不同的微服务模块可以由不同的团队来完成,而对于微服务模块里面的各层开发则对应到团队里面的角色岗位分工,可以有专门的前端开发,DB开发和逻辑层和接口服务开发人员。

阅读原文...

人月神话的BLOG

吴昕卖惨上热搜:走不适合的路到底有多难?

上一篇

A sampling of networking gear from CES: TP-Link goes Wi-Fi 6, D-Link goes 5G

下一篇

您也可能喜欢

评论已经被关闭。

插入图片
大中台(1.10)

长按储存图像,分享给朋友