互联网中台思想和建设方法到传统企业为何水土不服?(200914)

标签: 微服务架构 | 发表时间:2020-09-14 07:59 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi

在前面我已经分享了些关于中台,微服务,传统企业IT架构转型方面的文章。今天准备展开谈下互联网企业建设中台和传统企业建设中台的一些差异点,以及互联网中台建设方法论和架构设计转到企业后为何出现水土不服的问题。

最近这几年,在SOA和微服务后,中台这个词相当热,企业往往也出现两种明显分歧。一种就是中台和技术狂热型,恨不得企业的IT明天就能变成中台和微服务架构;还有一种企业就认为中台就是互联网企业概念炒作,用互联网概念来收割传统企业。

因此今天准备对互联网中台到传统企业中台做下对比分析。

中台概念在互联网企业出现背景

互联网中台思想和建设方法到传统企业为何水土不服?

 

这个我在前面文章也专门谈到过,今天再重新说下重点。

首先再次重申,中台本身是一个业务概念,其次才是技术实现。中台的出现一定是业务目标和需求驱动的,总结来说就是如下:

在前端的业务需求和模式快速变化的情况下,我们需要快速的响应。

如何做到快速响应?

即从对业务能力的从头开发,变化为对已有业务能力的组合。因此我们需要将共性业务能力进行整合,将这些业务能力以可共享的API服务方式提供给前台使用。

所以你再回顾互联网企业业务组织和架构,你会发现一个关键点,即你看到的类似库存中心,订单中心,结算中心等本身就是业务组织部门或业务单元。而这些业务组织部门本身又对应到业务模块的微服务实现。即:

业务组织部门或单元=》微服务模块实现之间是完全对应和映射的。

简单来说,互联网企业在运营的过程中,业务组织架构本身就已经是共性业务能力下沉,业务组织单元微服务化的了,其次才是技术实现的微服务化。

业务或运营模式变化快才需要快速响应

对于互联网企业我们一定要比较和传统企业关于用户群的一个区别。互联网企业是直接面对最终的B端或C端用户,而传统企业IT系统是面对内部的业务人员和管理人员。互联网企业本身的产品化运营往往就需要配合用户个性化多变需求快速灵活响应,否则就失去机会。

类似互联网的电商平台,你可以看到类似团购,秒杀,企业福利,支付理财,自营,toB或toC等各种运营模式不断在变化以满足业务需求。而这些前台应用的构建都需要用到采购,物流库存,财务结算,用户,产品管理等共性能力。

那么我们期望自然是能够复用和组装这些能力,而不是再去重新开发。

正是用于这种原因,我们需要将共性能力下沉,形成中台各业务单元。如果从业务上来说就是中台里面的各个业务组织部门,能力都相对稳定,不会经常变化。但是前台出现新商业模式后,任何一个新前台应用构建都可以单独组建一个新的业务团队,这个业务团队再对应到前台应用这个微服务模块技术实现。

传统企业和互联网企业中台差异化分析

互联网中台思想和建设方法到传统企业为何水土不服?

 

在了解互联网中台建设背景后,我们再来回顾传统企业是否需要一个完整中台就更加容易点。即我们基于互联网企业出现中台的几个背景要素进行分析来说明。

其一:传统企业业务是否需要像互联网应用一样足够敏捷?

对于企业的完整价值链来讲,我们可以将其分为两个关键阶段。其一就是围绕产品从无到有的核心研发,供应链和生产制造价值链。其二是生产出来的产品如何卖出来并交付到最终消费者手里面的销售运营价值链。

对于大部分企业来说,更加重要的是供应链核心流程,而对于销售这块往往本身就是依托于已有的各大电商平台,或别人的分销体系。除非你自己去构建了一个完整的分销线下网络,类似格力这种自己分销网络体系。

对于企业的供应链核心价值链,企业本身的计划,生产运营模式不可能随时都在变化,同时面对的又是内部用户需求本身时间容忍度也大。

因此IT系统完全不需要类似互联网应用一样的敏捷程度。

其二:传统企业的业务架构和组织模式是否先进行了重构

