阿里大中台小前台架构（阿里 中台架构）
今天给各位分享阿里大中台小前台架构的知识，其中也会对阿里 中台架构进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
IT信息系统对企业核心竞争力的支撑
前几天参与了公司组织的”引航计划“培训。
公司TOP分享了，”新零售战略漫谈“。
品牌事业部TOP分享了，"品牌管理，企业变革对于管理者的挑战与机遇”，如智能智造对品牌的挑战与机遇。
两位TOP分享的都是技术变革所引起的企业变革的话题。
让我印象特别深刻的是两位TOP对于变革都是积极拥抱的，变革的第一性原理都是
"一切以顾客为中心，以满足顾客需求为目的”。
这让我陷入深思，
企业的核心竞争力是 ”快速响应“、”挖掘“、”引领“顾客的需求,一切以"顾客(用户)需求"为中心。
哪么信息系统建设的原则也是必须支撑企业的核心竞争力来搭建。
目前我们公司搭建的信息系统如何?
能否支撑未来企业的高速发展?
如果需要变革或优化，方向又是什么？
工业时代，信息化建设一般以"前台+后台"的平台化架构来搭建，所有的软件系统都是基于这种方向来规划、设计。
一、前台、后台系统的定义
前台，每个前台系统就是一个用户的触点,是用户直接使用或交互的系统。
例如，网站、手机APP、微信公众号等都属于前台范畴。
后台，每个后台系统管理企业的核心资源(计算+数据),以规范处理企业底层核心资源和企业的核心可追溯单据为主要目的(采购、销售、财务订单等)，它们的变更需要严瑾的申报审批流程和更高级别的测试部署要求，天然导致它们变更频率低、变化成本高、变化周期长。
例如，财务系统、OMS系统、客户管理系统、仓储物流管理系统等。
基础设施、计算平台作为企业的核心计算资源，也属于后台的一部分。
前台、后台系统来源有两种
1、花大价钱外采，实施，需要每年支付大量的服务费，定制化困难。
2、花大价钱自建，一身的补丁，年久失修，同样变更困难。
有人会说，现有的版本较低，可重新搭建新的后台系统。
但是由于前、后台系统天然的特性，重建也只是推倒了一个“烟囱”，只是新建一个差不多的“烟囱”,建的越多，后期的运维会越艰难（天港城、DRP、AFS、FMS等)。
二、前台+后台系统框架的僵局
"前台系统"是用户直接使用或交互的系统,而企业的核心竞争力是 ”快速响应用户的需求"。
所以前台系统为 用户而生 ，需要快速的创新迭代、越快越好。
“后台系统"的目标，主要是为了实现企业资源的数字化管理，解决企业管理的效率问题，而不是完全为了服务于前台系统。
后台系统往往是稳定至上，越稳定越好。
前台系统是需要快而美，快速迭代。
这样前台、后台系统的的配速不区配。
而企业会不断发展，顾客(用户)需求的不断变化，后台修改的“成本”、“危险”也只会越来越高。
后台系统对于变化，天然会选择保持稳定性与可靠性，响应速度会越来越慢，甚至无法响应，或者将很多的业务逻辑不断的加到前台系统，造成前台系统不断膨胀，渐渐拖垮前台系统，同时用户的满意度下降，企业的竞争力自然也随之下降。
这样前台需要的快而美、后台系统的稳定可靠天生就陷入僵局 。
我们公司是不是也慢慢体现这种特点?
顾客需求多、变动频繁，而信息平台的响应速度也是越来越慢? 或直接说NO?
哪有没有解决之道？或有没有路径来处理？
移动互联网时代的弄潮儿，国内毫无疑问是阿里、腾讯、华为等。
其中阿里从最初的淘宝、天猫、支付宝、蚂蚁金服、阿里云等，业务不断扩展，阿里的技术团队在业务的不断摧化下，经过多年的努力，将自己的技术和业务能力沉淀出一套综合平台（大中台、小前台的系统框架)，具备了对前台业务变化及创新的快速享应能力。
阿里的信息平台中，引入了中台的业务架构。
中台业务架构是将一些基础公用的业务服务抽像出来，形成 共享平台 ，提供给所有的前台业务使用。
一、中台定义
中台为前台而生，目的就是更好的服务前台规模化建设，更好的响应服务引领用户。
前台系统中的通用业务能力"沉降"到中台，为前台减肥，恢复前台的响应力。
后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本。
中台是在“前台”与“后台”之间添加一组变速轮，将前台、后台的速率进行区配，在”前台“与”后台“之间搭建桥梁，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台作为桥梁，链接了用户与企业核心资源，可以将业务沉淀在中间层，覆予这些能力更强的灵活度和更低的变更成本，为前台提供强大的能力炮火。
二、中台的核心价值
1、以用户为核心的持续化创新能力，是中台建设的核心目标，业务响应能力和创新能力，是互联网时代企业综合能力的核心体现。
2、中台建设根本上是为了解决企业响应慢困境， 弥补顾客需求快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾，沉淀业务能力，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应速度。
在未来企业信息化平台的建设过程中，我们需要建设自己的中台层。
公司现建立了比较强大的信息化平台,如SAP、OMS、CRM、WMS、SRM、POS、OA等。
也建立了较强大的系统流程运维、研发团队，有较强的软件项目开发、运维经验。
随着新技术发展（如移动互联网、物联网等）、顾客生活方式的变化、人工材料成本上升、个性化需求等各种因素，公司战略也会变动，相应的信息化系统为了支撑业务的变化也会调整。
如最近公司"新品牌"的创建，就是为了适应这种变化，对于这种变化，信息化平台如何变化，我的思考如下（仅是我个人思考，有可能全是错的）
新品牌
一、顾客定位，相对于现有品牌顾客会 年轻、更爱美、有个性、有相应的经济能力，是随着互联网发展成长起来的群体。
二、产品定位，相对于现有品牌价位会偏低，多样化、年青化、舒适。
三、销售渠道，线上线下融合，购物更方便、快捷、售前、售后体验好。
四、供应链渠道快捷，可直接采购、或外协加工，供应链需敏捷反应。
信息系统规划及方向
顾客年青化、线上线下融合、敏捷供应链，基于互联网时代的特性，信息系统的搭建也需要基于"共享服务中心”的IT架构来实施、搭建。
“共享服务中心”的IT架构。
一、可以避免重复功能的建设、维护带来的成本浪费。
二、可以最大程度避免需要打通不同系统间实现业务交互带来的集成协作成本（如SAP、OMS、WMS、POS、CRM等）。
三、业务可持续沉淀、形成可重用的服务中心，为业务的快速发展、创新带来价值。
四、可以让企业具备跟互联网企业一样的业务快速创新、试错的能力。
五、信息中心，往核心业务和数据运营团队进化，更快、更好的支持业务发展，培养即精通业务，又熟悉技术的复合型人才。
2019年或之后的很长一段时间，我们应搭建相应“共享服务服心”
一、统一库存服务中心
统一库存共享和分配的过程，提高库存的管理能力，实现全渠道库存的可视、可控。
二、统一会员服务中心
统一各个业务线分散的用户体系，统一用户数据、存储及服务接口。
三、统一商品服务中心
商品是所用用户、系统的入口，对数据的质量要求很高，高质量的数据是所有业务的基础
四、统一的交易服务中心
交易业务领域的服务中心，包括交易流程、订单管理、结算、营销、评价等。
五、统一的物流服务中心等一系列的中心
服务中心构建好后，相应的“全渠道销售平台”信息平台，自然也水到渠成。
共享服务中心的IT架构，在前台、后台系统之间搭建中台，会更快、更好的响应顾客需求、提升组织效率。
同时共享服务中心的搭建，对于研发组织、研发流程有新的优化与要求。
应避免或淘汰目前的“项目制”的实施SOA的误区。
系统融合
系统融合，简单的说就是把多个系统合并成一个系统。
组件化”的结果就是把系统作为一个个“组件”独立部署并对外服务，我理解的系统“组件化”，其实是对系统 “服务化”或 “微服务化”的另一种称呼罢了。区别在于“组件”是对外的“服务”，有些“服务”是私有的不能对外。
这里封装了一个组件名称为“组件1”，包含3个子服务系统，其中A服务对外开放，B、C服务是为了支持对外的A服务而存在的，但不对外开放。这里采用了“微服务”的思想把“组件1”拆分为三个子系统，有点类似java里的public方法和private方法，A系统对应public方法可以对外服务，B、C系统对应private方法只能在“组件1”内部被调用。这里所谓的服务都是通过RPC框架搭建的子系统。
新增一个“前台业务”，只要“中台系统”足够强大，新业务可以通过调用各个公共的“组件”采用类似搭“积木”的方式，快速完成一个新业务系统开发。这应该就是阿里所谓的“小前台”、“大中台”理论基础。
好处就是快速上线、快速试错，“前台系统”只需要投入少量人力成本，就可以快速完成新产品的研发和上线，根据市场的反应再做调整。
前面提到的“前中台系统”建设，是站在公司组织架构层面来划分的。个人认为 在各自所在的项目组，也可以采用这种“组件化”的思路来进行子系统拆分，在项目组内有自己的“前中台”子系统，不管这个项目是否在组织架构上属于“前台”还是“后台”。在具体项目内部进行“前中台”子系统拆分，其实有点类似“微服务化”拆分
上图中的“jsf服务子工程集”中的每个子工程都可以作为“组件”来看待（只是这个组件只有1个工程，但根据业务需要对每工程还可以继续模块化拆分），属于“中台系统”。
上图中的“web服务子工程集”其实就对应各种业务系统，通过调用各种基础服务堆积而成，属于轻量化的“前台”系统。只要“jsf服务子工程集”中的“组件化”做得足够强大，我们就可以在项目组最大化的复用这些公共组件，更少的人力投入，快速的实现业务开发。
在这个项目“组件化”之前，是按照业务对系统进行划分，分为pc店铺、pc活动、m店铺、m活动，系统划分如下：
采用组件化的思想对系统架构进行改造，分别对前、后端都进行“组件化”提取，把公共的功能模块提取为“组件”单独部署。具体的业务系统调用这些公共组件达到复用的目的。改造后的系统架构如下：
todo
两个系统融合，最大的困难就是接口不统一
比如同样是商品接口，A、B两个公司的接口名可能不同，商品类的定义也不同。这时为了让外部系统调用这两个接口无感知，就需要一个统一的接口，这就产生了适配器模式。
在“系统融合”的场景中会为同一个接口创建多个Adapter适配器（这里是两个），分别对应多个类似业务。这里以A、B两个电商系统融合为例，两套系统有数十个接口我们需要在A、B两个系统之上新建一个“适配器”系统。为了顺应现在的“前中台系统建设”潮流，设计架构上对前中台进行区分，整体架构调整如下：
在A、B两个系统没有融合前，他们都各自对应自己的前台系统，架构说明如下：
1、A、B两个公司合并前，都有各自对应的前台系统和中台系统。如图中“绿色箭头”所示。
2、现在A、B两个公司合并，为了降低维护成本，以及增加用户体验，只维护一个前台系统。为了在系统融合期间，外部用户可以正常访问A、B前台系统，这里增加一个“新前台系统”。
3、同时为了兼容老数据，A、B两个系统保持原样不变，新增一个“适配器系统”，对A、B两个系统中的公共业务接口进行适配。接口调用流程，如上图中“红色箭头所示”，统一后的“前台系统”首先调用“适配器系统”，根据参数适配到A或B系统中。
4、A、B两套系统在融合前 虽然业务类似，但也就自己的个性化业务，统一后的“前台系统”直接调用A、B系统原接口即可。如上图中的“紫色箭头”所示。
5、当“新前台系统”开发完成并上线后，即可关闭两个老的前台系统。只维护一套“新前台系统”即可
通过上述系统架构，即可快速完成新系统的融合，又不影响老系统的访问，为了防止老客户对新系统的不适应，还可以让“三个前台系统”并行运行一段时间。是不是有种“酷毙了”的赶脚。
这个强大的系统架构设计的核心就是设计新的“适配器系统”，这个系统里设计有多个数据接口（A、B系统公共的接口），每个接口都是采用“适配器模式”对A、B两个系统的接口进行封装，让“新的前台系统”以为是一个接口。
下面就以“商品接口”为例，对“适配器模式”进行讲解。
根据上述新系统架构，主要分为4个系统：“A系统”、“B系统”、新“适配器系统”、新“前台系统”。作为示例不会把4个系统都搬出来，这里使用一个java application程序进行模拟，如下：
其中两个老系统的商品类ProductA、ProductB业务很类似：
ProductB中多一个成员变量venderId（商家Id）。现在要在新“适配器系统”中，定义新商品类Product，需要包含两个系统中所有业务，定义如下：
新商品对象定义完毕，现在进行接口“适配”，这里以A系统商品接口为例（B系统类似）;已有的被适配角色ProdcutManagerA（接口）、ProdcutManagerAImpl（实现类）：
新接口：新接口返回类型是新商品类Product：
可以看到ProdcutAdapterAImpl适配器，把“A系统”商品接口 转换为“新前台系统适配的”接口。
但在真实的系统中通过引入RPC框架和Spring IOC注入，“新前台系统”只会依赖一个“适配器”接口类：ProdcutAdapter；同时新建的“适配器系统”只依赖老A、B系统的接口类：ProdcutManagerA、ProdcutManagerB。如下图所示：
在两个系统融合过程中，还经常遇到另一种情况：A系统返回的商品列表是ArrayList类型，B系统返回的商品列表是数组类型。
这就是所谓的“聚合类型兼容性问题”。这时为了统一接口类型，可以在“适配器系统”把ArrayList转换成数组，或者把数组转换成ArrayList。但这不是最优雅的方式，我们还可以使用“迭代器模式”对两个接口进行兼容。Java中得聚合类型：数组、List、Set、Map等。
迭代器模式提供一种顺序访问一个聚合对象中的各个元素的方法，而又不暴露其内部的表象。把遍历聚合中各个元素的任务移交到“迭代器”上，满足OO设计原则中的“单一责任原则”。另外具体的“迭代器”都实现自一个统一的接口（Iterator），可以兼容不同的聚合类型遍历（这就是解决本文开头“兼容性”问题的关键）。
简单的理解，就是把聚合类型中遍历每个成员的任务剥离出来，生成“迭代器”，这些迭代器都实现自同一个接口。类图关系：
从类图上看，该模式主要有4类角色：
抽象的聚合：AbsAggregate，可以是抽象类 也可以是接口。一般都会定义一个抽象方法，获取迭代器。
具体的聚合：ConcreteAggregate，实现或继承自AbsAggregate。一般都会实现AbsAggregate中的抽象方法，获取具体的迭代器。
抽象的迭代器：Iterator可以是抽象类 也可以是接口。一般最少有两个抽象方法，hasNext()和next()方法，用于遍历聚合中的元素。
具体的迭代器：ConcreteIterator，实现或继承自Iterator。对hasNext()和next()方法进行具体的实现。其构造过程依赖“具体的聚合”，也就是说每个“具体的聚合”，一般都会对应一个自己 “具体的迭代器”。
回到文章开头，开始使用“迭代器模式”对A、B两个系统融合过程中，对两个不同的获取商品列表接口进行融合。为了方便理解，实现过程按照“迭代器模式”的4类角色 分类进行：
Java中的迭代器：Java的API中对大部分的聚合类型都已经默认实现了自己的迭代器，统一实现自接口java.util.Iterator,相比本示例中定义的Iterator，java.util.Iterator多了一个remove方法。
Java api中几乎已为所有的聚合类型创建了自己的迭代器，并且都实现自java.util.Iterator接口。如果要扩展自定义聚合类型的迭代器，直接实现这个接口即可，这样做的好处是可以跟java api中的聚合类型的迭代器完全兼容。
Ref:
“小前端，大中台”是什么意思？
1.什么是“大中台、小前台”
关键词：精准打击、管理高效、资源整合、灵活敏捷
阿里巴巴 “大中台、小前台”机制的提出，某种程度上是从传统的事业部制向准事业部制的转换。就阿里巴巴而言，“前台”就是贴近最终用户/商家的业务部门，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而“中台”则是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。
前台和中台本质上是工作分工的问题。比如，某部门要开发一款App，是部门内部（大前台）自己组织一套技术、产品、设计、运营的团队，还是集团为其提供资源（大中台），由专门的技术团队来帮助其开发、设计产品等等。
所以说， “小前台+大中台”的运营模式，就是美军的“特种部队（小前台）+航母舰群（大中台）”的组织结构方式，以促进管理更加扁平化。十几人甚至几人组成的特种部队在战场一线，可以根据实际情况迅速决策，并引导精准打击。而精准打击的导弹往往是从航母舰群上发射而出，后方会提供强大的侦查火力后勤支援。所以如果中台没有办法承接前线的需求，前线就会不认可它服务的价值。
2.原因、解决的问题
关键词：组织膨胀、避免重复、加强集权、管理高效、资源整合、灵活敏捷、存在风险
当我们开展具体的业务时，每个团队都需要有技术、产品、市场等方面的基础支持，传统互联网公司的每个业务部门都会有自己专属的业务、市场、产品等人员。随着公司的发展壮大，许多业务部门内提供基础支持的工作可能会有很大程度上的重复（例：两个相互独立的业务部门同时开发APP，两个团队很可能在同时开发同样的功能，重复解决同样技术问题，同时写差不多的代码），信息不能共享，导致许多资源被浪费。
并且，每个业务团队的水平参差不齐，怎样使每个团队都能够在既保证质量、又保证效率的前提下完成任务。为此，我们急需一个有效的机制来将公司内部的技术、数据、产品等资源进行整合，统一为业务线提供支持和帮助。
同时，各事业部就像一个个子公司，都是实行独立核算，导致各事业部往往从自身利益出发，影响事业部之间的协作，难以形成企业合力。
阿里巴巴近年来迅速扩张、员工众多，所以可能会存在管理不善、效率低下、各事业部各自为政等问题。为了解决以上问题，阿里提出了“大中台，小前台”机制。“小前台+大中台”的运营模式促使组织管理更加扁平化，使得管理更加高效，组织运作效率提高，业务更加敏捷灵活：
其“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。前台要做什么业务，需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发，而是在底层不变动的情况下，在更丰富灵活的“大中台”基础上获取支持，让“小前台”更加灵活敏捷，让每一个新的前台业务创新能够真正意义上“站在阿里巴巴这个巨人的肩膀上”，而不用每次开辟一个新业务都像新建一家创业公司那么艰难。
3.具体做法
关键词：组织架构调整、整合支持、网状结构、设立中台事业群、业务小前台
（1）阿里巴巴的组织架构调整
一直以“拥抱变化”著称的阿里巴巴，于2015年12月7日公布了新一轮组织调整。已经拥有3万员工的阿里巴巴将此前的“树状”管理模式改为“网状”，成立整合数据、搜索等技术平台的“中台事业群”，对前台各业务模块进行整合支持。
【整合前（2013年）阿里巴巴组织架构】
2013年的阿里巴巴把具体业务划分为了9类，并对每一块的业务进行了很明确的细分，共下设25个事业部，分别由9名事业部总裁负责。这时的组织架构是较为传统的树状结构
【调整后阿里巴巴的组织架构】
2015年经过调整后阿里巴巴的组织架构不再是传统的树状结构，而变成了网状结构。同时，其不再采用具体的业务模块下分设事业部的方式，而是将之前细分的25个事业部打乱，根据具体业务将其中一些能够为业务线提供基础技术、数据等支持的部门整合成为“大中台”，统一为业务线提供支持和帮助。
4.问题与建议
【问题】
① 中台无法为前台提供其想要的支持和帮助
首先，是因为资源有限，中台无法为前台提供其想要的支持和帮助。在开展业务的过程中，各前台会向中台提出需求，因为中台的资源有限，所以当中台收到许多来自前线团队提出的需求后会进行评估。如果其认为某个前台项目的重要程度比较低，拒绝为前台提供支持。那么这个前台可能会为自己的业绩考虑去自行组团队完成项目，这就与传统的事业部制没有什么区别了。所以说，如果中台和前台没有找好平衡点的话，这种机制很容易被破坏。同时，也存在中台能力受限无法为前台提供有力支持的情况，最后项目做出来的效果可能与前台所想相差甚远。
同时，此制度受限于中台的知识沉淀的能力，沟通协调能力和其对前台知识理解的能力等，这些都是非常大的挑战。
② 中台和前台分工不明确
中台和前台之间存在许多灰色地带，这个时候就会出现分工不明确的问题：哪些工作是属于前台的，哪些工作是属于中台的？面对某一具体业务时，这一块任务是应该让中台来为业务线提供支持，还是让业务线自己做？如果中台和业务线都去完成这个任务，工作上会不会有重复？会不会有前台和中台之间互相推诿“踢皮球”的情况发生？
③ 传统的绩效考核方式不再适用
中台用怎样的标准去衡量前台的业务值不值得提供支持？以什么为评估依据去分配资源？如果中台为许多小前台提供了差不多的支持，而最后只有一个小前台完成了业务目标，利润要怎么分配？如果所有小前台都没有达成业务目标怎么办？
【建议】
关键词：重建绩效考核体系 、划分清楚灰色地带、进行培训、评估过程标准化
针对以上三个问题，我提出了以下解决方法：
① 最大程度上对资源进行整合：以保证中台能够为各个小前台提供强有力的支持。
② 建立评估部门，将评估过程标准化：组建专业的评估部门去对小前台开展的业务进行考察和评价，并根据评估结果向中台提出建议，使中台能够将资源合理分配。
③ 建立业务bp岗位（类似hrbp）：深入前台了解前台的业务需求并反馈给中台，在前台和中台中起到沟通和协调作用，以免前台、中台有重复完成同一工作或“踢皮球”的情况发生
关于阿里大中台小前台架构和阿里 中台架构的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
陕ICP备2021009819号