• 设备
    • 今日
    • 2

    什么是中台业务架构?

    一、什么是前台,后台

    在以往的互联网企业生产流程中,我们可以将研发团队宏观的划分为前台与后台两部分。所谓前台就是用户直接接触到的产品部分,如可在应用商店下载的APP,像微信、抖音、淘宝,或者可以使用的网站等。
    用户对产品的认知与体验也由此而生。比如大家对于微信的理解就是这个前台APP展示的一切给大家描绘的:一个绿色图标的应用,里面有我的A、B、C好友。
    而后台包含两个部分:
    1. 企业的内部管理服务的统称,如:内部的CRM,ERP等;
    2. 为前台提供服务能力的,如:数据压缩能力,并发等。
    后台最重要的特点就是其提供的服务都是不被普通用户所感知的,就像用户不会因为应用的并发,传输速度而记住微信这个品牌。
    在搞清楚了前台与后台的概念后,前后台模式的产品服务模式我们就可以用一张图来概括描述:

    图1

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

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

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

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

    图5
    通过对比我们能清楚的看到中台对于公司的整个业务架构起到了非常大的简化作用。
    用一句话来概括就是:中台的核心本质就是服务共享,目标是支持前台的快速创新或试错,而实现的手段是微服务架构、敏捷基础设施和公共基础服务。
    三、中台解决方案
    那么到这我们可以给中台解决方案下一个定义:
    中台解决方案的组成 = 能力输出 + 标准化中间件
    让我们来一个个解释:
    第一部分:能力输出
    所谓能力输出就是要规划出什么是公司的核心竞争力,理清楚公司发展的战略与目标与未来公司里的主要业务会涉及到哪些方面。并在这些业务层面中去提炼哪些模块是以共性存在的,并会在每个新开拓的业务中不断使用,然后就把他归类到中台进行建设。这也就是中台的一个重要的意义:为不同的前台业务提供可以重复使用的能力,形成一次建设多次使用。
    例如我们规划了公司的核心方向是视频方向,未来可能会涉及的业务形态有:
    • 在线视频
    • 视频直播
    • 短视频
    • ……
    分析上面的业务方向我们不难判断出最基础要抽取的模块可以划分为:
    • 在线视频编辑
    • 视频压缩
    • 多人点播
    • ……
    完成拆分后我们就可以通过中台去实现这几个通用模块。
    值得提一下的是虽然这里在说中台要考虑复用性、扩展性,但是要考虑多少,考虑多深这里又是一个非常考验产品功力的地方。

    还是举上面的例子来说我在设计一个视频社区APP的积分商城系统时,需要将商城交易方式抽象为能力时,这里我们大体上可以抽象为如下三种交易方式:

    表1
    但是同样的疑问来了,我们仅仅为了支持一个积分商城需要将中台的复用与扩展放大要考虑引入股票交易才使用到的撮合交易模式吗?
    当然这里的案例比较极端我们能快速判断,但是在具体的中台规划中我们会碰到很多这种类似的范围决策,我们必须要按照公司的核心业务规划来严格定义中台的能力,避免在中台出现过度建设的现象。
    第二部分:标准化中间件(整合能力,并封装头尾)
    在我们确定了公司的业务发展需要哪些能力之后,中台解决方案的另一个组成部分就是需要做一个将每个能力进行封装,形成一个统一的可供前台业务端方便使用的中间件。
    这里的统一具体表现在如下的几个方面:
    • 不同终端中的叫法与含义;
    • 定义统一化的输入输出;
    为什么要统一呢?
    以往的前后台模式中同一家公司内的不同业务如:直播项目组、短视频项目组各自为战的时候,经常会出现一个事物被不同项目因为场景化的需求,而出现两个称呼的现象,但是实际上他们本质上是同一个事物。这也是原来不同项目组想要进行复用前人的模块时一个天然的巨大障碍——无法快速对接。
    例如:就那一个用户昵称这个字段来看,在不同项目组中的应用中可能会叫:用户名称、用户昵称、称号、花名等等,而在数据库中又可能会有不同的字段名称:username、UN、name等等。
    因此我们需要一个中心化的产物帮助我们定义好这些个通用属性,使在公司中不同的业务端都能统一。
    面对这种现象,在有了中台后,我们就可以通过定义标准化的中间件来解决。以后假设公司内部孵化的项目组再次要使用用户昵称这个字段的时候,无论具体是什么业务前端都会是一个叫法、一种存储,这样不仅能直接使用之前项目的模块,同时还可以和公司内部的管理系统如CRM/BI等快速完成对接。
    四、最后
    在竞争日趋激烈的互联网行业中,如何低成本又快速地完成业务创新去占领市场是每个企业所追求的方向,而中台解决方案的出现给我们当下的互联网企业带来了一个全新的发展思路。

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

    当前最需要建设的中台有两种:
    • 狭义的业务中台:一般指在线业务为典型特征的中台。在OLDI(Online Data-Intensive)时代,越来越多的企业的核心业务都是在线业务,因此把在线业务中台简称为业务中台。
    • 数据中台:一般指以数据采集、数据集成、数据治理,指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。
    对业务中台来说,比较符合的场景主要有:
    • 业务系统研发团队至少大几十人(含外包的),需求多变化快,系统又涉及多个领域(比如做ERP、电商的),业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚,提高研发效率。
    • 做相似行业的外包项目为主,业务规模也做的比较大的(一年有两位数的项目)。这时业务中台可以提升软件复用,降低定制化成本,提高研发效率。如果你做外包,每个项目都完全不一样,那中台也救不了你。

    对数据中台来说,比较符合的场景:
    • 数据产品比较多,每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。尤其是数据产品和运营人员还在多个团队。
    • 用数据的姿势比较复杂,问题比较多,比如经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题。
    网易杭州研究院建设中台,源自并行支撑多个业务的需求,追求技术体系化,对抗重复建设,建立共享能力团队,提高创新的速度和效率,提高成功率。
    要建设中台,需要考虑组织、支撑技术、方法论这三个方面,往往还需要咨询服务。
    支持业务中台的技术体系,包括微服务、DevOps、云原生和分布式事务等,在网易,是网易轻舟微服务平台,提供微服务应用全生命周期的完整支持,包括下一代微服务Service Mesh支持、经典微服务框架NSF、包括CI/CD的DevOps、分布式事务框架GXTS、APM、API网关、GoAPI全自动化测试以及容器应用管理服务等。
    支持数据中台的技术体系,包括指标管理、数据服务、元数据管理、数仓开发与管理、数据安全管理、数据资产管理、大数据计算引擎、数据集成/同步/交换引擎等,在网易,是以网易猛犸为核心的网易全链路数据中台解决方案

    关于中台的全面科普,可以参考汪源的中台系列文章,系统地回答了什么是中台、怎么建中台的问题,并给出了网易杭研的实践案例。
    • 什么是中台?所有的中台都是业务中台
    • 如何建设中台?中台建设的组织、支撑技术和方法论
    • 互联网公司的中台实践:网易杭研的中台往事

    首先什么是中台呢?中台战略是阿里 CEO 张勇在 2015 年提出的。
    中台到底是一个什么样的组织架构。以往我们在前线跑业务的时候,需要签很多的客户进来,并且收款。
    但是在签业务的过程当中,其实是需要很多职能部门的配合的,比如说市场部,比如说 HR 部门,比如说数据部门,甚至还包括技术部门。
    可是以往的工作过程当中,我们需要的是跟各个职能部门打交道,这样极大影响了效率,同时在信息沟通上面也有不同程度的衰减,这个中台部门的建立,就是将原有的职能部门抽取不同的人员,重新把他们组合在一起,形成一个新的部门,我们称之为中台部门。
    可以是销售运营中心,类似于这样的一个部门,这个部门里面的兵种是将原来的各个职能部门集合在一起,统一归业务部门指挥。这样能极大的形成有效的战斗力,同时也能够快速的支撑前线。这就是我们所说的中台部门。
    接下来,我为大家举以中供铁军为案例的一个中台搭建的过程。
    这里面有五个核心思想,分别是:第一,这支中台部门核心的是全面为外部客户,即向购买服务的用户提供一流的体验服务和效果;
    第二,全力支持内部客户,对于中台部门来说,他们的内部客户就是我们一线的销售团队;

    第三,高度指挥统一,大多数情况下,这些部门它会有一个中台部门的直属上级。也就是说,这里面我们可以设置一个头;
    四、管理幅度可控。一个管理者管理幅度最多十个人,再多效率就会下降了;
    五、分工要明确,分工为横向和纵向两个,横向主要是指直门线,指的是专业化分工和专业化的水平,纵向指的是层级,当然组织越发庞大的时候,形成了更多的矩阵式的发展,甚至会产生生态型的公司。这个时候就需要更复杂的管理架构,比如说双轨制双线汇报,甚至会出现三线汇报的状况。
    接下来,我们回到中供搭建上面,我们先来介绍一下前线部门是怎么搭建的,有了前线部门的搭建以后,我们就知道后线部门应该怎么搭建了。
    那个时候,我们的前线部门是以十人为一个作战小组,配备一名主管,十个小组形成一个小区域,十个小区域呢构成一个大区域,若干个大区域会报告业务总经理那里,那么部门市场大的区域也出现过特例,会有十三个到十四个小区。
    在管理上面,我们会在大区的下面也会设置一名销售的大区的副总,协助大区总进行管理。而在进行中台搭建的时候,就要回归到业务流程上,我们的组织一定要跟我们的业务流程相匹配。
    所以我们来看一下中供铁军的业务流程。
    大家设想一下,中供是 B2B 的销售,所以在 to B 的销售的过程当中,业务流当中的第一步,其实是获取潜在的客户资源。有了这个销售线索以后,我们要去打电话,打完电话预约了以后,要去上门,见过客户以后,我们就会把上门过的客户进行分类,比如说会有 A、B、C、D。A 类客户代表的是最好的客户,D 类客户代表的是一般的客户,有了这些客户分类以后,才会像漏斗一样漏到签
    单环节。
    签单环节之后,是收款,然后再到售后服务的环节,这就是我们整个的业务流。在这个过程当中,都需要哪些部门来配合,支持销售去完成从获得销售线索,一直到最后的签单收款,到最后的服务的这个过程呢?那我们接下来跟大家再仔细的剖析一下。
    首先我们来看,获取潜在客户资料的这个环节。
    在这个过程,除了销售端自己去获得一些销售线索以外,要发挥整个公司的作用,这就需要市场部门来配合。在原来的中供铁军里面,会专门有一个叫做市场部,他们通过做品牌,通过做市场活动,去获取更多的销售资源,他们也得要通过不同的手段去拿到我们所需要的销售资料,以补充到一线人员快速的获取客户的需求上来。

    其实中台严格意义上来说,不是一种架构,也不是一种系统,而是一种战略。
    以前的企业发展到一定程度,需要规范化管理的时候,我们上了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中,如购物车、商品、会员以及支付等功能。核心能力微前端主要完成核心业务前端功能,一般会根据业务类型动态加载对应业务的微前端页面。
    比如:可以根据商品类型,加载核心业务微前端录单页面。在完成所有保单录入后,加载订单共享微前端页面,完成订单生成。订单生成后,加载支付共享微前端页面完成支付等等。共享微前端可在不同渠道前台实现复用。

    七、总结

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


    来自:PC 广东省广州市
    上一篇: 黑果枸杞的功效、作用与食用方法
    您可能还喜欢这些:

    1 1条评论

    评论审核已开启:即评论经审核才能正常显示! 记住我的个人信息 回复后邮件通知我