什么是云原生中台业务架构？

什么是云原生中台业务架构？

最近公司说要做中台架构，业务中台，技术中台，数据中台，很谦虚的请教一下，什么是业务中台？业务中台是什么样子的，它是一个什么样的产品，是一个个的业务系统吗，业务中台还有没有后台系统呢

不同的团队对中台有不同的理解，但中台项目要成功，还是有必要对中台的概念做一个比较准确的定义。
网易副总裁、网易杭州研究院执行院长汪源的观点：
中台是支持多个前台业务且具备业务属性的共性能力组织。
三点含义：
1. 中台必须具备业务属性。
2. 中台是一种共性能力组织，支持了多个业务。
3. 中台支持的是多个前台业务。
业界常说的中台，包括业务中台，数据中台、用户中台、搜索中台、推荐中台、技术中台、组织中台等，根据这个定义，容易知道：
1. 所有中台都是业务中台，没有别的类型的中台。
2. 数据中台、搜索中台、内容中台、零售中台等等，都是特定形式的业务中台，也还是业务中台。
3. 技术/算法/移动/研发中台当前基本不存在。

当前最需要建设的中台有两种：
· 狭义的业务中台：一般指在线业务为典型特征的中台。在OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。
· 数据中台：一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。
对业务中台来说，比较符合的场景主要有：
· 业务系统研发团队至少大几十人（含外包的），需求多变化快，系统又涉及多个领域（比如做ERP、电商的），业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚，提高研发效率。
· 做相似行业的外包项目为主，业务规模也做的比较大的（一年有两位数的项目）。这时业务中台可以提升软件复用，降低定制化成本，提高研发效率。如果你做外包，每个项目都完全不一样，那中台也救不了你。
对数据中台来说，比较符合的场景：
· 数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。尤其是数据产品和运营人员还在多个团队。
· 用数据的姿势比较复杂，问题比较多，比如经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题。
网易杭州研究院建设中台，源自并行支撑多个业务的需求，追求技术体系化，对抗重复建设，建立共享能力团队，提高创新的速度和效率，提高成功率。
要建设中台，需要考虑组织、支撑技术、方法论这三个方面，往往还需要咨询服务。
支持业务中台的技术体系，包括微服务、DevOps、云原生和分布式事务等，在网易，是网易轻舟微服务平台，提供微服务应用全生命周期的完整支持，包括下一代微服务Service Mesh支持、经典微服务框架NSF、包括CI/CD的DevOps、分布式事务框架GXTS、APM、API网关、GoAPI全自动化测试以及容器应用管理服务等。
支持数据中台的技术体系，包括指标管理、数据服务、元数据管理、数仓开发与管理、数据安全管理、数据资产管理、大数据计算引擎、数据集成/同步/交换引擎等，在网易，是以网易猛犸为核心的网易全链路数据中台解决方案。
关于中台的全面科普，可以参考汪源的中台系列文章，系统地回答了什么是中台、怎么建中台的问题，并给出了网易杭研的实践案例。
· 什么是中台？所有的中台都是业务中台
· 如何建设中台？中台建设的组织、支撑技术和方法论
· 互联网公司的中台实践：网易杭研的中台往事

看了很多答案感觉还是有点高深，我摘取我的书中的一个生活化例子来解释下什么是中台：

一、什么是前台，后台

在以往的互联网企业生产流程中，我们可以将研发团队宏观的划分为前台与后台两部分。
所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等。
用户对产品的认知与体验也由此而生。比如大家对于微信的理解就是这个前台APP展示的一切给大家描绘的：一个绿色图标的应用，里面有我的A、B、C好友。
而后台包含两个部分：

1. 企业的内部管理服务的统称，如：内部的CRM，ERP等；
2. 为前台提供服务能力的，如：数据压缩能力，并发等。
   后台最重要的特点就是其提供的服务都是不被普通用户所感知的，就像用户不会因为应用的并发，传输速度而记住微信这个品牌。
   在搞清楚了前台与后台的概念后，前后台模式的产品服务模式我们就可以用一张图来概括描述：

图1
总的来说就是在应用中后台提供能力与计算，前台将后台的能力进行封装以图形化的形式展示给用户，让用户能更容易的使用公司提供的服务来解决个人需求。

二、中台的白话解释