对于大部分传统企业来说,真正困难和难以推行的都是业务组织架构的重组,其次才是IT系统的建设。很多CIO希望通过IT系统建设或者说当前的中台,微服务来倒逼业务架构重构,往往都是一厢情愿,到最后往往根本推行不下去。

当我们观察大部分企业的时候,你会看到企业本身的业务架构往往就没有中台化。

我们可以举些常见的例子,比如一个制造企业有多个子公司,你会看到各个子公司本身的财务,供应链,售后这些本该业务下沉和集中化的本身就没有统一。在企业内部业务上就没有我们经常谈到的共享中心的概念。

在业务组织本身就没有共享化,拆分化的情况下推进中台往往就是难上加难。

其三:前端应用是否不断推陈出新

在前面我已经强调了,传统企业的内部IT往往就是支撑企业核心价值链一套业务,最多也就是PC端BS应用和手机端两种展现模式,但是本质还是一套应用系统。

对于供应链核心价值链来说根本就不存在要不断推出新应用的可能。只存在会出现的业务流程的情况,而对于新业务流程的出现往往基于传统SOA架构思路完全可以解决。即将遗留系统接入和适配,将服务能力共享开放即可。

传统企业什么时候需要一个中台?

经过上面分析我们可以看到,大部分企业并不需要一个类似互联网企业一样的中台。那么什么时候需要这个中台呢?

也就是什么时候会出现类似互联网企业一样的背景需求。

互联网中台思想和建设方法到传统企业为何水土不服?

 

还是会到前面的分析,简单来讲就是:对于本身就是做C端消费类产品的企业,本身又希望实现对终端用户的端到端触达能力,同时营销价值链本身又是完全自建的情况。这种企业往往中台规划建设的需求最强烈。

我们也看到当前很多上中台的企业更多就是属于上面场景的企业,而且中台的构建更多的是面向自己的电商平台,CRM营销网络,面向C端的前台应用需求。

在这种情况下,企业需要去构建一个中台来满足前台应用敏捷化的需求。

也就是说这个企业中台已经不再是简单的满足内部业务系统,内部用户的使用,而是更多的打破了企业边界,面向外部的消费者用户,或者产业链上的生态合作伙伴的需求。

在这种场景下,我们就需要对企业内部已有的业务能力进一步包装和抽取共性,然后将共性能力以API接口服务的方式提供给前台应用。

互联网中台思想和建设方法到传统企业为何水土不服?

 

其次,就是一个大的集团性企业,本身在进行业务重组,将共性业务能力形成共享中心的方式进行统一的情况下,需要去构建一个中台。这个也和我们中台产生背景思路一致。

比如前面谈到的,一个生产制造企业,本身有很多子公司或工厂,但是你可以看到企业的供应链能力,营销服务能力,售后服务能力完全是可以共享和复用的,这些业务能力应该进行整合和统一。真正差异化的仅仅是制造各类产品不同的制造单元。

在这种明确的业务驱动和业务整合背景下,往往也是最佳的构建中台场景。

传统企业更多的是转型到平台+应用构建模式


互联网中台思想和建设方法到传统企业为何水土不服?

 

这里的平台我们指技术平台,或者对应到中台概念里面的技术中台。这个平台即我经常说到的私有云PaaS平台。而私有云PaaS平台的重点就是将企业内部业务系统构建需要的共性技术服务能力下沉并统一建设。这些共性技术能力包括了中间件,数据库资源池,也包括了类似4A,流程引擎,消息,缓存,文件,任务调度等共性技术服务能力。

为何平台建设如此重要?

我们要意识到只有原业务系统中的技术平台完全下沉并移出,上次的业务系统模块才能够实现彻底的组件和微服务化架构。

这个我在前面一篇文章专门谈到过,可以参考:

SOA和云计算-企业私有云PaaS平台建设实践

同时对应平台层规划建设,我们理解重点应该包括:

步骤1:4A和流程平台的下沉和能力开放

这个是我谈的最多的问题,即在实施微服务架构转型的时候必须将4A(也可先狭义理解为原业务系统的系统管理模块)和流程引擎下沉到平台层共性建设,或者说优先要将这两个模块作为微服务模块剥离出来,同时给上层的业务组件模块提供API服务接口能力。