在开始谈论中台之前，我们先要明白：当下的主流前后台模式并不是在业务实现上出现了问题，不支持眼下出现的种种新业务场景；相反地，这种前后台反而是公司最省事省力的一种提供服务的解决方案。因为这种模式不需要提供额外的建设，前台完成信息展示与交互，后台做好对应需求的解决逻辑就组成了一个产品。
实际上，中台的出现更多是因为公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。
在互联网进入日益复杂的市场环境的今天，市场中由于存在众多的竞争者，也逼迫着企业需要不断去更新产品去抢夺市场。
而作为实际用户真正接触的前台业务，如：APP、小程序、网站等，必须要快速迭代新的功能才能让用户感知到。
而在这个大背景下带来的矛盾就是——以往为了支撑前台越来越多的业务，后台不断地建设庞大起来的系统，由于一直在追求稳定性而生，反而在这个时候显得越发笨重起来。这样的后台变得越来越没法去快速响应前端变化所带来的改变。原来的前后台模式的这种直接关联决定了两者的冲突不可避免。
例如：传统我们的一个电商网站，由于用户前端需要组织各种新的销售方式（拼团，一元购等），导致每次活动页面开发的时候，不仅需要前端重新设计页面，从后台接口提供与数据表都要重新设计。
这无疑大大拉长了我们的需求响应时间，很有可能会导致在活动模块还没开发完成，我们的风口就已经过去了。因此我们需要一个能最少改动就能完成大部分需求的解决方案，这就是中台。
中台解决方案到底是什么呢？让我们举个通俗的例子来说，如果将互联网公司的研发中心比作一个厨房，将研发新产品的过程比做菜的话，我们就可以很容易理解这个概念了。
首先请大家想一个问题，在一家客流量非常大的餐厅中我们要如何缩短客人的等待时间呢？
相信很多人的第一想法就是增加多名厨师，但时大多数的餐厅单纯的增加厨师这是不实际的，因为每增加一个厨师是有很高成本的，而且每天忙的就是中午和晚上这两个时间点，虽然在饭点解决了问题，但是在一天中其他的时间里，厨师人员就显得非常冗余了。
而正确的做法是先将做菜这个任务拆分，让做菜这一件事变为多个环节来思考。也就是将做菜变为：

图2
通过这样的拆分后我们可以发现无论是做什么菜系，买菜与配菜都是共有的两个步骤，我们完全可以只需要增加一位配菜的小哥来代替厨师去进行前两步，这也就是现在大多数上规模餐厅的组织架构：

图3
这样我们每一位厨师新做一道菜时没有必要一定要从买菜，洗菜，切肉这些最基础的环节开始，而是完全可以直接使用他人切好的肉片，洗好的菜下锅，唯一需要关心的就是如何在搭配调料上研究不同的创意。完全可以大大提高厨师的做菜速度，同时在成本上我们只增加了一个人就解决了所有问题。
回到研发流程来看，买菜其实就是我们研发的后台，他们帮助我们解决最基础原料问题。厨师是我们的一个个业务前台团队，他们要做的就是根据不同地区口味烹饪出对应的菜系，而在业务多元化后洗菜，切菜，配菜都可以交给中台解决方案去完成，做菜的时候作为大厨只需要喊一句要什么材料既可，当然这里的配菜小哥就是我们的中台。
所以说有了中台之后我们的前台业务就可以快速尝试迭代，不需要每件事都是从0到1开始了。
让我们再站在架构的层面来看看中台对整个系统业务所起到的作用。
假设我们是一个电商平台在我们未使用中台的时候，每一个前台的用户终端都需要与后台进行一次对接，就像下图：

图4
而后台的每一个模块都需要维持与前台业务的关联，并根据不同业务前台的特征加入适配。这样造成的结果：
· 后台的每一个模块都需要加入与前台适配的部分，从而大大加大了开发量；
· 每个前端在启动时需要分别对接不同的后台模块，也加大前台启动时的工作量；
· 当后台进行升级或架构调整时还需要考虑与前台的对接，并进行逐一的调整。
当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端，同时对后台各个子系统进行统一的封装，让前台能无感知的使用各项服务而不需要单独设计通道，我们的系统也就简化成了这个样子：

图5
通过对比我们能清楚的看到中台对于公司的整个业务架构起到了非常大的简化作用。
用一句话来概括就是：中台的核心本质就是服务共享，目标是支持前台的快速创新或试错，而实现的手段是微服务架构、敏捷基础设施和公共基础服务。

三、中台解决方案

那么到这我们可以给中台解决方案下一个定义：
中台解决方案的组成 = 能力输出 + 标准化中间件
让我们来一个个解释：

第一部分：能力输出

所谓能力输出就是要规划出什么是公司的核心竞争力，理清楚公司发展的战略与目标与未来公司里的主要业务会涉及到哪些方面。并在这些业务层面中去提炼哪些模块是以共性存在的，并会在每个新开拓的业务中不断使用，然后就把他归类到中台进行建设。这也就是中台的一个重要的意义：为不同的前台业务提供可以重复使用的能力，形成一次建设多次使用。
例如我们规划了公司的核心方向是视频方向，未来可能会涉及的业务形态有：
· 在线视频
· 视频直播
· 短视频
· ……
分析上面的业务方向我们不难判断出最基础要抽取的模块可以划分为：
· 在线视频编辑
· 视频压缩
· 多人点播
· ……
完成拆分后我们就可以通过中台去实现这几个通用模块。
值得提一下的是虽然这里在说中台要考虑复用性、扩展性，但是要考虑多少，考虑多深这里又是一个非常考验产品功力的地方。
还是举上面的例子来说我在设计一个视频社区APP的积分商城系统时，需要将商城交易方式抽象为能力时，这里我们大体上可以抽象为如下三种交易方式：

表1
但是同样的疑问来了，我们仅仅为了支持一个积分商城需要将中台的复用与扩展放大要考虑引入股票交易才使用到的撮合交易模式吗？
当然这里的案例比较极端我们能快速判断，但是在具体的中台规划中我们会碰到很多这种类似的范围决策，我们必须要按照公司的核心业务规划来严格定义中台的能力，避免在中台出现过度建设的现象。

第二部分：标准化中间件（整合能力，并封装头尾）

在我们确定了公司的业务发展需要哪些能力之后，中台解决方案的另一个组成部分就是需要做一个将每个能力进行封装，形成一个统一的可供前台业务端方便使用的中间件。
这里的统一具体表现在如下的几个方面：
· 不同终端中的叫法与含义；
· 定义统一化的输入输出；
为什么要统一呢？
以往的前后台模式中同一家公司内的不同业务如：直播项目组、短视频项目组各自为战的时候，经常会出现一个事物被不同项目因为场景化的需求，而出现两个称呼的现象，但是实际上他们本质上是同一个事物。这也是原来不同项目组想要进行复用前人的模块时一个天然的巨大障碍——无法快速对接。
例如：就那一个用户昵称这个字段来看，在不同项目组中的应用中可能会叫：用户名称、用户昵称、称号、花名等等，而在数据库中又可能会有不同的字段名称：username、UN、name等等。
因此我们需要一个中心化的产物帮助我们定义好这些个通用属性，使在公司中不同的业务端都能统一。
面对这种现象，在有了中台后，我们就可以通过定义标准化的中间件来解决。以后假设公司内部孵化的项目组再次要使用用户昵称这个字段的时候，无论具体是什么业务前端都会是一个叫法、一种存储，这样不仅能直接使用之前项目的模块，同时还可以和公司内部的管理系统如CRM/BI等快速完成对接。

四、最后

在竞争日趋激烈的互联网行业中，如何低成本又快速地完成业务创新去占领市场是每个企业所追求的方向，而中台解决方案的出现给我们当下的互联网企业带来了一个全新的发展思路。

相关阅读：中台实战系列文章

《中台实战（0）：最近处处惹人爱的中台到底是什么》
《中台实战（1）：看懂企业业务演进路线》
《中台实战（2）：中台的建设核心原则》
《中台实战（3）：数据中心中台化案例》
《中台实战（4）：业务组件化设计》

其实中台严格意义上来说，不是一种架构，也不是一种系统，而是一种战略。
以前的企业发展到一定程度，需要规范化管理的时候，我们上了ERP系统，要通过供应链建设B2C业务的时候，我们上了SRM系统，仓储管理到一定规模我们上WMS，物流管理我们上TMS……整个公司各个系统功能有重叠，有交叉，内部协同成了重大问题。
这就好像我们一直在打是局部信息化战争，头痛医头脚痛医脚，需要解决什么样的问题，就上什么样的系统，最终就形成了所谓烟囱式的系统架构。导致整个架构重复造轮子，跨系统管理也给运营人员造成了不必要的时间精力浪费。
整个系统管理冗杂又造成资源浪费，这时候就需要将原有的系统规范化、一体化，通过数据总线进去进行深度的整合，打通各个信息孤岛，形成前后贯通的信息化建设。我们把这个时代称之为ESB数据孤岛时代。