对于4A模块剥离后,我们希望的是涉及到人员,组织,用户,权限等能力的获取都是通过服务接口实时查询获取,这些基础主数据信息也不要落地。在进行这样实施的时候确实会增加上层业务系统的改造工作量。对于流程平台的签出相对来说比较容易,最主要的还是给业务模块提供流程启动,暂停,获取待办已办列表等关系服务接口信息为主。

进行4A和流程平台的剥离核心目的仍然是是的后续需要进行拆分的业务模块只包含业务功能,而不再包含共性的技术能力功能。

步骤2:基础主数据模块能力独立建设

这是我们谈的第二个重点,即希望将提供共享基础主数据的功能单独剥离出来进行独立建设,比如建设独立的主数据平台或叫提供基础主数据的各个数据中心模块。然后数据能力以数据服务的方式暴露出去供上层业务系统使用,同样我们希望上层业务模块在使用这些基础主数据的时候最好主数据不落地,实时用实时查。

在传统PaaS平台建设中会涉及到MDM主数据平台的建设,到了彻底的微服务架构可能并不存在主数据平台的概念,而是各个类似产品中心,供应商中心,客户中心的各个微主数据中心模块,这些微服务模块也是我们常说的中台的核心数据能力提供中心。

要规划和建设中台,首先要考虑的就是这种基础数据中心,其次才是提供业务支撑和业务逻辑处理的中心。

步骤3:及早的进行统一门户的建设

要注意,在各个微服务模块建设完成后,单个微服务模块本身是不能提供支撑完整业务流程的能力。对于用户来说并不关心是否进行了微服务架构化,而是关心涉及到业务流程处理的功能和操作是否能够很方便的在一个业务应用里面操作和完成。

而这些业务模块基于业务流程,基于业务场景和使用部门的组装和展现,就需要在门户层完成。对于统一门户不仅仅是提供统一认证和单点登录,也还包括了统一的待办集成和任务处理,统一的消息通知等共性功能能力。也就是说,只要是各个微服务模块共性的一些需要展现的能力,都可以集中化到统一门户层去集中处理和展现。

门户层还有一个重要的功能就是进行微服务模块的组装,这些模块组装后可以为业务用户提供完整的端到端业务流程功能支持,让最终用户的感觉就是在使用一个系统,没有系统不停切换的感觉。因此实际上在门户层不仅仅是简单的模块选择,也还可以做一些展现层的编排和组合工作。

对于微服务模块的灵活组装也是相当困难的,因为很多模块组装最终都是体现到模块提供的南北向接口的自动对接,这往往是比对服务组合和服务编排进行定制更加困难,对于这个问题后续将在单独进行讨论。

已有的IT架构和遗留系统如何构建中台?

互联网中台思想和建设方法到传统企业为何水土不服?

 

这个估计是大部分企业都会遇到的问题。也是我们经常说的,传统企业中台的构建不能完全照搬互联网企业中台构建思路,而是需要考虑如何最大化的保护遗留IT资产。

即使企业是需要对外构建完整生态链的情况下,也不可能将企业内部已有的IT系统全部完整中台和微服务的架构思路完全推倒重新建设。

正是这个原因,我们提出一个重点,即:

传统企业在最大化保留遗留资产情况下,更多应该是适配方式构建一个能力中台。

在这里我将其称呼为能力中台意思就是,这个中台的服务能力不是全新产生的,而是对遗留IT系统能力的一种适配和聚合形成的。

即能力中台有点类似于我们传统在SOA架构下的ESB总线和服务共享平台建设。

那么这个能力中台和单纯的ESB总线区别在哪里呢?

其中最大的区别就在于这个能力中台,本身不是简单的接口服务接入和集成,而是对已有的遗留IT资产,数据库,接口API等进行了重构,适配,整合和重组,构建了一个满足新业务构建的完整领域服务能力层提供。

也就是说这个能力中台本身是可能存在业务代码和业务逻辑的。

互联网中台思想和建设方法到传统企业为何水土不服?

 