而到了大中台时代，中台的核心价值是在于，在对企业业务有了柔性支撑和贯通的前提下，再形成协同与智慧的运营体系。
一般企业架构分成了三个层次：前台、中台、后台。但是**对于欧电云中台层来说，又分成三大块，业务中台、数据中台和技术中台。**技术中台支撑企业业务发展，通过打通企业内异构系统，支持业务中台；业务中台围绕公司业务运营进行服务，将获取的多维度数据传递给数据中台，由数据中台分析反馈给业务中台，以优化业务运营。同时数据中台通过BI智能分析，帮助企业管理者更好的做决策分析。三者是相辅相成，相互协作的。

（红色框中的就是“业务中台”）

你问的“业务中台”，其实就是把原有的前端的会员中心、营销中心、商品中心，后端的供应链中心、采配中心等重点模块放在业务中台模块，以后前端不管对接多少个第三方，线上线下增加多少家门店，都能进行统一会员、统一商品编码、统一供应链整合，整个系统一体化。真正做到用技术支持业务，通过业务收集大量数据进行决策，统一高效的进行管理。

一、 中台的诞生

中台战略是企业数字化转型过程中的一个热门话题。说到中台转型，企业大多对标阿里巴巴。
2015年阿里巴巴提出了“大中台，小前台”的中台战略，提出之初阿里有近 4 亿用户，为超过 1000万各类企业提供服务，业务种类繁多，业务之间相互网状依赖。同时，阿里部门也越来越多，分工越来越细，沟通过多，相互依赖，创新成本非常高，对业务响应也越来越慢。阿里需要找到能够对外界变化快速反应，整合阿里各种基础能力，高效支撑业务创新的机制。
相信很多公司或多或少都遇到过类似的问题，或者随着企业规模越来越大，也正面临着同样的问题。

二、 中台or平台？

很多IT人员在谈论中台时说：“我们在系统建设之初就已将产品、用户、权限、客户等公共模块独立成了共享的平台了，这不是中台吗？”也有很多人对中台提出质疑：“中台是个怪名词，它不就是平台吗？”
我们先了解一下阿里业务中台的发展历程。
阿里中台从业务中台和数据中台开始，后来发展出移动中台、技术中台、研发中台等。

“阿里业务中台的前身是共享平台，原来的共享平台更多的被当作资源团队，承接各个业务方的需求，为业务方在基础服务上做定制开发。”
看到这里是不是似曾相识呢。有的企业十多年前就已经完成了大一统的集中式系统拆分，将公共能力和核心能力分开建设，解决了公共模块重复投入和重复建设的问题。有的企业共享平台建设时间甚至比阿里还要早，但并没有发展成为像阿里一样的中台。
同样的起点，为什么结果会不一样？
阿里这十年经历了光速发展，同时业务领域快速扩张也增加了业务的复杂性，这种业务发展也只有像阿里这样的互联网企业才会遇到。可以说：业务的发展和复杂性推动了阿里中台的诞生。
我们再进一步来了解阿里业务中台的目标。
“业务中台是把核心服务链路 (会员、商品、交易、营销、店铺、资金结算等) 整体当作一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。”
这也是我们为什么可以在闲鱼上能直接登录淘宝、支付宝，在刷微博时也能流畅的跳转到淘宝和天猫店铺的原因。您是否感受到了这种跨平台融合能力的强大呢？
平台化只是将部分公共模块独立为共享平台。虽然平台通过API接口或者数据共享对外提供公共服务，解决了重复建设的问题，但由于这类平台并没有与企业内其他平台或应用实现页面、业务流程和数据从前端到后端企业级的全面融合，没有将核心业务服务链路作为一个整体方案考虑，各平台仍然是独立和分离的，本质上仍然为竖井式建设模式。
共享平台虽然解决了公共能力复用的问题，但离中台的目标还有一段距离！

三、 中台到底是什么？

中台到底是什么？“一千个读者就有一千个哈姆雷特”，业内提法很多。
听听阿里业务平台负责人玄难老师说说中台是什么？
“中台是一个基础的理念和架构，我们要把所有的基础服务用中台的思路建设，进行联通，共同支持上端的业务。业务中台更多的是支持在线业务，数据中台提供了基础数据处理能力和很多的数据产品给所有业务方去用。业务中台、数据中台、算法中台等等一起提供对上层业务的支撑。”
我们提炼几个中台的关键词：“共享、联通、融合和创新”。联通是前台以及中台之间的联通，融合是前台流程和数据的融合，以共享的方式支持前端一线业务发展和创新。
中台首先体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团、大到生态圈的能力共享、联通和融合的问题，支持业务和商业模式创新。通过平台联通和数据融合为用户提供一致的体验，更敏捷的支撑前台一线业务。
中台源于平台，但中台与平台比，它更多的体现在一种理念的转变，它更主要体现在三个关键能力上：
· 1. 对前台业务的快速响应能力；
· 2. 企业级能力的复用能力；
· 3. 从前台、中台到后台的设计研发、页面操作、流程服务和数据的无缝联通和融合能力。
其中最关键的是第3点：企业级的无缝联通和融合能力，尤其对于集团化的超大企业而言，这一点至关重要。

四、 传统企业如何做中台？

传统企业有别于互联网企业，阿里、腾讯等公司是互联网生态圈的创造者和流量入口，传统企业作为生态圈种群中的个体，除了需要做好原有的传统渠道业务外，还需要融入互联网生态圈，其商业模式、个体能力、与其他个体共生的能力决定了它的发展潜力。
为了适应不同业务和渠道的发展，过去很多企业的做法是开发很多独立的应用或APP。但由于IT系统建设初期没有企业级的整体规划，平台之间融合不好，导致用户体验不好，关键的是用户也并不想装那么多APP！
为了提高用户体验，实现统一运营，很多企业开始缩减APP数量，通过一个APP集成企业内所有能力，联通前台所有核心业务链路。
由于传统企业的商业模式和IT系统建设发展的历程与互联网企业不完全一样，因此传统企业的中台建设策略与阿里中台战略也应该有所差异。
由于渠道多样化，传统企业不仅要将通用能力中台化（对应领域驱动设计的通用域或支撑域），以实现通用能力的沉淀、共享和复用。还需要将核心能力中台化（对应领域驱动设计的核心域），以满足不同渠道的核心业务能力复用的需求，避免传统核心和互联网不同渠道应用出现“后端双核心、前端两张皮”的问题。这属于业务中台的范畴，需解决核心业务链路的联通和不同渠道服务共享的问题。

除了核心业务链路的联通和服务共享，还需要解决系统微服务分拆后的数据孤岛、数据融合和业务创新的问题。这属于数据中台的范畴。采用分布式架构后更应关注微服务拆分后的数据融合。
在中台设计和规划时，需要整体考虑企业内前台、中台以及后台应用的协同，实现不同渠道应用的前端页面、流程和服务的共享，实现核心业务链路的联通以及前台流程和数据的融合，支持业务和商业模式的创新。
中台转型要做到：前台流程融合、中台服务共享、数据融合创新。

五、 中台建设应该共享什么？

分布式和云原生等开源技术的逐步成熟，阿里、腾讯等互联网企业也从互联网业务主战场转型为面向企业的2B技术能力输出。这些成熟的云计算技术将为传统企业中台战略转型赋能，也为传统企业中台建设的技术路线选择提供了多种可能。
1. 先谈谈前台
传统企业早期系统有不少是基于业务领域或组织架构来建设的，每个系统都有自己的前端，相互独立，用户操作是竖井式，需要登录多个系统才能完成完整的业务流程。

中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案，实现各不同中台前端操作、流程和界面的联通和融合。不管后端有多少个中台，前端用户感受只有一个前台！