如上面图所示,在构建新的中台能力服务层的时候,为了对已有的业务系统影响最小,我们需要重新构建中台能力接口,这个接口涉及到一定的适配和定制开发工作量。

具体接口的实现本身又包括了三种方式,即:

  1. 直接连接遗留系统的数据库,来重新开发接口服务。
  2. 通过遗留系统已有的JAR包引入,来重新开发接口服务。
  3. 通过遗留系统已有的WS或Rest等接口服务适配,来重新开发接口服务。

可以看到三种模式中对于数据库这种模式是对业务系统依赖最小的模式,但是这个模式本身也是需要我们重新大量完整性校验,业务规则的模式。这种模式本身就可以看到对遗留业务系统的部分业务规则和能力进行了重写,即这部分业务逻辑规则已经在朝中台能力层逐步迁移。

这种迁移形成的接口服务能力,一方面是构建全新的业务应用可以使用。而同时,我们建议是及时对于PMS或SCM等业务系统,如果有全新的业务模块需要开发,也完全可以基于中台已有的接口服务能力进行,只有这样才容易实现后续的业务系统逐步迁移到中台架构上。

数据重构和服务组合是中台另外一个关键能力

在中台能力构建的时候,一定要考虑数据重构和能力组合。

即中台的能力接口不是简单的数据库CRUD能力暴露,也不是已有的遗留接口的简单适配和接入。而是真正根据业务流程和业务需求驱动,失败关键的业务能力,将业务能力转变为服务。这种服务本身是粗粒度的,有明确的业务含义,有点类似我们在领域架构设计里面经常谈到的领域服务能力。

中台构建不要盲目的微服务架构化

最后再次强调下,企业中台的构建不一定要全面微服务化。比如我们前面说的能力中台建设,更多的是适配已有的资产能力进行重构形成能力开放平台。

我始终任务:企业业务共性能力下沉,并形成统一服务对前台提供。

这样满足这个目标要求,构建的就是企业中台,这个中台是否一定微服务化反而不是重点,只是说微服务化后,整体的解耦,扩展性更强而已。

但是一定要注意到,引入微服务本身对企业IT治理管控水平要求相对高。如果企业本身的IT成熟度没有达到一定阶段,显然是不可能推行实施微服务架构的。这个道理前面已经谈到过,在企业IT建设中,如果连粗粒度的业务系统以及它们之间的集成都管理不好,那么更没有能力管理细粒度的微服务模块。

那么如果企业IT成熟度达到一定水平,在推广微服务架构还存在的难点如下:

首先是架构设计能力的显性化,即架构设计这个工作的输入,输出和过程需要更加的显性化出来形成团队都认同的标准工件。一个业务系统没有拆分开时候,虽然有架构设计和组件划分,但是这个工作是属于团队内部的事情,即使架构设计不合理,在后期集成也可以通过诸多变通方式解决掉。而现在是不同的微服务模块可能分派到两个独立的团队开发,原来属于自己内部黑盒的问题变为团队间问题。

简单来说你原来藏着或没做规范的东西太多,而现在这些不能再藏着掖着了,当真要把这些东西拿出来的时候,你才会发现你原来架构能力是有欠缺的。正如我们理解了一个东西,那么要让我们清楚的讲出来困难,那么我们的理解有欠缺。对于我们能讲清楚的东西,要系统的写下来有困难,那么说明我们讲的结构和条理有欠缺。

其次管控要求和规范体系的建立,对于管控要求可以看到如果两个微服务模块分给同一个团队开发,如何才能保证开发的团队保持两个模块的完全独立和解耦,两个模块间不会出现相互交叉的数据库直接调用,也不会存在直接绕开Service接口的其它耦合调用?这些如果没有完整的管控和检查体系我们很难约束。

微服务架构下导致的开发复杂度增加

互联网中台思想和建设方法到传统企业为何水土不服?

 

只谈微服务架构的松耦合和高扩展性,而不谈开发和集成复杂度的都是耍流氓。

实际上当前很多企业对微服务架构并没有如此迫切,互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力,而实际大多数企业内应用往往并没有如此海量并发。

其次,即使在并发量增加的情况下通过进行代码本身的优化,数据库调优或者升级硬件服务器资源都可以较好的解决性能问题。而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本,后期的运维管控成本。