前台设计中可以借鉴微前端的设计思想，在企业内不仅实现前端解耦和复用，还可以根据核心链路和业务流程，通过对微前端页面的动态组合和流程编排，实现前台业务的融合。
2. 再说说中台
这里只讨论业务中台和数据中台。
传统企业核心业务大多基于集中式架构开发，单体系统存在扩展性和弹性伸缩能力差的问题，无法适应忽高忽低的互联网业务场景。而数据类应用也多数通过ETL工具抽取数据实现数据建模、统计和报表分析功能，但由于数据时效和融合能力不够，再加上传统数据类应用本来不是为前端而生，难以快速响应前端一线业务。
业务中台的建设可采用领域驱动设计方法，通过领域建模，将可复用的公共能力从各单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力中台。同样的将核心能力采用微服务架构模式，建设成为可面向不同渠道和场景的可复用的核心能力中台。 业务中台面向前台、第三方和其它中台提供API服务，实现通用能力和核心能力的复用。

需要记住一点：在将传统集中式单体按业务职责和能力细分为微服务，建设中台的过程中，会产生越来越多独立部署的微服务。虽然提升了应用弹性和高可用能力，但由于微服务的物理隔离，原来一些系统内的调用会变成跨微服务调用，再加上前后端分离，微服务拆分会导致数据进一步分离，增加企业级应用集成的难度。
如果没有合适的设计和指导思想，处理不好前台、中台和后台的关系，将会进一步加剧前台流程和数据的孤岛化和碎片化。
数据中台的建设可分为三步走。第一步实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。第三步萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。
数据中台不仅限于分析型场景，也适用于交易型场景。它可以建立在数据仓库或数据平台之上，将数据服务化之后提供给业务系统。基于数据库日志捕获的技术，使数据的时效性大大提升，可为交易型场景提供很好的支撑。
数据中台主要完成数据的融合和加工，萃取数据业务价值，支持业务创新，对外提供数据共享服务。

六、 如何实现前台的融合？

为什么要单独来说前台的融合呢？因为前台的融合对企业级的业务融合非常重要！
中台通过微服务实现了后端应用的解耦，提高了应用的弹性伸缩能力。但中台化的过程中也会将单体应用拆分出许多的微服务，前台团队将会面对多个微服务团队。如何实现不同中台的前台融合？前台应用如何正确的连接和拼装这些服务？不是一件很容易的事情。
为解决前台与中台的集成以及前台页面和流程的融合，我们借鉴微前端设计思想。在前端设计时，对齐微服务功能和职责，按照领域模型和微服务边界，构建与微服务前端功能相对应的可以独立部署、完全自治、松耦合的页面聚合，每个聚合只负责特定的 UI 元素和特定的功能。一个完成特定微服务前端功能的页面聚合就是一个微前端。
微前端与微服务集成后可形成从前端到中台可独立开发、测试、部署和运维的并且功能自包含的微前端业务组件。微前端除了可以实现前端页面的解耦外，还可实现前端页面的复用，这也与中台服务复用理念是一脉相承。
在微前端之上还有一个企业级的前台应用，它可以是一个企业级的移动APP，也可以是PC端应用，按照正确的业务逻辑和流程能够编排和动态加载企业内所有微前端页面，完成企业内核心业务链路的融合，给用户提供一致体验。
通用能力微前端大多作为共享的页面和功能，其功能入口一般常驻前台APP中，如购物车、商品、会员以及支付等功能。核心能力微前端主要完成核心业务前端功能，一般会根据业务类型动态加载对应业务的微前端页面。
比如：可以根据商品类型，加载核心业务微前端录单页面。在完成所有保单录入后，加载订单共享微前端页面，完成订单生成。订单生成后，加载支付共享微前端页面完成支付等等。共享微前端可在不同渠道前台实现复用。

七、总结

用技术语言总结就是**：“前台聚合，中台解耦，数据融合，业务创新”。先有共享、后有联通、再有创新。**

在互联网助力传统企业升级的今天，绝大部分公司都在建设自己能够触达用户的前台产品；而企业为了自身效率和合规本身就有建设相关的信息化系统（后台系统）例如：财务系统、OA系统、CRM、ERP等等。而这前后台的两类系统天生具有矛盾，前台追求多变、快速响应用户需求，而后台则追求稳定、合规。为了解决这种天生的矛盾，中台应运而生，中台是为前台而生，主要就是解决低成本快速试错的问题，能够让企业灵活的应对用户多变的需求。前台业务一般具有通用型，以交易业务为主，只要企业的主营业务不变。其创新的土壤还是一样的，例如：电商永远都是围绕商品、交易、支付、会员、营销、库存这几个领域；知识付费都是围绕内容、会员、交易、支付、营销这几个领域，如此种种，而这些领域能够在企业的长期运营中逐渐形成标准，而业务中台就是这种标准业务的系统体现，同时业务中台还提供让前台快速接入、灵活扩展的能力。而业务中台把数据沉淀以后，自然需要对这些极赋价值数据进行加工、处理、分析以反补业务、指引业务改进、引领业务创新。

业务中台+数据中台 是一种典型的系统架构，而为了解决快速开发、对复杂计算资源管理以及系统建设好以后的运维问题，也可引入技术中台作为整体系统的底座。

而为了把业务中台和数据中台更好的运营起来，为企业创造更大商业价值，很多企业也会配套把业务组织也改造成组织中台。

什么是中台

最近被老板折腾得够呛，我们老板听说最近中台的概念很火，让我们调研公司实习中台战略的可行性。刚开始并不理解什么是中台… 因此，写篇博客先简单介绍下什么是中台。
要理解中台，要先清楚传统项目架构的痛点在哪里

没有中台的时代

在传统IT企业，项目的物理结构是什么样的呢？无论项目内部的如何复杂，都可分为“前台”和“后台”这两部分。
什么是前台？
首先，这里所说的“前台”和“前端”并不是一回事。所谓前台即包括各种和用户直接交互的界面，比如web页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等。
什么是后台？
后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。
前台、后台、用户之间的关系，可以用下图简单表示：

在当时，项目的发展相对稳定，并不需要那么快速的去迭代和试错，所以这种结构并没有什么问题。
在互联网快速发展的今天，企业之间的竞争越来越激烈。只有以用户为中心，快速响应用户的需求，不断迭代和试错，才能让企业在竞争当中立于不败。
但是，现实情况下…
老板：小A，最近短视频挺火的，咱们也做一个短视频 APP 吧，一周时间够不够？
我：老板您别开玩笑了，新项目设计各种底层的技术和业务，能三个月搞定就很不错了…
在传统的前台-后台架构中，各个项目相对独立，许多项目都在重复发明同样的轮子，即让项目本身越来越臃肿，也让开发效率越来越低。

这种时候，为提高开发效率，我们有必要整合出一个中间组织，为所有的项目提供一些公共资源。而这个中间组织，就是人们所说的“中台”。

第一个吃螃蟹的人——SuperCell

SuperCell是一家芬兰的手机游戏公司，这个名字或许有些陌生，但是说起下面几款游戏，大家一定会很熟悉：
· 部落冲突

· 海岛奇兵

· 皇室战争

SuperCell公司就像是一个高产的游戏孵化器，在几年内开发出了10款以上的游戏，但是大部分用于试错的游戏都在研发过程中被腰斩了，最终呈献给用户的几款游戏都是经典中的经典。
是什么让SuperCell公司能够如此高效地试错和迭代呢？他们依靠的是强大的平台资源，支撑起各个游戏开发的小团队。
他们开发出的游戏看上去风格迥异，却存在许多共同之处。在业务上，共通的东西包括支付系统、用户系统等等，在技术上，共同的东西包括游戏引擎，内部开发工具等等。而这些共通的资源，都可以由一个强大的“中台”来提供：

中台的架构思想改变的不只是项目结构，也影响了研发团队的组织形式。SuperCell公司把这种高效的组织形式称为“部落”。
紧随其后，国内互联网公司也纷纷开始了各自的中台战略。
阿里巴巴提出了“大中台，小前台”的战略：

图中，阿里巴巴许多产品线的共通业务经过下沉，形成了中台的各种业务中心，而Aliware则是阿里巴巴的技术中间件平台，为各大业务线提供技术支持。
华为提出了“平台炮火支撑精兵作战”的战略：

华为把作战小分队比喻为前台项目团队，把中台比喻成战地指挥部。在这个比喻当中，中台的作用就是提供资源支持：要数据给数据、要技术给技术。

中台的具体划分

按照不同的功能和角色，中台可以划分为4个维度
业务中台
业务中台在前文中反复提及，就是把各个项目的共通业务进行下沉，整合成通用的服务平台：

技术中台
技术平台，为了避免研发人员重复发明轮子，向各个项目提供通用的底层框架、引擎、中间件：

数据中台
数据中台，为各个项目进行各种数据采集和分析：

算法中台
算法中台，为各个项目提供算法能力，比如推荐算法、搜索算法、图像识别、语音识别等等：

中台的适用场景