要做到完全微服务模块独立,微服务架构下最大的一个变化就是数据库也拆分开了,原来的一个业务系统如果分为5个微服务模块,那理论上就是5个独立的后台数据库,而且数据库间还不能随便相互连接和访问。只有这样微服务模块才能做到独立部署和管理。

由于数据库拆分带来两个问题,其一是我们原来很简单的一个跨表查询操作现在无法做了,我们必须调用两个微服务模块提供的服务,查询到数据后再到逻辑层进行组合。其次最大的问题就是如果一个业务操作需要同时更新两个微服务模块的数据,由于服务本身无状态,导致了这种分布式事务问题很难解决。

企业内业务系统很大一个特点就是业务逻辑和规则相对互联网更加复杂,而且有更高的事务一致性要求。正是由于这个原因,无法解决好分布式事务的问题都将直接导致后续数据不一致和业务错误。

微服务架构下导致的集成复杂度增加

互联网中台思想和建设方法到传统企业为何水土不服?

 

任何一个微服务模块在外部协同上都存在两个点,一个是模块本身要消费和调用其它微服务模块提供的服务接口,另外一个是模块本身又需要将其业务能力暴露为服务接口给其它微服务模块使用。

如果一个微服务模块要同时支撑PC端和APP端,可以看到微服务模块暴露的服务还需要统一提供给前端的展示用。那么可以看到一个微服务模块需要完成自身组件层和展现层间的集成,同时又需要完成多个微服务模块组件间的横向服务集成。

如果我们将消息,日志,流程,4A等能力下层到平台层微服务模块,那么一个组件要跑起来还涉及到和平台层的多个技术类微服务模块集成。在如此复杂的集成场景下,要将复杂的跨多个微服务模块的横向端到端业务跑通,其涉及到的模块数,接口数都远超原有单一系统的模式。

一个业务系统如果没有拆分为微服务模块,那么其它内的模块间集成和集成测试是系统内部的事情,但是一旦拆分为多个微服务模块,那么这种集成就变成外部第三方的事情,或者必须要显性的事情。集成复杂度会大增,同时系统健壮性和稳定性下降。

微服务架构下的运维问题

互联网中台思想和建设方法到传统企业为何水土不服?

 

在实施了微服务架构后,运维的复杂度也是成倍增加,任何一个微服务模块出问题都可能影响到整个业务应用的功能使用。我们在运维时候不仅仅要健康单个微服务模块,还需要健康所有的接口服务监控状态。

如果跟Docker集成了,我们看到整个性能监控和问题分析都会变麻烦了,没有实施微服务架构前发现问题,我们直接可以看应用服务器上类似tomcat或jboss日志,而实施了微服务架构后,应用容器已经是自动部署和动态分配的,原有的故障诊断模式行不通,而需要PaaS平台本身提供完整的预警和日志分析能力。


 

相关 [互联网 中台 思想] 推荐:

互联网中台思想和建设方法到传统企业为何水土不服?(200914)

- - 人月神话的BLOG
在前面我已经分享了些关于中台,微服务,传统企业IT架构转型方面的文章. 今天准备展开谈下互联网企业建设中台和传统企业建设中台的一些差异点,以及互联网中台建设方法论和架构设计转到企业后为何出现水土不服的问题. 最近这几年,在SOA和微服务后,中台这个词相当热,企业往往也出现两种明显分歧. 一种就是中台和技术狂热型,恨不得企业的IT明天就能变成中台和微服务架构;还有一种企业就认为中台就是互联网企业概念炒作,用互联网概念来收割传统企业.

周鸿祎:用“毛泽东思想”做互联网

- 纸条 - 每日鲜果精选
做技术的人觉得有一种天生的优越感,有的人用居高临下的眼光来看普通的用户. 其实,心态这东西就是一层窗户纸,一旦你这样捅破了,你就放下了自我,真正融入到用户中去了. 毛泽东还有一句话:从群众中来,到群众中去. 我把它改一下,做互联网产品,就要“从用户中来,到用户中去. ” 《毛泽东选集》第一卷开篇第一句话:“谁是我们的朋友,谁是我们的敌人,这个问题是革命的首要问题.

网景创始人安德森:五大思想改变互联网

- - 行业资讯
   硅谷风投公司AndreessenHorowitz负责人马克-安德森(TechWeb配图).   北京时间4月22消息,据国外媒体报道,美国《福布斯》杂志网络版近日发表了署名为安东尼-维格-科斯纳(AnthonyWingKosner)的文章,该文章指出互联网传奇人物马克-安德森(MarcAndreessen)的思想总是非常超前和正确.

移动互联网=移动+互联网?

- 可可 - It Talks-魏武挥的blog
从名词上看,移动互联网似乎就是互联网加上一个移动. 但移动互联网远不是“移动的互联网”那么简单. 它的本质——网络部分,就和互联网大不相同;而它的表现——移动部分,也正因为移动,造就了很多和互联网相当不一样的商业机会. 而更重要也是很多人并没有注意到的是,它可能会改变整整一代人的信息处理习惯. 从网络部分而言,我们都知道,理论上互联网是没有拥有者的.

重新索引互联网

- keso - 爱范儿 · Beats of Bits
重新索引互联网 Facebook 雇佣公关抹黑 Google 的过程已经水落石出. 问题是: Google 那么多产品, Facebook 为何对 Social Circle 这么敏感. Google 号称自己的使命是“索引互联网”. 这件事的难点并非派出多少爬虫,而是对收集来的海量内容做排序:怎样让真正重要的网页,的排到 Google 搜索结果的前面来.

中美互联网差异

- leeking001 - 互联网的那点事
在互联网以指数的速度发展的今天,人们的生活已经离不开网络,那么,这两个打过在互联网方面有什 么差异呢. 我们从下面一系列与互联网相关的参数来比较两个国家,比如:互联网用户数量,互联网普及率,互联网连接的速度,域名数量,受欢迎的网站,网页浏 览器,操作系统等等. 十年前,美国是世界上的互联网头号大国,而现在很明显已经不是,取而代之的是中国.

重新索引互联网

- Ray - 最新文章 - UCD大社区
重新索引互联网 Facebook 雇佣公关抹黑 Google 的过程已经水落石出. 问题是: Google 那么多产品, Facebook 为何对 Social Circle 这么敏感. Google 号称自己的使命是“索引互联网”. 这件事的难点并非派出多少爬虫,而是对收集来的海量内容做排序:怎样让真正重要的网页,的排到 Google 搜索结果的前面来.

互联网七巧板

- Ray ma - 云科技
话说天下事势,合久必分分久必合. 大半年前在一辆宝马车里,一互联网大佬爆料说“百度可能收购新浪,肯定在谈”. 半个月前又开始传,百度高管去硅谷跟Facebook谈合资了. 前天又听到,搜狐可能和另一家互联网巨头合资做微博. 互联网的谣言和互联网的股价一样,起起伏伏. 不过,本文主题不是关于百度或者搜狐或者新浪,而是关于合资.

被选择的互联网

- Jacqueline - 月光博客
  连线杂志的那篇《互联网死了》确实震动业界,而现在,百度的框计算似乎正在验证他的话. 无论是高兴也好,无论是哀嚎也罢,百度的框计算终究给最终用户带来了一些实际的东西. 他改变了人们对于传统搜索的认知. 而百度这类似的行为,正成为互联网的一种趋势. 可以说,商业化的大潮,正在人为的割裂互联网,让他的边界越来越明显.

互联网的锤子(三)

- 盛开 - 月光博客
  对微博的讨论思路仍将从信息的获取和发布两个方面结合微博的特征来讨论,这将是我们的思维定势.   2006年twitter诞生,在blog之后,在rss,digg,youtube之后. 在这些应用出现之后,网民创造的信息内容与日俱增,对新闻资讯,博文的评论散落在网络的各个角落. Twitter生逢其时,将网民集合在一个平台上,最初将这一优势显现出来的是对突发新闻的报道,在现场的网民发布现场图片信息,通过twitter直接将图片传送给其他网民,经过转发评论,现场的新闻图片传播到整个twitter平台上,实现即时广泛的传播.