从0到1的阶段，没有必要搭建中台。
从0到1的创业型公司，首要目的是生存下去，以最快的速度打造出产品，证明自身的市场价值。
这个时候，让项目野蛮生长才是最好的选择。如果不慌不忙地先去搭建中台，恐怕中台还没搭建好，公司早就饿死了。
从1到N的阶段，适合搭建中台。
当企业有了一定规模，产品得到了市场的认可，这时候公司的首要目的不再是活下去，而是活的更好。
这个时候，趁着项目复杂度还不是特别高，可以考虑把各项目的通用部分下沉，组建中台，以方便后续新项目的尝试和旧项目的迭代。
从N到N+1的阶段，搭建中台势在必行。
当企业已经有了很大的规模，各种产品、服务、部门错综复杂，这时候做架构调整会比较痛苦。
候，趁着项目复杂度还不是特别高，可以考虑把各项目的通用部分下沉，组建中台，以方便后续新项目的尝试和旧项目的迭代。
从N到N+1的阶段，搭建中台势在必行。
当企业已经有了很大的规模，各种产品、服务、部门错综复杂，这时候做架构调整会比较痛苦。
但是长痛不如短痛，为了项目的长期发展，还是需要尽早调整架构，实现平台化，以免日后越来越难以维护。

中台只是一个工具、方法。
这个工具好不好用，取决于要解决的问题。如果问题没找对，那么这个工具也不会用好。
同程创始人在见实大会上的分享说到，创业14年来总结的成功公式，企业成功=战略*组织能力。如果没有好的战略，那么就抓不到关键问题，没有形成一套指标机制，那么企业要解决的问题就是乱的，这时运用的各种工具都发挥不好威力。
现在的经营重点，已经从经营产品转到经营用户上了。只有紧跟用户，才能立于潮头。公司战略制定好后，打造组织能力，同步形成一种顺畅的，适应该战略的文化机制，才能和战略相辅相成，互相促进。上下一心，高效运转，攻城克艰，达成目标，互相成就。
在这种流程下，所谓的中台规划才能被放在正确位置，用正确角度去处理，和其他工具方法一起配合使用，协助公司共同达成战略任务，解决突破关键问题，为用户带来价值，同步提升市场地位。
如果没有基于正确的业务战略，在一定清晰的业务规划基础上，只是从IT视角，那么这种角度规划出来的中台架构，只能是IT技术手段的IT架构，不会和业务形成战略协同力，那么这种程度的IT中台架构规划就不是在解决公司关键业务问题，就不会有什么威力。
就拿吃饭的餐馆举例。我们中午经常去吃的塘塘私宴，之前定位是私宴，装修也很不错，但是处在商务圈，客单价较高，生意不是很好，最近门口一直修路，生意更难。后来在大众点评推出中午商务套餐团购，性价比很高，味道也不错，我们就经常去，进行所谓的褥羊毛。
每次吃饭，就能看到里面各种忙乱，各种主管各种指点，服务员声音比食客声音还大。这种局面下，就是定位不清（私宴），大环境不好（修路），管理混乱，业绩就不稳定。在这种情况下，如何搞中台，如何优化管理结构，就很难。
在看看目前比较火的连锁网红餐饮，海底捞，西贝莜面村。他们就本身业务较好，形成了自己的竞争优势，做出了口碑，业务模式正确，业绩也蒸蒸日上。这种情况下，优化业务流程，搞中央厨房，就威力很大。
这时，中央厨房就算他们的中台，在中央厨房做好半加工，在统一配送到门店，门店基本不用厨师，只需要简单加工就能快速上餐桌。这种中台架构优化下，中央厨房效率更高，成本更优，管理更规范。门店成本也快速下降，门店租金高，厨房不用太大，空间利用更优。对门店厨师要求也低，成本也下来，而且菜品质量稳定，更容易扩张。客户体验也好，口碑叠加。
海底捞还把中央厨房变成了供应链公司，对海底捞外部餐饮输出能力，升级成为公司，给其他餐饮店做餐饮B2B供应。还做成品，供应商超网点，而且产品品类越来越多，变现能力越来越强。
这就是中台架构在不同公司的运用，形成的能力差别。我们可以感受下，公司战略清晰，业务模式健康，那么形成的中台规划，就是如虎添翼。如果公司定位不清，业务混乱，组织能力也受限，那么中台规划就不会成功。